Would more descriptive names, like IEEE_BINARY32_KIND, be OK? Names of entities in the IEEE modules typically start with IEEE_. Seems like a straightforward feature for the next standard. And easy to implement in the module.
On Apr 7, 2017, at 5:07 PM, Vipul Parekh <[log in to unmask]> wrote:
> Tom, Van:
>
> Thanks much for your feedback, very helpful.
>
> This discussion has revealed quite a few options but nothing that seems sufficiently clear for our purposes in industry where the powers-that-be (and the IT departments that serve them) have resolved to do all the computing using IEEE 754 and the situation will remain so for the foreseeable future.
>
> So I seek your input on the following, oneI had brought up earlier. What would prevent the Fortran standard from making the lives of coders working exclusively with IEEE floating-point arithmetic easier with a 5th option?! Say a few named constants in IEEE_ARITHMETIC intrinsic module such as BINARY32, BINARY64, BINARY128 that *precisely match the floating-point format parameters (e.g,, Table 3.2) in IEEE Std 754™-2008* standard . Then with the overload example under discussion, one can simply do:
>
>
> Option 5:
> function F_s ( X )
> use ieee_arithmetic , only :: RK => BINARY32
> …
> end function F_s
>
> function F_d ( X )
> use ieee_arithmetic, only :: RK => BINARY64
> …
> end function F_d
>
> function F_q ( X )
> use ieee_arithmetic, only :: RK => BINARY128
> …
> end function F_q
>
>
> This will allow tus to ensure far more easily that all the coders, the library developers and the consumers of the libraries, have a consistent way to define the floating-point types in an intrinsic manner i.e., based on an intrinsic module. Currently, every programming group does its *own* thing and comes with its own solution (say their own KINDS module) that essentially strives to match the 3 floating-point formats specified in the IEEE 754 standard. It's a lot of needless effort for us and a real pain to ensure consistency and a lot of it get managed in questionable ways.
>
> As you can surmise, an overwhelming majority of the floating-point computations and simulations are performed with the equivalent of binary64 but there are a few instances where either binary128 (this may be a somewhat increasing fraction) or binary32 (for legacy support) are needed. And we would like to overload our *library* methods with specific procedures with the KINDs that handle the 3 format parameters from IEEE 754. We would then mostly ignore the other 4 options and have simplicity and clarity in our code.
>
> Can the Fortran standard not serve us so? It's only a handful of named constants that should have no impact on the underlying type system, they should be trivial to introduce but they can prove to be so useful to us. And it is only a change to the IEEE_ARITHMETIC intrinsic so it needn't come in the way of anything with Fortran's legacy nor the general considerations and constraints that weigh down every other proposal so heavily.
>
> Regards,
> Vipul
>
> * https://standards.ieee.org/findstds/standard/754-2008.html
>
> On Thu, Apr 6, 2017 at 12:49 PM, Clune, Thomas L. (GSFC-6101) <[log in to unmask]> wrote:
> Well stated question and it raises several thoughts. But let me first add:
>
>
> Option 4:
> function F_s ( X )
> use iso_c_binding , only :: RK => C_FLOAT
> …
> end function F_s
>
> function F_d ( X )
> use iso_c_binding , only :: RK => C_DOUBLE
> …
> end function F_s
>
> Presuming that there is an overloaded interface involved somewhere, then I think the following observations hold:
>
> • Only option 3 is guaranteed to compile. The standard requires 1.0e0 and 1.d0 to be supported _and_ of _distinct_ kind.
> • Option 1 can fail because either or both of REAL32, REAL64 may return -1 on some platforms
> • Option 2 can fail because SELECTED_REAL_KIND() could return the same kind on some processor, making the overload illegal.
> • I suppose they also could fail if you if the machine only supported lower precisions/ranges than requested.
> • Option 4 can fail because it is not required that there be a companion C processor.
>
> Now since all of these will actually work on existing platforms with F2008 support, the real question is how likely is there to be a future system in which some of options (1,2,4) would fail?
>
> But before you hastily conclude that option 3 is the way to go, consider that a future machine might _change_ the original intent. E.g., what if a new machine came out with 64 bit precision for default real and 128 bit for default double. Further, suppose that the machine did still have a kind for 32 bit IEEE. In that case, 3 would compile but would not link with code that used methods (1,2,4) for selecting their precisions.
>
> Nothing is easy. :-(
>
>
>
>
>
>> On Apr 6, 2017, at 11:28 AM, Vipul Parekh <[log in to unmask]> wrote:
>>
>> Van,
>>
>> Is the use of KIND(1.0e0) and KIND(1.0d0) just as 'portable' as SELECTED_REAL_KIND? My reading and experience suggest otherwise, but I may be wrong. Can you please share your views?
>>
>> More specifically, consider the following from the scenario you presented involving some generics: the blog in question (the one I mentioned in the first note) effectively considered 2 of these options and emphatically states SELECTED_REAL_KIND is what coders should use. What do you say and why? Thanks,
>>
>> Option 1: begin --
>> ..
>> function F_s( X )
>> use ISO_FORTRAN_ENV, only : RK => REAL32
>> ..
>> end function F_s
>> ..
>> function F_d( X )
>> use ISO_FORTRAN_ENV, only : RK => REAL64
>> ..
>> end function F_s
>> -- end Option 1 --
>>
>> Option 2: begin --
>> ..
>> function F_s( X )
>> integer, parameter :: RK = SELECTED_REAL_KIND( p=N_s, r=M_s ) ! N_s and M_s are arbitrary values for single precision
>> ! e.g., 6, 37
>> ..
>> end function F_s
>> ..
>> function F_d( X )
>> integer, parameter :: RK = SELECTED_REAL_KIND( p=N_d, r= M_d ) ! N_s and M_d are arbitrary values for single precision
>> ! e.g., 15, 307
>> ..
>> end function F_s
>> -- end Option 2 --
>>
>> Option 3: begin --
>> ..
>> function F_s( X )
>> integer, parameter :: RK = KIND(1.0e0)
>> ..
>> end function F_s
>> ..
>> function F_d( X )
>> integer, parameter :: RK = KIND(1.0d0)
>> ..
>> end function F_s
>> -- end Option 3 --
>>
>> So do you really prefer Option 3 from above? If so,
>> 1) Why?
>> 2) What would you do if you needed extended precision, say the equivalent of binary128 from IEEE 754 standard?
>>
>> Thanks,
>> Vipul
>>
>>
>> On Thu, Apr 6, 2017 at 2:43 AM, Van Snyder <[log in to unmask]> wrote:
>> On Wed, 2017-04-05 at 11:29 +0200, Phillip Helbig wrote:
>> > I understand the motivation for KIND. However, many people use
>> > SELECTED_REAL_KIND with 1.0D0 or whatever to find the
>> > "double-precision KIND". Why not just write DOUBLE PRECISION if that
>> > is what you mean?
>>
>> I use INCLUDE as a poor-man's substitute for generic programming.
>>
>> I use a kind type parameter to specialize a function to default real or
>> double precision, to produce a generic interface, like this:
>>
>> interface F
>> module procedure F_d, F_s
>> end interface
>> ...
>> function F_d ( X )
>> integer, parameter :: RK = kind(1.0d0)
>> include "F_body.f9h"
>> end function F_d
>>
>> function F_s ( X )
>> integer, parameter :: RK = kind(1.0e0)
>> include "F_body.f9h"
>> end function F_s
>>
>> with F_body.f9h containing
>>
>> ! function F_* ( X )
>> real(rk) :: F
>> real(rk), intent(in) :: F
>> ...
>>
>> This doesn't work if I use DOUBLE PRECISION.
>>
>
>
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
|
