forums.silverfrost.com

[JohnCampbell]

Today I have a project where I need real numbers with 9 significant digits. It would be good if I could call "Selected_real_Kind (9,12)" and get a numeric precision that suits that. The reality is that I get real*8, as there are very few options available.

WRT /alt_kinds compiler option, I tested the following program; with and without the /alt_kinds option. The results do not change.

Paul, should we expect the results to be different ?

I think that the reality of the /alt_kind implementation is that it is presently limited to numeric constants, of the form "2.1_8" and not yet "real (kind="

[PaulLaidler]

selected_real_kind etc. give the compiler defaults. I am not surprised that /alt_kinds makes no difference. I guess that strictly it should but in practice programmers will either use literal constants or selected_x_kind not both.

Perhaps it is strictly a bug that I need to fix.

[LitusSaxonicum]

It amazed me, and annoyed me at the same time, that Fortran 90 et seq. eschewed the ubiquitous REAL*8 for all this KIND nonsense. The reason that CDC didn't have REAL*8 is that they ran 60-bit words. You could therefore have 60 bit REAL or 120 bit DOUBLE PRECISION, but not 64 bit anything. When computers were word-based instead of being byte-based, there were all sorts of native precisions, for example, 36-bit or 24-bit words etc.

Although there are a few constructs in Fortran 90 that have no equivalent in Fortran 77, mostly the new features duplicate things you could already do. The 9x standards simply ignore such things as graphics, user interfaces and so on, as a result of which the language went nowhere at a time it could have been rejuvenated. To get all those things, one has to tie oneself to a specific compiler, e.g. FTNxx with ClearWin+. I imagine that this makes commercial developers nervous. However, Salford/Silverfrost's FTN proved more durable than Microsoft's Fortran! Tying oneself to Windows is less of an issue, given the proportion of machines that use it.

I recently spent some time pondering Hatton's "safe subset" idea (i.e. that there is a subset of a language that programmers make fewest mistakes with - in his case he considered Fortran 77). The safe subset of Fortran 9x is, of course, Fortran 77. Not only is this true of user code, but based on what gets fixed release by release, it is true of FTN95 itself (forgetting "reversions" - of which there are few).

In my view, it is sad that we don't have REAL*6, as this is for many uses REAL*4 is grossly inadequate, and REAL*8 is overkill. We had this precision on ICL computers, and also on the BBC micro.

KIND might be of more use if one could trade off range and precision, but in practice, one can't. There is one model for how the bits are shared out, and that is that.

A similar argument could be adduced for the introduction of "short" INTEGERs. I never got integer overflow on a machine where the INTEGER and REAL were the same length - it was a problem I first encountered (but only once) on a PC when I used short (INTEGER*2) integers to save space on my first PC back in 1983. I realise that few people get integer overflow with INTEGER*4, but that small number becomes even smaller with INTEGER*6.

Eddie

[IanLambley]

Eddie,

Remember the REAL*16 on the VAX, and there was a compiler option to use "Huge" or "Grand" whereby the size of the mantissa and exponent could be juggled to give a "Huge" range or a "Grand" precision.

We can use REAL*10 on FTN95 which goes someway towards what we had in the 1980s. And of course INTEGER*8. But are these available to Win32 only and not .net?

I also seem to remember that DECUS provided Fortran source code to use arbitary precision variables.

Ian

[JohnCampbell]

Paul,

I would say that not supporting "real (kind=" or "real (" when /alt_kinds is selected is the main bug that should be corrected.

I am not aware of this ever working with /alt_kinds, although I have been wrong before when recalling past versions of ftn95.

Also the interpretation of "integer (kind=4)" or "integer (4)" should be guaranteed to work when /alt is or is not selected. It's use probably should include a warning as to what precision was implied. I think this is the only kind value overlap when using the /alt_kinds model.

When it comes to reals, why can't the kind value sets of 1,2,3 or 4,8,10 both be supported ?
With integers, we have 1,2,3,4 or 1,2,4,8 giving ambiguity only for integer (kind=4).
Logical and complex can also easily overlap. ( Is there a LOGICAL*8 ?)

John

[PaulLaidler]

Now you are confusing me!

/alt_kinds should be working correctly from version 5.40 of FTN95.

selected_x_kind gives the default values (i.e. it does not respond to /alt_kinds).

I can make selected_x_kind sensitive to /alt_kinds and this would seem sensible although it may never be used in this context.

[fmolina]

Hi:

/ALT_KINDS work correctly now in v 5.40, at least with real declarations (but see below). Probably selected_real_kinds should reflect that option too, so as kind = selected_real_kind() works always the same, but I agree that is an uncommon case to find that construct together with /ALT_KINDS

Now, I discovered one problem with v 5.40, at least that downloaded from Mediafire: It works OK on 32 bits WinXP, but on 64 bits XP crashes at the end of compilation leaving a 0 bytes .obj file, with the following messages (from Plato):

[JohnCampbell]

Paul,

Sorry about the confusion. We previously discussed /alt_kind in Feb-07. At that time I was finding problems with it's use.
I am yet to download Ver 5.40, but have recently noted that Ver 5.30 does not work. ( I always wait a while to see what others find. I've only just stoped running Ver 4.9 as a backup check of Ver 5.3 )

My apologies as I should have read the Ver 5.40 release notes that mentions /alt_kind.

Based on my post last night, could you consider an extension to FTN95 to support an extended set of kind values;
for Real and Complex, always include 4, 8 and 10 as valid values
for Integer, include 8
for Logical, include 4

The only problem came about when INTEGER*8 was introduced, which I recall as recent ! For Integers, when kind=4, or nn_4 is used, then the compiler should issue a warning about ambiguity or non-portability. I must admit that this could get messy, as "1234_n" is valid and when n=4 can be a 64 bit or 32 bit value, depending on /alt_kind. Infortunately, I think the only way to provide an integer*8 constant is using this number format. If n has been derived from selected_int_kind then a warning would be misleading.

Back on the introduction of KIND
Back in the 70's and 80's I did a lot of work on converting programs of unknown origin to Prime, Vax and PC. Control Data was fairly common to me, but there were a few English computers with wierd precision which always caused a lot of problems. Does anyone remember IBM fortran? What a nightmare! Practical Fortran 4 and Fortran 77 programs always mixed integer, real and character/hollerith in the same memory locations. It was increadibly frustrating that real*n and integer*4 was not enforced, as this was the clearest and most concise way of describing the precision of variable declarations, especially reals. I wonder how much experience in fortran programming some of the members of the standards comittee had. They certainly keep introducing program constructs that I, as a fortran programmer, do not use!

John

[jjgermis]

[PaulLaidler]

John

Sorry but I will not be able to provide support for both kinds simultaneously although with the present compiler you can do it on a file by file basis.

There are three reasons for this

1. We need to keep things simple (the KISS principle) for everyones sake.
2. Programming the compiler for this would not be straight forward.
3. There is already an overlap and this may increase with future developments.

Paul

[LitusSaxonicum]

John C,

Those English computers with wierd precisions, always used 24 bit words, which meant that a REAL was 48 bits. UK programmers could get FE software to work in single precision. Equivalent US computers (except for CDC) got to 30, 32 or 36 bit REALs - nowhere near good enough for much FE work, and much more variable than machines of UK origin!

e.g. Elliot/NCR 4120/4130 - 24 bit
ICL 1900 series - 24 bit
ICL 2900 series - same
Ferranti Atlas? (48-bit single precision)

ICL 1900 Fortran (66) had an interesting couple of concepts: Statement No zero (meaning the next executable statement) and used in Arithmetic IF, together with zero length fields in input formats (e.g. I0, F0.0 etc) with similar functionality to Fortran-77 "formatless" list-directed input. The minute you started using those features, however, you were locked into that compiler.

I used IBM 1130 with 16-bit words (32 bit REAL) and Univac 1100 computers with 36 bit REAL.

Eddie

[JohnHorspool]

Thanks Eddie, I think you may have explained why after migrating from an ICL 1900 to a VAX we could never exactly replicate the old computers output

I very quickly learnt to only use double precision on the VAX.

[JohnCampbell]

Eddie,

When I first started work, I refused to use the IBM 1130, but insisted on using a Prime. I remember there were no logical if statements.

In mid 80's, I once had to transfer code onto an IBM mainframe (forgotten the number). I learnt how backward IBM was in comparison to then Prime/Vax for engineering computing. The IBM Fortran imposed a lot of constraints on what could be assumed from the Fortran 77 standard, with anything good that was vender dependant was not in their compiler, especially for I/O errors. I'm sure IBM had considerable influence on what capabilities were partially excluded from the F77 standard. Interactive graphics also gave particular problems for easy implementation.

I never used "double precision", I always used real*8. I'm not so confident about 48-bit precision as I would have a few finite element shell examples where 48-bit:"real*6" would have problems, although I could do with that in a project I am working on now. Who would have thought that 2gb would have been a memory limit ! Lately I've become accustomed to instant computing, with minimal I/O delays.

John

[PaulLaidler]

For the next release I have improved the compiler's response to the option ALT_KINDS so that the following code will work as expected.

[PaulLaidler]

I have done some further work on this so that even dynamic calls to selected_int_kind etc (i.e. calls to the library at run time) will be sensitive to ALT_KINDS. This rarely happens. When the arguments are constant the compiler evaluates these calls at compile time.