Confusion about kinds in FORTRAN

Question

I have been in the process of writing a FORTRAN code for numerical simulations of an applied physics problem for more than two years and I've tried to follow the conventions described in Fortran Best Practices.

More specifically, I defined a parameter as

integer, parameter:: dp=kind(0.d0)

and then used it for all doubles in my code.

However, I found out (on this forum) that using KIND parameters not necessarily gives you the same precision if you compile your code using other compilers. In this question, I read that a possible solution is using the SELECTED_REAL_KIND and SELECTED_INT_KIND, which follow some convention, as far as I understand.

Later on, though, I found out about the ISO_FORTRAN_ENV module which defines the REAL32, REAL64 and REAL128 KIND parameters.

I guess that these are indeed portable and, since they belong to the FORTRAN 2008 standard (though supported by GNU), I guess that I should use these?

Therefore, I would greatly appreciate if someone with more knowledge and experience clear up the confusion.

Also, I have a follow-up question about using these KINDs, in HDF5. I was using H5T_NATIVE_DOUBLE and it was indeed working fine (as far as I know) However, in this document it is stated that this is now an obsolete feature and should not be used. In stead, they provide a function

INTEGER(HID_T) FUNCTION h5kind_to_type(kind, flag) RESULT(h5_type) .

When I use it, and print out the exact numerical value of the HID_T integer corresponding to REAL64 gives me 50331972, whereas H5T_NATIVE_DOUBLE gives me 50331963, which is different.

If I then try to use the value calculated by H5kind_to_type, the HDF5 library runs just as fine and, using XDMF, I can plot the output in VisIt or Paraview without modifying the accompanying .xmf file.

So my second question would be (again): Is this correct usage?

I think it is a scandal how cumbersome it is in Fortran to guarantee that a floating point variable has 8 bytes. Are we really supposed to load a module every single time we declare a floating-point variable, or type out some longish commands? I fell in a similar trap as you and thought that real(8) specifies an 8-byte floating-point number. Now I use real*8, which unlike real(8) is portable. It's not part of the Fortran standard, but practically understood by every compiler. — Norbert S, Feb 19 '17 at 03:56

Vladimir F Героям слава · Accepted Answer · 2015-05-04T19:02:20.533

6

The type double precision and the corresponding kind kind(1.d0) are perfectly well defined by the standard. But they are also not exactly fixed. Indeed there were many computers in history and use different kind of native formats for their floating point numbers and the standard must allow this!

So, a double precision is a kind of real which has a higher enough precision than the default real. The default real is also not fixed, it must correspond to what the computers can use.

Now today we have the standard for floating point numbers IEEE_754 which defines IEEE single (binary32) and IEEE double types (binary64) and some others. If the computer hardware implements this standard, as almost all computers younger than 20 years do, it is very likely that the compiler chooses these two as the real and double precision.

The Fortran 2008 standard brings the two kind constants real32 and real64 (and others). They enable you to request the real kinds which have storage size of 32 and 64 bits. It is not guaranteed it will be the IEEE types, but it is almost certain on modern computers.

To request the IEEE types (if they are available) use the intrinsic function ieee_selected_real_kind() from module ieee_arithmetic.

The IEEE types are the same an all computers (excluding endianness!), but the compiler is not required to support them, because you may have a computer which does not support these in hardware. This is only a theoretical possibility, all modern computers support them.

Now to your HDF constants, these are apparently just some indexes to some table, it does not matter if they are different or not, the important is whether they mean the same and in your case they do.

As I wrote above, it is extremely likely that on a computer which supports IEEE 754 the double precision will be identical to IEEE double. It may not be, if you use some compiler options which change this behaviour. There are compiler options which promote the default real to double and hey may also promote double precision to quad precision (128 bit) to preserve the standard semantics which requires the double precision to have more precision and storage size.

Conclusion: You can use both, or any other way to choose your kind constants (you can also use iso_c_binding's c_float and c_double), but you should be aware why are those ways different and what do they actually mean.

edited May 04 '15 at 19:02

answered May 04 '15 at 08:01

Vladimir F Героям слава

57,977
4
76
119

Thank you for the clarification. I will continue using REAL64 and REAL128 from ISO_FORTRAN_ENV as to me it appears best to adhere to the IEEE standard. I assume that the hardware supports it. – Toon May 04 '15 at 08:45
As far as I know you won't find any modern Fortran compiler for any computer that doesn't support IEEE 754. – Vladimir F Героям слава May 04 '15 at 08:48
As a word of caution, currently with gfortran `real128` actually refers to the kind of a 10-byte variable. With ifort it has the correct meaning of quad precision. – Raul Laasner May 04 '15 at 11:20
The gfortran manual states that `real128` uses a storage size of 128 bits. – M. S. B. May 04 '15 at 11:32
1

Whether the REALxx constants from ISO_FORTRAN_ENV map onto IEEE types is processor specific. If you want to "directly request" IEEE single and double then you need to use the facilities from the IEEE intrinsic modules. REAL32 on one processor may be different from REAL32 on another - all that is required to be the same is the storage size. – IanH May 04 '15 at 12:38
I was worried of something like that, but again, I don't believe there is any processor even in some niche research use, which wouldn't use the IEEE, but I will add the IEEE kinds to the answer. – Vladimir F Героям слава May 04 '15 at 12:40
I also forgot about endianness issues when claiming the ieee types are the same everywhere. – Vladimir F Героям слава May 04 '15 at 13:24
See [this bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153) for gfortran's definition of `real128`. – Stefan May 04 '15 at 18:39
Is there a typo in the conclusion? "but you should be aware why are _hose_ ways different" – John Alexiou May 04 '15 at 19:01
yes, thanks. You can also edit such mistakes directly. – Vladimir F Героям слава May 04 '15 at 19:02
@VladimirF Hi, VladimirF. I have a confusion. Is IEEE really matters? You said interpreting REAL32 to IEEE or not is processor dependent. But even if a computer makes non-IEEE interpretation, will the program gives a different running result compared to IEEE interpretation? – user15964 Mar 27 '16 at 04:28
@user15964 If the CPU you have in your computer uses non IEEE arithmetics, you will get different results. – Vladimir F Героям слава Mar 27 '16 at 10:48
@VladimirF But how different will they are? I suppose the difference should be negligible, right? – user15964 Mar 27 '16 at 11:26
@user15964 In a single calculation the differnce will be negligible. If you solve a chaotic system, the difference will build up in time (butterfly effect). – Vladimir F Героям слава Mar 27 '16 at 12:10
@VladimirF Oh, that is another story. The nature of chaos : ) – user15964 Mar 27 '16 at 12:30

Confusion about kinds in FORTRAN

1 Answers1