specifying type of constant in floating-point initialization expression

Hello,

On 2012-04-08 21:14:23 +0000, Richard Maine said:

> Isolation of nonportable things is one of the most important principles
> in writing code that is easy to port and maintain.

Many compilers (well, ifort and gfortran JOTTOMH) support
the f08 iso_fortran_env constants real32, real64, and real128.
They are portable and precise.

If you don't like the names, just rename on the use statement.

use, intrinsic :: iso_fortran_env, only: my_better_name => real64

--
Cheers!

Dan Nagle

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
> > In article <jls1pv$crf$1@dont-email.me>, "James Van Buskirk" wrote:
>
> (snip)
> >> >> DOUBLE PRECISION, PARAMETER :: A = 123456789
>
> >> > There are 9 significant digits here, which is more than
> >> > a single precision quantity supports.
>
> >> But A will be defined correctly nonetheless.
>
> > Correct to DP or correct to SP? Some compilers make it
> > correct to DP, but what does the standard guarantee?
>
> The integer constant should convert directly to double
> precision without an intermediate single precision.
>
> In that past, I do remember systems with 16 bit integer,
> and 32 and 64 bit floating point. In that case, the integer
> constant would overflow.

Not that the Fortran standard has always required that default integer
takes the same storage as a real. Did those systems waste the additional
16 bits, or was the default Fortran integer size different from that of
C's int, or were they non-conforming?

>
> If you put enough digits on you can overflow the integer type,
> but still be within the floating point representation.
>
> -- glen


--
Bill Clodius
los the lost and net the pet to email

On 4/8/2012 10:28 AM, Richard Maine wrote:
> glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:
>
>> Phillip Helbig---undress to reply<helbig@astro.multiclothesvax.de> wrote:
>>> In article<jls1pv$crf$1@dont-email.me>, "James Van Buskirk" wrote:
>>
>> (snip)
>>>>>> DOUBLE PRECISION, PARAMETER :: A = 123456789
>>
>>>>> There are 9 significant digits here, which is more than
>>>>> a single precision quantity supports.
>>
>>>> But A will be defined correctly nonetheless.
>>
>>> Correct to DP or correct to SP? Some compilers make it
>>> correct to DP, but what does the standard guarantee?
>>
>> The integer constant should convert directly to double
>> precision without an intermediate single precision.
>
> Yes. Single precision is irrelevant here. There is no single precision
> in sight. I would expect this to be done exactly. If you are asking
> about guarantees, though, that's a different matter. The standard has
> pretty much no guarantees relating to the accuracy of floating point
> computations, including the computation involved in converting from
> integer. All the standard does is define the operation to be done. In
> this case, that operation is conversion from integer to double precision
> real.
>

Some of us have been wondering whether real(integervalue, kind(0d0))
should be required for accurate conversion in place of
dble(integervalue), as it seems to be with certain compilers.
Richard seems to be saying we might expect dble() to convert as
accurately, but we have "no guarantee."

--
Tim Prince

Tim Prince <tprince@computer.org> wrote:

(snip, Richard wrote)
>> Yes. Single precision is irrelevant here. There is no single precision
>> in sight. I would expect this to be done exactly. If you are asking
>> about guarantees, though, that's a different matter. The standard has
>> pretty much no guarantees relating to the accuracy of floating point
>> computations, including the computation involved in converting from
>> integer. All the standard does is define the operation to be done. In
>> this case, that operation is conversion from integer to double precision
>> real.

> Some of us have been wondering whether real(integervalue, kind(0d0))
> should be required for accurate conversion in place of
> dble(integervalue), as it seems to be with certain compilers.

The traditional DBLE expected a REAL argument. DFLOAT is for conversion
of integer to double precision.

> Richard seems to be saying we might expect dble() to convert as
> accurately, but we have "no guarantee."

Yes, the standard makes very little guarantee about floating
point, but there is always "quality of implementation."

-- glen

William Clodius <wclodius@lost-alamos.pet> wrote:

(snip, I wrote)
>> The integer constant should convert directly to double
>> precision without an intermediate single precision.

>> In that past, I do remember systems with 16 bit integer,
>> and 32 and 64 bit floating point. In that case, the integer
>> constant would overflow.

> Not that the Fortran standard has always required that default integer
> takes the same storage as a real. Did those systems waste the additional
> 16 bits, or was the default Fortran integer size different from that of
> C's int, or were they non-conforming?

If you go back to the 704 and successors, 36 bit words used
for either floating point or 16 bit (sign magnitude) integers,
then they were the same size.

Many of the 16 bit minicomputers, such as the PDP-11, DG Eclipse,
and such, normally did not follow that part of the standard by
default, though likely would as a compile time option.

>> If you put enough digits on you can overflow the integer type,
>> but still be within the floating point representation.

-- glen

In article <jlspg6$f99$1@online.de>,
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to
reply) wrote:

> > There are many problems with that approach, for example, when you
> > use constants in your code, particularly as actual arguments in
> > subroutine calls. With the KIND approach, you can write your
> > million-line code so that the precisions used throughout the entire
> > program can be changed by modifying a single line of code. That is
> > essentially impossible if you use REAL and DOUBLE PRECISION
> > declarations, and it can be very difficult to determine how
> > expressions with constants (no exponent, E exponent, and D exponent)
> > should be changed.
>
> I agree, and certainly this approach has its advantages. However, it
> means using named constants like THREE, PITHIRD or whatever or having
> literal constants with an explicit type (which should be a named
> constant of course). Also, changing just the precision and nothing else
> to solve some problem is probably a rare case.
>
> Certainly it makes little sense to jump through the hoops to end up with
> SP and DP as names for kinds. :-( But people do this.

Consider the following call statements.

call sub(1.0)
call sub(1.0_wp)

Now what do you do when you want to change precisions? In the first
case you need to change it to

call sub(1.0D0)

In the second case, you don't have to do anything. You don't need
to touch that line of code at all. Once the KIND parameter is set,
the conversion is automatic.

Now, consider locating every line of code like that in a large
program.

Contrary to your assertion above, it makes a lot of sense to use the
KIND parameter. That is why people do it, even on machines that
support only two precisions. Most of the popular machines now
support three or four precisions. Then it makes even more sense to
use KIND parameters in expressions, actual arguments, etc.

$.02 -Ron Shepard

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> In article <jlspg6$f99$1@online.de>,
> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to
> reply) wrote:


(snip)
>> Certainly it makes little sense to jump through the hoops to
>> end up with SP and DP as names for kinds. :-( But people do this.

> Consider the following call statements.

> call sub(1.0)
> call sub(1.0_wp)

> Now what do you do when you want to change precisions?
> In the first case you need to change it to

> call sub(1.0D0)

> In the second case, you don't have to do anything. You don't need
> to touch that line of code at all. Once the KIND parameter is set,
> the conversion is automatic.

Not counting rewriting subroutine sub, maybe written by someone
else, maybe using KIND, maybe not. Maybe using different symbolic
names for the kinds it does use.

> Now, consider locating every line of code like that in a large
> program.

Now consider that your program calls 20 other subroutines,
written by 20 other people. Some used KIND, some didn't.
Some algorithms need to adapt to the precision being used,
such as computing new coefficients for polynomial expansions.

> Contrary to your assertion above, it makes a lot of sense to use the
> KIND parameter. That is why people do it, even on machines that
> support only two precisions. Most of the popular machines now
> support three or four precisions. Then it makes even more sense to
> use KIND parameters in expressions, actual arguments, etc.

Many have architectural support for more precisions, but don't
implement them in hardware. Very few do it in hardware.

-- glen

> Many compilers (well, ifort and gfortran JOTTOMH) support
> the f08 iso_fortran_env constants real32, real64, and real128.
> They are portable and precise.
>
> If you don't like the names, just rename on the use statement.
>
> use, intrinsic :: iso_fortran_env, only: my_better_name => real64
>

This looks great! However: on gfortran, this works for me. On Cray as
well. On intel fortran, I get errors - see below. Are you sure this
works on ifort? Perhaps my ifort version is out of date?

Paul


~/Iso_kind_parameters $ cat iso.f90
program f90real
use, intrinsic :: iso_fortran_env, only: real32, real64
implicit none
integer, parameter :: sp = real32
integer, parameter :: dp = real64
print *, 'Single precision:', sp
print *, 'Double precision:', dp
end program f90real

~/Iso_kind_parameters $ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler Professional for applications
running on Intel(R) 64, Version 11.1 Build 20091012 Package ID:
l_cprof_p_11.1.059
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

~/Iso_kind_parameters $ ifort iso.f90
iso.f90(2): error #6580: Name in only-list does not exist. [REAL32]
use, intrinsic :: iso_fortran_env, only: real32, real64
---------------------------------------------^
iso.f90(2): error #6580: Name in only-list does not exist. [REAL64]
use, intrinsic :: iso_fortran_env, only: real32, real64
-----------------------------------------------------^
iso.f90(4): error #6592: This symbol must be a defined parameter, an
enumerator, or an argument of an inquiry function that evaluates to a
compile-time constant. [REAL32]
integer, parameter :: sp = real32
-------------------------------^
iso.f90(5): error #6592: This symbol must be a defined parameter, an
enumerator, or an argument of an inquiry function that evaluates to a
compile-time constant. [REAL64]
integer, parameter :: dp = real64
-------------------------------^
compilation aborted for iso.f90 (code 1)

In article <jlu1ra$3ni$1@dont-email.me>, Paul Anton Letnes
<paul.anton.letnes@nospam.gmail.kthxbai.com> writes:

> ~/Iso_kind_parameters $ cat iso.f90
> program f90real
> use, intrinsic :: iso_fortran_env, only: real32, real64
> implicit none
> integer, parameter :: sp = real32
> integer, parameter :: dp = real64
> print *, 'Single precision:', sp
> print *, 'Double precision:', dp
> end program f90real

I understand the issues involved and perhaps Richard has convinced me to
use KIND. However, since the whole point is flexibility, calling them
"sp" and "dp" seems rather lame. Maybe one changes the definition, so
that "sp" now corresponds to DOUBLE PRECISION. Yes, easier to change in
one place, but anyone reading the code will associate a precision with
this name, which is what one is trying to avoid. So if going this route
I would suggest better names.

On 09.04.12 10:27, Phillip Helbig---undress to reply wrote:
> In article<jlu1ra$3ni$1@dont-email.me>, Paul Anton Letnes
> <paul.anton.letnes@nospam.gmail.kthxbai.com> writes:
>
>> ~/Iso_kind_parameters $ cat iso.f90
>> program f90real
>> use, intrinsic :: iso_fortran_env, only: real32, real64
>> implicit none
>> integer, parameter :: sp = real32
>> integer, parameter :: dp = real64
>> print *, 'Single precision:', sp
>> print *, 'Double precision:', dp
>> end program f90real
>
> I understand the issues involved and perhaps Richard has convinced me to
> use KIND. However, since the whole point is flexibility, calling them
> "sp" and "dp" seems rather lame. Maybe one changes the definition, so
> that "sp" now corresponds to DOUBLE PRECISION. Yes, easier to change in
> one place, but anyone reading the code will associate a precision with
> this name, which is what one is trying to avoid. So if going this route
> I would suggest better names.

I was merely asking why the program doesn't compile and run under ifort,
as someone claimed it would. I use 'wp' (working precision) myself, in
most cases. Alternatively I define wp1 and wp2, so I can separately
adjust the precision of intermediate calculations and e.g. storage,
where double precision may not be needed.

Paul

Hello,

On 2012-04-09 07:07:21 +0000, Paul Anton Letnes said:
>
> ~/Iso_kind_parameters $ ifort -V
> Intel(R) Fortran Intel(R) 64 Compiler Professional for applications
> running on Intel(R) 64, Version 11.1 Build 20091012 Package ID:
> l_cprof_p_11.1.059
> Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

Try ifort 12.1; 2009 is three years old now. :-)
Fortran 2008 hadn't been formally published (the content was known).
(gfortran as of 4.6.2 anyway, nagfor as of 5.3)

I was lukewarm when this was proposed in J3, but it has become
one of the most-used features for me. It's a set-and-forget feature.

--
Cheers!

Dan Nagle

On 09.04.12 13:07, Dan Nagle wrote:
> Hello,
>
> On 2012-04-09 07:07:21 +0000, Paul Anton Letnes said:
>>
>> ~/Iso_kind_parameters $ ifort -V
>> Intel(R) Fortran Intel(R) 64 Compiler Professional for applications
>> running on Intel(R) 64, Version 11.1 Build 20091012 Package ID:
>> l_cprof_p_11.1.059
>> Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
>
> Try ifort 12.1; 2009 is three years old now. :-)
> Fortran 2008 hadn't been formally published (the content was known).
> (gfortran as of 4.6.2 anyway, nagfor as of 5.3)
>
> I was lukewarm when this was proposed in J3, but it has become
> one of the most-used features for me. It's a set-and-forget feature.

Thanks for letting me know. Not sure if it's feasible to upgrade the
compiler, though.

Paul

Paul Anton Letnes <paul.anton.letnes@nospam.gmail.kthxbai.com> wrote:

> On 09.04.12 13:07, Dan Nagle wrote:
> > Hello,
> >
> > On 2012-04-09 07:07:21 +0000, Paul Anton Letnes said:
> >>
> >> ~/Iso_kind_parameters $ ifort -V
> >> Intel(R) Fortran Intel(R) 64 Compiler Professional for applications
> >> running on Intel(R) 64, Version 11.1 Build 20091012 Package ID:
> >> l_cprof_p_11.1.059
> >> Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
> >
> > Try ifort 12.1; 2009 is three years old now. :-)
> > Fortran 2008 hadn't been formally published (the content was known).
> > (gfortran as of 4.6.2 anyway, nagfor as of 5.3)
> >
> > I was lukewarm when this was proposed in J3, but it has become
> > one of the most-used features for me. It's a set-and-forget feature.

I was really hot for it, just because it is so much simpler to explain
to a new user than selected_real_kind. It makes the entry barrier lower
for those new users. Most users can tell you pretty quickly whether they
want a 32-bit or 64-bit real - a lot more quickly than they can tell you
how many decimal digits of precision they need. Yes, I know that, in
theory, one ought to have a detailed numerical analysis of the
requirements. But that ain't what happens in practice in 99% of the
cases. (That number being invented out of thin air, like 99% of the
statistics people cite. :-)). There are plenty who haven't thought about
the matter of precision at all, even needing it explained that precision
is finite. After people get past that, they can usually tell you whether
they want 32-bit or 64-bit precision.
>
> Thanks for letting me know. Not sure if it's feasible to upgrade the
> compiler, though.

Note that, for the user sophisticated enough to specify a kind using
either selected_real_kind, or even just a hard-wired, compiler-specific
kind number (which ought to inclde any of the users in this discusion),
it is easy enough to cope with lack of compiler support. Write your own
module of just a few lines, like many of us do today. USE that module
instead of iso_fortran_environment. Provided you are sufficiently
consistent about the form of the USE statement, you could make it a
simple sed (or comparable tool) operation to change all the USEs. Or for
better isolation of the dependence until you can just count on compiler
support being not only available, but also installed everywhere
important to you, always USE your own module, but have it be a wrapper
for iso_fortran_environment.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

In article <1ki9wpj.1ercdcl1wdmwdeN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> I was really hot for it, just because it is so much simpler to explain
> to a new user than selected_real_kind. It makes the entry barrier lower
> for those new users. Most users can tell you pretty quickly whether they
> want a 32-bit or 64-bit real - a lot more quickly than they can tell you
> how many decimal digits of precision they need. Yes, I know that, in
> theory, one ought to have a detailed numerical analysis of the
> requirements. But that ain't what happens in practice in 99% of the
> cases.

This is the origin of my "opposition" to SELECTED_REAL_KIND. If the
results are just other words for REAL and DOUBLE PRECISION, then it is
clearer to just use them. Yes, more trouble to change, but if the
analysis is just more or less precision, rather than something more
precise, then presumably one wouldn't change the declarations anyway.

> After people get past that, they can usually tell you whether
> they want 32-bit or 64-bit precision.

Are there still any compilers with types with the same number of bits
but differently split between mantissa and exponent (like on the VAX)?

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <1ki9wpj.1ercdcl1wdmwdeN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes:

> > After people get past that, they can usually tell you whether
> > they want 32-bit or 64-bit precision.
>
> Are there still any compilers with types with the same number of bits
> but differently split between mantissa and exponent (like on the VAX)?

Not to my knowledge. I am aware of the VAX case, but I can't cite any
others quite like that.

Perhaps more likely might be kinds with binary and decimal radix using
the same number of bits. I don't see any compilers where that issue
comes up today, but that's one I could well see happening in the future.
There are things happening in that direction already, but just not yet
at the level where you actually have a Fortran compiler with kinds for
both cases.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain