 |
 |
On Apr 3, 2017, at 5:37 PM, Vipul Parekh <[log in to unmask]> wrote:
Thanks much, Bill and Tom, for your replies.
My apologies if this sounds silly to you all to bring this up, but I'm quite confused: as you can see in the blog, Steve Lionel states, "My advice is to not use those constants ..", he laments the standard only stipulates the storage size and says nothing about the range or precision of the type.
So I'm wondering again if such constants are being introduced well into the new millenium, does anyone what prevented the standard from characterizing more deeply in terms of the properties, say in consistency with modern computers?
Alternately, does it make sense to introduce to introduce a few new constants, binary64, binary128 (and binary256, binary518, binary16, binary32), either natively or as part of IEEE_ARITHMETIC intrinsic module to define KINDs a processor can represent on a given architecture per IEEE-754 standard**?
It will be rather useful for many coders of Fortran, especially beginning and casual, to simply do:
-- begin snippet --real(binary64) :: x ! KIND of x exactly matches binary64 representation from IEEE-754 standard..x = ..-- end snippet --
or-- begin snippet --use ieee_arithmetic, only : binary64, ....real(binary64) :: x ! KIND of x exactly matches binary64 representation from IEEE-754 standard..x = ..-- end snippet --
because as Tom suggests, it does get overwhelming for beginners and casual coders to deal with SELECTED_REAL_KIND and if they then see blogs such as the one above, it is added cause for confusion.
I propose the new named constants of binaryNN with the assumption that REALNN from ISO_FORTRAN_ENV are now "untouchable"; if that's not the case and the option exists to *refine* the REALNN named constants from ISO_FORTRAN_ENV in a future standard (the one after Fortran 2015) to include precise wording on their properties too, then that should suffice.
* e.g., a precision of 15 and a range of 307 for REAL64 which I assume is what most implementations likely provide anyway; analogously for REAL32 andREAL128.It will be good if the standards committee could keep this in mind, especially because the default REAL in the standard falls short in terms of precision for all but the simplest of floating point needs.
Regards,Vipul
On Mon, Apr 3, 2017 at 4:41 PM, Clune, Thomas L. (GSFC-6101) <[log in to unmask]> wrote:
As someone working with a large model ( O(10^6) sloc ), I have found that using these named constants provides 2 major advantages over the SELECTED_REAL_KIND() approach. First, the intent is much more obvious. Yes, the parameters to the intrinsic let you figure out that on an IEEE machine this expression will give you 32 bits:
integer, parameter :: sp = selected_real_kind(6, 37)
But it is far from obvious compared to REAL32.
The second more subtle advantage is that there is then the one “right” way to do this in the code. Otherwise everyone either invents their own named parameters for these things or randomly uses some other module that kindly made such a parameter public. Again, not the worst thing in legacy code, but the variations do slow developers down to a small degree.
And Bill, yes - there’s lots of REAL*4 and REAL*8 in NASA codes. I’ve generally basished them from infrastructure layers of models that I support, but am a ways off from eliminating them from the more numerical physics layers. A bigger target for me is the use of the -r8 flag is some of our Makefiles. (shudder)
Cheers,
- Tom
> On Apr 3, 2017, at 4:24 PM, Bill Long <[log in to unmask]> wrote:
>
> The REAL32, REAL64, and REAL128 constants, as we as INT8, INT16, INT32, and INT64 constants for integers, were added as a convenience for users. "The requirement is to provide a simplified means to select the most commonly desired real and integer kinds.” It is far better than the old *n form because these constants can be used in standard-conforming statements. The constants also provide useful information in that negative values indicate that the particular KIND is not supported.
>
> I would hope that REAL*n is no longer in “widespread usage”. Although I do still see the archaic CHARACTER*n being used, instead of the more modern CHARACTER(n).
>
> Cheers,
> Bill
>
>
> On Apr 3, 2017, at 11:00 AM, Vipul Parekh <[log in to unmask]> wrote:
>
>> Steve Lionel, previously at Intel, pointed out in a recent blogpost at http://intel.ly/2nZSxoE) that "Fortran 2008 extended intrinsic module ISO_FORTRAN_ENV to include named constants .. REAL32, REAL64 and REAL128 whose values correspond to the kinds of real .. that occupy the stated number of bits. .. In my view, this is little better than the old *n extension in that it tells you that a type fits in that many bits, but nothing else about it."
>>
>> So I'm just curious as to why as recently as Fortran 2008, something gets introduced into the standard whose value or use case seems unclear. Would anybody on this mailing list know that the standards committee had in mind i.e., what were the use case(s), say, for REAL64 and REAL128 when they introduced to the ISO_FORTRAN_ENV intrinsic module? Were they added to address somehow the widespread usage of REAL*n constructs and if so, how did the committee hope that would materialize?
>>
>> Any feedback is appreciated.
>>
>> Best Regards,
>> Vipul Parekh
>>
>>
>
> Bill Long [log in to unmask]
> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9143
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425