I understand that this

   DOUBLE PRECISION, PARAMETER :: X = 1.0D0/3.0D0

is better than

   DOUBLE PRECISION, PARAMETER :: X = 1.0/3.0

at least if the fraction (like here) is not exactly representable in 
floating point.

But is there any (numerical, not style) reason to prefer

   DOUBLE PRECISION, PARAMETER :: A = 123456789.0D0

to 

   DOUBLE PRECISION, PARAMETER :: A = 123456789

Hello,

On 2012-04-08 10:03:36 +0000, Phillip Helbig---undress to reply said:

> But is there any (numerical, not style) reason to prefer
> 
>    DOUBLE PRECISION, PARAMETER :: A = 123456789.0D0
> 
> to
> 
>    DOUBLE PRECISION, PARAMETER :: A = 123456789

There are 9 significant digits here, which is more than
a single precision quantity supports.

My stylistic preference is to eliminate double precision completely.
It isn't portable because it's tied to the definition
of a numeric storage unit.

I suggest

use, intrinsic :: iso_fortran_env, only: real64
! or rename real64 if you don't like the name

real( real64), parameter :: a = 123456789.0_real64

YMMV on style matters

-- 
Cheers!

Dan Nagle

"Dan Nagle" <danlnagle@me.com> wrote in message 
news:jls10g$96i$1@dont-email.me...

>>    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. :)

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <jls10g$96i$1@dont-email.me>, Dan Nagle <danlnagle@me.com>
writes: 

> > But is there any (numerical, not style) reason to prefer
> > 
> >    DOUBLE PRECISION, PARAMETER :: A = 123456789.0D0
> > 
> > to
> > 
> >    DOUBLE PRECISION, PARAMETER :: A = 123456789
> 
> There are 9 significant digits here, which is more than
> a single precision quantity supports.

Hence my question.  Some compilers give the same results for both, but 
presumably that is non-standard, hence my question.  Presumably it would 
be allowed to evaluate the RHS as default integer then give the LHS only 
the precision of the RHS.

(The difference between the above and 1.0/3.0 vs. 1.0D0/3.0D0 is that in
the latter case, 1.0/3.0 is first evaluated, resulting in a certain 
number of digits, then a conversion is performed, while in the second 
place the division is done in DP.  In other words, in the example above 
all the digits are available (as literals in the code) immediately 
before the conversion.)

In article <jls1pv$crf$1@dont-email.me>, "James Van Buskirk"
<not_valid@comcast.net> writes: 

> "Dan Nagle" <danlnagle@me.com> wrote in message 
> news:jls10g$96i$1@dont-email.me...
> 
> >>    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?

"Phillip Helbig---undress to reply" <helbig@astro.multiCLOTHESvax.de> wrote 
in message news:jls3ag$u15$2@online.de...

> In article <jls1pv$crf$1@dont-email.me>, "James Van Buskirk"
> <not_valid@comcast.net> writes:

>> "Dan Nagle" <danlnagle@me.com> wrote in message
>> news:jls10g$96i$1@dont-email.me...

>> >>    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?

Notice that the literal above was an integer so single precision is
irrelevant.  Given 32-bit default integers, even 1234567890 should
be represented exactly.  Hence the smiley.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

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.

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

-- glen

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.

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

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

>    DOUBLE PRECISION, PARAMETER :: A = 123456789

Oh yes, in my reply of a few minutes ago, I failed to note one other
thing - namely the subject line. There is no "floating-point
initialization expression" here. The only expression is an integer one.
That expression is used in a context that requires conversion of its
result into floating point, but the expression itself is integer. Recall
that, as always, the evaluation of an expression does not depend on
context.

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

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

> I understand that this
> 
>    DOUBLE PRECISION, PARAMETER :: X = 1.0D0/3.0D0
> 
> is better than
> 
>    DOUBLE PRECISION, PARAMETER :: X = 1.0/3.0

The two expressions are different.  Whether one is "better" depends 
on how the expressions are used.  For example, if one were 
interested in determining empirically the accuracy of single 
precision arithmetic, then the difference in the two expressions 
above is important, and the second would be "better" than the first.

The reason I mention this is that this used to be one of the common 
ways to determine the machine epsilon in f77 before the epsilon() 
intrinsic was in the language.  The floating point representation of 
the exact number 1/3 has alternating 1s and 0's, so a calculation 
like

   third = 1.0/3.0
   eps = 1.0 - 3.0 * third

would give the desired result (well, except for cases where third 
was stored in an extended-precision register).  Replacing those 
constant expressions with the double precision version on the 
right-hand-side would clearly be incorrect for this purpose.


> 
> at least if the fraction (like here) is not exactly representable in 
> floating point.
> 
> But is there any (numerical, not style) reason to prefer
> 
>    DOUBLE PRECISION, PARAMETER :: A = 123456789.0D0
> 
> to 
> 
>    DOUBLE PRECISION, PARAMETER :: A = 123456789

Sure, just add another couple of digits and one will error off at 
compile time and the other won't (at least on machines with 64-bit 
double precision and 32-bit integers).

BTW, I have found almost no place for the old fashioned DOUBLE 
PRECISION declarations in new code.  My problems all fit in the 
category where precision specified with KIND parameters is better.  
Of course I work on legacy code (mine and others) that use DOUBLE 
PRECISION declarations, so I need to know how it works, but that 
approach was always a bad fit to my kind of numerical problems to 
begin with.  The same goes for float, double, and long double in 
C-like languages.  In fact, I was someone who routinely used the 
REAL*8 style of declaration in old f77 code.  For me, it was more 
portable despite being nonstandard. You know there is a fundamental 
problem with a language specification when a nonstandard approach is 
more portable than the standard approach, but that is the way f77 
was.  F90 fixed this with KIND parameters, so it always seems 
strange to see new code regress to the old flawed style of 
declarations, or modern languages that still require that kind of 
approach.

$.02 -Ron Shepard

In article <ron-shepard-6275D0.11281208042012@news60.forteinc.com>, Ron
Shepard <ron-shepard@NOSPAM.comcast.net> writes: 

Thanks to all for the comments in this thread.

> BTW, I have found almost no place for the old fashioned DOUBLE 
> PRECISION declarations in new code.  

I agree that the new paradigm is more flexible.  However, probably well 
over 90% of the code which uses it jumps through some hoops to define 
some named constants used for declarations but what it essentially 
results in is a single-precision type and a double-precision type.  In 
such cases, it is clearer to just use REAL and DOUBLE PRECISION.

I have had examples of routines where input and output parameters are
well within the single-precision range, both in terms of magnitude and
in terms of precision---numbers for which 3 or 4 digits of precision is
enough with a range between a thousandth and a thousand, say.  However,
if the routine which calculates the output based on the input is
single-precision, then numerical problems occur, such as when an
expression is analytically zero but numerically not or vice-versa, due
to roundoff issues.  Converting the input variables to double-precision
and doing calculations with those (and converting to single-precision on
output) fixes things.  An analysis to determine the minimum precision
required would be quite involved and in practice would result in
double-precision anyway.

In article <jlsfom$77p$2@online.de>,
 helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
 reply) wrote:

> In article <ron-shepard-6275D0.11281208042012@news60.forteinc.com>, Ron
> Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> 
> Thanks to all for the comments in this thread.
> 
> > BTW, I have found almost no place for the old fashioned DOUBLE 
> > PRECISION declarations in new code.  
> 
> I agree that the new paradigm is more flexible.  However, probably well 
> over 90% of the code which uses it jumps through some hoops to define 
> some named constants used for declarations but what it essentially 
> results in is a single-precision type and a double-precision type.

Of course, that must be the final result if the compiler supports 
only those two data types.

>  In 
> such cases, it is clearer to just use REAL and DOUBLE PRECISION.

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 have had examples of routines where input and output parameters are
> well within the single-precision range, both in terms of magnitude and
> in terms of precision---numbers for which 3 or 4 digits of precision is
> enough with a range between a thousandth and a thousand, say.  However,
> if the routine which calculates the output based on the input is
> single-precision, then numerical problems occur, such as when an
> expression is analytically zero but numerically not or vice-versa, due
> to roundoff issues.

Yes, I agree, but this has little to do with the language.  This is 
a general feature of finite-precision floating point arithmetic.  
The same comments would apply if you were writing code in assembler. 
How this is addressed in the language is the important issue.

>  Converting the input variables to double-precision
> and doing calculations with those (and converting to single-precision on
> output) fixes things. 

That might be one way.  You can also change the way intermediate 
expressions are evaluated, you can change the overall algorithm, and 
so on.  The entire field of numerical analysis addresses these 
problems.

> An analysis to determine the minimum precision
> required would be quite involved and in practice would result in
> double-precision anyway.

Sometimes, but not necessarily.  A good example might be 
least-squares solutions for problems with large condition numbers.  
If you solve them with the normal equations, the condition number is 
the square of the condition number when the solution is obtained 
with factorization.  With your approach, the "answer" would be to 
solve the normal equations in double precision, and then convert the 
answer back at the end.  But that is not necessary. You can solve 
the equation in single precision arithmetic if you use the right 
algorithm.  Whether this analysis is "quite involved" is a separate 
matter.  And if you want the solution in double precision to begin 
with, and that is all that your hardware supports, then your 
approach would not work at all, whereas the algorithm change does 
solve the problem.

Another example that is often used to demonstrate this issue is the 
solution of roots of a quadratic equation.

  (-b +-sqrt(b*b - 4*a*c) / (2*a))

If you use that expression directly, then one root involves adding 
two terms with the same sign and the other root involves adding two 
terms with opposite signs.  If the two terms are about the same 
magnitude, then that second root will suffer from roundoff error.  
Converting to higher precision to compute the results is one 
approach, but it is not the best one.  Depending on when that 
conversion is done, it might not help at all with the accuracy of 
that second root. But there is an easy answer to this because the 
second root can be computed in a way that does not involve adding 
terms with opposite signs.

So the conclusion from all this is that the high-level language 
needs to be flexible in order to address all these possibilities.  
Although the old fashioned REAL and DOUBLE PRECISION maps closely to 
the underlying hardware, that is not what is best from the numerical 
analysis perspective. Particularly when the compiler supports three 
or four different precisions, things are much easier with the KIND 
approach.  And yes, compilers do now support multiple precisions 
like this; the latest gfortran supports 32-bit, 64-bit, 80-bit, and 
128-bit floating point arithmetic.

$.02 -Ron Shepard

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

(snip)
> I have had examples of routines where input and output parameters are
> well within the single-precision range, both in terms of magnitude and
> in terms of precision---numbers for which 3 or 4 digits of precision is
> enough with a range between a thousandth and a thousand, say.  However,
> if the routine which calculates the output based on the input is
> single-precision, then numerical problems occur, such as when an
> expression is analytically zero but numerically not or vice-versa, due
> to roundoff issues.  

I believe that is fairly common. With matix operations, it is very
easy to have some precision losing operations (subtraction of similar
values) in intermediate calculations. The traditional worst is
matrix inversion, but it happens in many other calculations, too.

On the other hand, the roundoff problem occurs in any precision.
My old favorite is computing the mean and standard deviation from
the sum and sum of squares. When the values are all the same,
the standard deviation should be zero, but sometimes will give
a square root of a negative number. I believe that can happen
in any precision.

> Converting the input variables to double-precision
> and doing calculations with those (and converting to 
> single-precision on output) fixes things.  An analysis to 
> determine the minimum precision required would be quite 
> involved and in practice would result in double-precision anyway.

Yes. Except for those rare machines with quadruple precision
hardware, most often the best solution is double precision.
Especially when using hardware that does all operations in
double precision or more internally.

(In the CDC days, with 60 bit single precision, many operations
that were double on other machines were single on such machines.
I believe that they supplied a software emulated double precision
to satisfy the Fortran standard. Also, the Cray machines with 64 bit
single precision.)

-- glen

In article <ron-shepard-E0F8E9.14122908042012@news60.forteinc.com>, Ron
Shepard <ron-shepard@NOSPAM.comcast.net> writes: 

> > I agree that the new paradigm is more flexible.  However, probably well 
> > over 90% of the code which uses it jumps through some hoops to define 
> > some named constants used for declarations but what it essentially 
> > results in is a single-precision type and a double-precision type.
> 
> Of course, that must be the final result if the compiler supports 
> only those two data types.

Right.

> >  In 
> > such cases, it is clearer to just use REAL and DOUBLE PRECISION.
> 
> 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.

> >  Converting the input variables to double-precision
> > and doing calculations with those (and converting to single-precision on
> > output) fixes things. 
> 
> That might be one way.  You can also change the way intermediate 
> expressions are evaluated, you can change the overall algorithm, and 
> so on.  The entire field of numerical analysis addresses these 
> problems.

Of course.  I don't like to micro-optimize code when writing, but I do 
make sure that obvious numerical goofs are avoided (e.g. grouping 
expressions to avoid extremely small intermediate values).  Changing a 
complicated algorithm is of course more trouble, and if increasing the 
relative precision for "internal" calculations solves the problem, why 
not indicate it with DOUBLE PRECISION (which makes it clear that it has 
more precision than REAL)?  Using the KIND approach and expressing a 
wish for a certain precision can give the impression that one has 
actually calculated what one needs.  :-)  That's fine if that's the 
case, but if I just need MORE, I don't want to make it look like I have 
done more work than I actually have.  :-|

> > An analysis to determine the minimum precision
> > required would be quite involved and in practice would result in
> > double-precision anyway.
> 
> Sometimes, but not necessarily.  A good example might be 
> least-squares solutions for problems with large condition numbers.  
> If you solve them with the normal equations, the condition number is 
> the square of the condition number when the solution is obtained 
> with factorization.  With your approach, the "answer" would be to 
> solve the normal equations in double precision, and then convert the 
> answer back at the end.  But that is not necessary. You can solve 
> the equation in single precision arithmetic if you use the right 
> algorithm.  Whether this analysis is "quite involved" is a separate 
> matter.  And if you want the solution in double precision to begin 
> with, and that is all that your hardware supports, then your 
> approach would not work at all, whereas the algorithm change does 
> solve the problem.

Yes, and a good example, but not one I am working on now.

> Another example that is often used to demonstrate this issue is the 
> solution of roots of a quadratic equation.
> 
>   (-b +-sqrt(b*b - 4*a*c) / (2*a))
> 
> If you use that expression directly, then one root involves adding 
> two terms with the same sign and the other root involves adding two 
> terms with opposite signs.  If the two terms are about the same 
> magnitude, then that second root will suffer from roundoff error.  
> Converting to higher precision to compute the results is one 
> approach, but it is not the best one.  Depending on when that 
> conversion is done, it might not help at all with the accuracy of 
> that second root. But there is an easy answer to this because the 
> second root can be computed in a way that does not involve adding 
> terms with opposite signs.

Yes; that is what I was thinking of above.

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

> In article <ron-shepard-6275D0.11281208042012@news60.forteinc.com>, Ron
> Shepard <ron-shepard@NOSPAM.comcast.net> writes: 

> > BTW, I have found almost no place for the old fashioned DOUBLE 
> > PRECISION declarations in new code.  
> 
> I agree that the new paradigm is more flexible.  However, probably well
> over 90% of the code which uses it jumps through some hoops to define
> some named constants used for declarations but what it essentially 
> results in is a single-precision type and a double-precision type.  In
> such cases, it is clearer to just use REAL and DOUBLE PRECISION.

I most vehemently disagree. Yes, you might well end up doing the same
thing as single and double precision, but the decision is isolated to
one place in the code where you define the named constants that you use
for your kinds.

I wasted many, many hours of my youth converting f66 and f77 code
between single and double precision for different machines. Single
precision was inadequate on the 32-bit machines, and double precision
was too slow and space-consuming on the 60-bit ones (or 64-bit ones, but
I more often used 60-bit machines). I learned the tricks to making it
relatively easy to do the conversion, but it could be awfully painful
for codes that hadn't been written specifically to make it easy. (And
for some codes that played lots of strange equivalence/common tricks, it
was just impractical enough that you were better off finding a different
program). I spent *LOTS* of time on this kind of thing, so I am very
sensitive to it. Kind type parameters were one of the first things I
noticed in f90, and I was an instant convert.

Strew explicit double precision declarations all over your code instead
of isolating the decision to a single place and someday I predict you
will come to appreciate the quote in my signature. I use it for a
reason. :-(

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

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

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

In article <1kia0ah.ipbc0b1k58gvaN%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.

Since there never was Fortran 90 for the VAX (at least not from DEC; 
there was a company which had a Fortran90-to-VAXFortran translator, but 
I don't think it was ever a mature product), this was always an 
extension.  It was a useful feature; in many (most?) cases, the reason 
to have more bits is greater precision, not greater range.  This 
provided an option for more precision than DOUBLE PRECISION without 
having to go to REAL*16.

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

> 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.

Yes, and you are not the first programmer to take this into account.  
One of the common conventions is to use "wp" as the kind parameter 
for working precision, and then assign or map that value as 
appropriate.  In cases where I might want to do mixed-precision 
work, I use "wp", "ep", and "eep".  Sometimes those all have the 
same value, sometimes they have two values, and sometimes they have 
three values, depending on what "wp" is at the time and what I'm 
trying to do.  In most of my work (on intel cpus), "wp" is 64-bit, 
"ep" is 80-bit, and "eep" is 128-bit floating point, but sometimes 
they map to 32-bit, 64-bit, and 80-bit.

It does take some effort to write code that works correctly with 
these kinds of parameterized precisions.  Things like root searches 
and other iterative procedures need to have different tolerances and 
convergence criteria.  Modern fortran provides a nice set of 
intrinsics that give you the floating point characteristics 
(epsilon(), spacing(), nearest(), huge(), tiny(), and so on).  I 
cannot overstate how much better this situation is now than it was 
in the 70's and 80's when this kind of portable programming was 
almost impossible.  This is why it seems so regressive to me to see 
someone programming with old fashioned REAL and DOUBLE PRECISION and 
with hardwired constants with D exponents.  I certainly understand 
why that is still in the language for back compatibility and legacy 
code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT 
WAY.

$.02 -Ron Shepard

In article <ron-shepard-FD6D28.11011609042012@news60.forteinc.com>, Ron
Shepard <ron-shepard@NOSPAM.comcast.net> writes: 

> This is why it seems so regressive to me to see 
> someone programming with old fashioned REAL and DOUBLE PRECISION and 
> with hardwired constants with D exponents.  I certainly understand 
> why that is still in the language for back compatibility and legacy 
> code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT 
> WAY.

What about an initiative to make them OBSOLESCENT?

Richard Maine <nospam@see.signature> wrote:

(previous snip on iso_fortran_environment)
>> > 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. :-)). 

I might have come up with the same number, in about the same way.

If you write a program to solve just one instance of one specific
problem, then you might know the exact precision requirements.
If you want one to be generally useful for a wide variety of
problems, then usually not.

> 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.

Reminds me of all the PL/I programs with FLOAT BIN(21) and
FLOAT BIN(53), the numbers that match the IBM hardware. 

Some fraction of those cases where you might do the analysis
on the needed precision, it can't actually be determined
until run-time, when the input data is available.

Reminds me of an interesting book I found not so long ago:

  "Introduction to Precise Numerical Methods, Second Edition"
  by Oliver Aberth 

It includes discussion on the problems and methods of doing
calculations to a known precision, C++ routines to do such
calculations, and sample programs to use those routines.

This is for the case when you know (at compile or run time) the
precision you need in the result, and then need to propagate
that back through the calculation.

Available reasonably priced from the usual used book web sites.
 
>> 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. 

If a compiler doesn't support the intrinsic module, is it likely
to complain if you write one with the same name? Still, probably
better to give it your own name.

> 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. 

(snip)

-- glen

On 2012-04-09, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <1kia0ah.ipbc0b1k58gvaN%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.
>
> Since there never was Fortran 90 for the VAX (at least not from DEC; 
> there was a company which had a Fortran90-to-VAXFortran translator, but 
> I don't think it was ever a mature product), this was always an 
> extension.

FWIW, there has been some recent work to make GFortran (and the rest
of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
the CPU architecture is IA-64 rather than VAX, though.

-- 
JB

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

(snip on precision specification, someone wrote)

>> 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)?

You ask about compilers, not about the underlying hardware.

For VAX, it was usual that the hardware supported one, but on
some it might be optional to support both.

The current IBM z/ systems support hex (S/360 form), binary (IEEE),
and decimal (new IEEE) all on one machine. The bits are divided
up differently among all three formats. (For the decimal form,
the division is finer than bits.)

I don't know if there are compilers that support more than one
in the same compilation, though.

-- glen

JB <foo@bar.invalid> wrote:
(snip)

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

(snip)

>> Since there never was Fortran 90 for the VAX (at least not from DEC; 
>> there was a company which had a Fortran90-to-VAXFortran translator, 
>> but I don't think it was ever a mature product), this was always an 
>> extension.

> FWIW, there has been some recent work to make GFortran (and the rest
> of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
> the CPU architecture is IA-64 rather than VAX, though.

For Alpha, the VAX formats were supported by converting to/from
IEEE format. That is, the memory formats were supported, but when
loaded into registers they became IEEE format. (I have the manuals,
though I never did assembly programming on Alpha.) In that case,
the extra bits were silently lost.

I have an actual RX2600 running (well, currently turned off) 
IA-64/VMS under a hobbyist license. It does have the HP Fortran
compiler. It would be interesting to run gfortran on it.
(Some time ago, RX-2600's were available on eBay for $100,
dual processor and 10GB RAM.)

I also have a MicroVAX 3100 which I should get running again.

-- glen

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

> Richard Maine <nospam@see.signature> wrote:

> > 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. 
> 
> If a compiler doesn't support the intrinsic module, is it likely
> to complain if you write one with the same name? Still, probably
> better to give it your own name.

Yes, using your own module name is what I had in mind. That also avoids
the problem of the compiler having the iso_fortran_environment module,
which was introduced in f2003, but not having those particular
parameters in it, as those weren't introduced until f2008. (I swear I
recall arguing for them in f2003, but obviously either I lost that
argument then or I misrecall the date and it was actually about f2008).

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

In article <slrnjo63oj.lts.foo@hugo.hut.fi>, JB <foo@bar.invalid>
writes: 

> FWIW, there has been some recent work to make GFortran (and the rest
> of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
> the CPU architecture is IA-64 rather than VAX, though.

That would be interesting.  At home, I have ALPHAs (and VAXes, though
none of these in use at the moment) and the Fortran95 compiler.  AFAIK
there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
didn't make even Fortran90.  (At work, we have only IA64 now, but no
Fortran on the machines I use.)  Does anyone know if there is anything 
later than Fortran95 for ALPHA?  For IA64?

Does GFortran translate to C and compile that?  If so, it probably 
wouldn't be as efficient as a native compiler.  (The VAX and ALPHA 
compilers don't even go through intermediate assembly; they produce 
object files directly.)  Would still be interesting though.

In article <jlv2um$9au$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes: 

> Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
> 
> (snip on precision specification, someone wrote)
> 
> >> 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)?
> 
> You ask about compilers, not about the underlying hardware.
> 
> For VAX, it was usual that the hardware supported one, but on
> some it might be optional to support both.

I don't know about the VAX hardware details; the Fortran compiler 
offered two different 8-byte floating-point data types...

> The current IBM z/ systems support hex (S/360 form), binary (IEEE),
> and decimal (new IEEE) all on one machine. The bits are divided
> up differently among all three formats. (For the decimal form,
> the division is finer than bits.)
> 
> I don't know if there are compilers that support more than one
> in the same compilation, though.

....and this was also possible if I remember correctly.  (There was also 
a compiler option to change the default.)

In article <jlv3hp$av0$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes: 

> For Alpha, the VAX formats were supported by converting to/from
> IEEE format. That is, the memory formats were supported, but when
> loaded into registers they became IEEE format. (I have the manuals,
> though I never did assembly programming on Alpha.) In that case,
> the extra bits were silently lost.

Right.  This was basically just for compatibility with programs reading 
or writing binary data in the non-standard VAX format.

> I have an actual RX2600 running (well, currently turned off) 
> IA-64/VMS under a hobbyist license. It does have the HP Fortran
> compiler. 

What is the latest standard supported?

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

> I swear I
> recall arguing for them in f2003, but obviously either I lost that
> argument then or I misrecall the date and it was actually about f2008).

Or maybe it was an optional argument and you assumed it was 
present.  :-)

On 2012-04-09, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <slrnjo63oj.lts.foo@hugo.hut.fi>, JB <foo@bar.invalid>
> writes: 
>
>> FWIW, there has been some recent work to make GFortran (and the rest
>> of GCC) support VMS. The target triplet is ia64-hp-openvms, suggesting
>> the CPU architecture is IA-64 rather than VAX, though.
>
> That would be interesting.  At home, I have ALPHAs (and VAXes, though
> none of these in use at the moment) and the Fortran95 compiler.  AFAIK
> there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
> didn't make even Fortran90.  (At work, we have only IA64 now, but no
> Fortran on the machines I use.)  Does anyone know if there is anything 
> later than Fortran95 for ALPHA?  For IA64?

GCC supports both. For alpha, at least the alpha*-dec-osf* target was
somewhat regularly tested up to the 4.7 release, at some point
alpha-linux-gnu was also supported by GCC, though I don't know of the
current status nor if gfortran ever worked on it. For IA-64,
hppa2.0w-hp-hpux11.11 is still supported and AFAIK gfortran works,
also at least some ia64-unknown-linux-gnu target was supported at some
point though I don't know if gfortran worked there.

At least Intel used to provide Linux/IA-64 compilers, but IIRC the
latest version doesn't support it anymore.

> Does GFortran translate to C and compile that?

No. All the GCC frontends (C, C++, Objc, ObjC++, Fortran, Ada, Go,
Java) generate a common intermediate representation which is then
successively lowered until assembler for the target is eventually spit
out.

> (The VAX and ALPHA 
> compilers don't even go through intermediate assembly; they produce 
> object files directly.)

For GCC, see the -pipe option; it doesn't really affect CPU time used
by the compiler, but it might reduce wallclock time by avoiding the
(relatively slow) disk for temp files.


-- 
JB

In article <slrnjo6fds.qaq.foo@hugo.hut.fi>, JB <foo@bar.invalid>
writes: 

> > That would be interesting.  At home, I have ALPHAs (and VAXes, though
> > none of these in use at the moment) and the Fortran95 compiler.  AFAIK
> > there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
> > didn't make even Fortran90.  (At work, we have only IA64 now, but no
> > Fortran on the machines I use.)  Does anyone know if there is anything 
> > later than Fortran95 for ALPHA?  For IA64?
> 
> GCC supports both. For alpha, at least the alpha*-dec-osf* target was
> somewhat regularly tested up to the 4.7 release, at some point
> alpha-linux-gnu was also supported by GCC, though I don't know of the
> current status nor if gfortran ever worked on it. 

Isn't Linux on Alpha dead?  I'm pretty sure RedHat no longer supports 
it.

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

(snip, I wrote)
>> For Alpha, the VAX formats were supported by converting to/from
>> IEEE format. That is, the memory formats were supported, but when
>> loaded into registers they became IEEE format. (I have the manuals,
>> though I never did assembly programming on Alpha.) In that case,
>> the extra bits were silently lost.

> Right.  This was basically just for compatibility with 
> programs reading or writing binary data in the non-standard 
> VAX format.

Note that though the VAX format is slightly different, they byte
order is very different. It seems that it was inherited from
some hardware used with the PDP-11, and has little-endian 16 bit
words, in big endian order. I used to have some VAX Fortran
programs initializing arrays with hex constants, which are,
as usual, in the appropriate order for 32 bit integers.

>> I have an actual RX2600 running (well, currently turned off) 
>> IA-64/VMS under a hobbyist license. It does have the HP Fortran
>> compiler. 

> What is the latest standard supported?

http://h71000.www7.hp.com/doc/82final/6443/6443pro.html

Says "Fortran 90/95". I don't know why that, instead of Fortran 95.

-- glen

JB <foo@bar.invalid> wrote:
> On 2012-04-09, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:

(snip)
>> Does GFortran translate to C and compile that?

> No. All the GCC frontends (C, C++, Objc, ObjC++, Fortran, Ada, Go,
> Java) generate a common intermediate representation which is then
> successively lowered until assembler for the target is eventually 
> spit out.

That is the more usual way to write compilers. There was for a
while f2c which translated to an intermediate C, which was then
compiled. I believe that the calling sequence was similar to
g77 such that one might be able to call between them.

I believe, though, that the intermediate representation was
designed toward a C compiler, and may be less than optimal
for Fortran. For one, I know that it doesn't represent ENTRY,
such that the generated code for programs using ENTRY has one
routine with all the possible dummy arguments, and then small
ones, with each possible name, that call the big routine.

Among others, that is (or was when I tried it) from gdb.

>> (The VAX and ALPHA compilers don't even go through intermediate 
>> assembly; they produce object files directly.)

That is the more usual way to write compilers, though there
was been a tradition as far back as I know to have the ability
to write out, in a human readable form, the generated assembly
program. It may or may not be close to the form needed as
input to an assembler. 

The Watcom compilers are interesting. They generate the object
program directly, and then supply a program what will show the
generated assembly code in human readable form. Enough information
is included in the object file to make a useful assembly listing.

> For GCC, see the -pipe option; it doesn't really affect CPU time used
> by the compiler, but it might reduce wallclock time by avoiding the
> (relatively slow) disk for temp files.

-- glen

On Monday, April 9, 2012 9:42:34 AM UTC-7, glen herrmannsfeldt wrote:
[...]
> For Alpha, the VAX formats were supported by converting to/from
> IEEE format. That is, the memory formats were supported, but when
> loaded into registers they became IEEE format. (I have the manuals,
> though I never did assembly programming on Alpha.) In that case,
> the extra bits were silently lost.

This paragraph is incorrect.  VAX supported two 64-bit floating
point formats, D_float and G_float, plus one 128-bit floating
point format, H_float (I believe H_float was a hardware and/or
microcode option on early VAXes...).  The differences are that
D_float retains the same format as single precision F_float in
the first 32-bit word, then adds another 32-bits of mantissa,
thereby giving a smaller exponent range than IEEE doubles.
G_float, on the other hand, uses the same number of exponent and
mantissa bits as IEEE double precision.  N.B. A VAX (and Alpha)
G_float has 16-bit words within the 64-bits swapped in a way
that matches the early PDP-11 definition of floats that was
inherited by the VAX; the bit-wise representation looks very
odd compared to IEEE 754 floats and doubles.

All that said, Alpha supports both IEEE and VAX floating 
point formats. As noted before, the VAX formats are F_float
and G_float, with D_float being converted to G_float on 
read.  The IEEE formats are named S_float and T_float,
for single and double precision, respectively (with a 128-bit
format named X_float also being available in software).  
These have the IEEE 754 bitwise representations.

It is the conversion of D_float to G_float, that loses 3 bits
of mantissa in the process, which Glen was refering to.  It
is not D_float to "IEEE" as implied.

> I have an actual RX2600 running (well, currently turned off) 
> IA-64/VMS under a hobbyist license. It does have the HP Fortran
> compiler. It would be interesting to run gfortran on it.
> (Some time ago, RX-2600's were available on eBay for $100,
> dual processor and 10GB RAM.)

Correct me if I'm wrong, but I believe IA64 supports only the 
IEEE formats, but I'm sure the compiler provides conversion 
routines to and from the VAX and Alpha representations,
no?

    -Ken

ken.fairfield@gmail.com wrote:
> On Monday, April 9, 2012 9:42:34 AM UTC-7, glen herrmannsfeldt wrote:
> [...]
>> For Alpha, the VAX formats were supported by converting to/from
>> IEEE format. That is, the memory formats were supported, but when
>> loaded into registers they became IEEE format. (I have the manuals,
>> though I never did assembly programming on Alpha.) In that case,
>> the extra bits were silently lost.

> This paragraph is incorrect.  VAX supported two 64-bit floating
> point formats, D_float and G_float, plus one 128-bit floating
> point format, H_float (I believe H_float was a hardware and/or
> microcode option on early VAXes...).  The differences are that
> D_float retains the same format as single precision F_float in
> the first 32-bit word, then adds another 32-bits of mantissa,
> thereby giving a smaller exponent range than IEEE doubles.
> G_float, on the other hand, uses the same number of exponent and
> mantissa bits as IEEE double precision.  N.B. A VAX (and Alpha)
> G_float has 16-bit words within the 64-bits swapped in a way
> that matches the early PDP-11 definition of floats that was
> inherited by the VAX; the bit-wise representation looks very
> odd compared to IEEE 754 floats and doubles.

OK, I wrote that one without actually looking it up, as
the book wasn't nearby.

The thing I was not very well explaining is that when you 
load F or G float into a register that the bits are moved
around to undo the 16 bit word swap that you noted above.

Also, when you load F or S float into a register, the 8 bit
exponent is expanded to 11 bits.

> All that said, Alpha supports both IEEE and VAX floating 
> point formats. As noted before, the VAX formats are F_float
> and G_float, with D_float being converted to G_float on 
> read.  The IEEE formats are named S_float and T_float,
> for single and double precision, respectively (with a 128-bit
> format named X_float also being available in software).  
> These have the IEEE 754 bitwise representations.

> It is the conversion of D_float to G_float, that loses 3 bits
> of mantissa in the process, which Glen was refering to.  It
> is not D_float to "IEEE" as implied.

The bits are reordered to IEEE order. There are some
differences in the meaning of the bits between the IEEE and
VAX formats.

>> I have an actual RX2600 running (well, currently turned off) 
>> IA-64/VMS under a hobbyist license. It does have the HP Fortran
>> compiler. It would be interesting to run gfortran on it.
>> (Some time ago, RX-2600's were available on eBay for $100,
>> dual processor and 10GB RAM.)

> Correct me if I'm wrong, but I believe IA64 supports only the 
> IEEE formats, but I'm sure the compiler provides conversion 
> routines to and from the VAX and Alpha representations,
> no?

Yes, I believe there is software support, but not hardware
support, for the VAX formats.

-- glen

In article <jlv1an$eku$7@online.de>,
 helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
 reply) wrote:

> In article <ron-shepard-FD6D28.11011609042012@news60.forteinc.com>, Ron
> Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> 
> > This is why it seems so regressive to me to see 
> > someone programming with old fashioned REAL and DOUBLE PRECISION and 
> > with hardwired constants with D exponents.  I certainly understand 
> > why that is still in the language for back compatibility and legacy 
> > code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT 
> > WAY.
> 
> What about an initiative to make them OBSOLESCENT?

It would not get my support: "back compatibility and legacy code".  
That issue is simply too important.

$.02 -Ron Shepard

On 4/8/2012 10:10 PM, glen herrmannsfeldt wrote:
> 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.

In the ANSI Fortran 77 specification, DBLE is defined both for REAL and 
INTEGER arguments.   I guess this would not have worked in Fortran 66.
Admittedly, real(integervalue,targetkind) has the advantage of allowing 
targetkind to be set in one place, but I've never seen it used.


-- 
Tim Prince

Hello,

On 2012-04-09 14:44:05 +0000, Richard Maine said:
>>> 
>>> 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.

Yea,   I was wrong.  :-(

-- 
Cheers!

Dan Nagle

In article <9uicltFp1qU1@mid.individual.net>,
 Tim Prince <tprince@computer.org> wrote:

> In the ANSI Fortran 77 specification, DBLE is defined both for REAL and 
> INTEGER arguments.   I guess this would not have worked in Fortran 66.
> Admittedly, real(integervalue,targetkind) has the advantage of allowing 
> targetkind to be set in one place, but I've never seen it used.

Instead of using the kind value by position, which I think might be 
confusing, I usually specify it either as

   a = real(i,kind(a))

or by keyword as

   a = real(i,kind=wp)

In both cases, I think it is clear which value is being converted 
and what is the purpose of the second argument.

$.02 -Ron Shepard

On Monday, April 9, 2012 8:24:23 PM UTC-7, glen herrmannsfeldt wrote:
> Ken Fairfield wrote:
> > On Monday, April 9, 2012 9:42:34 AM UTC-7, glen herrmannsfeldt wrote:
> > [...]
> >> For Alpha, the VAX formats were supported by converting to/from
> >> IEEE format. That is, the memory formats were supported, but when
> >> loaded into registers they became IEEE format. (I have the manuals,
> >> though I never did assembly programming on Alpha.) In that case,
> >> the extra bits were silently lost.
> 
> > This paragraph is incorrect. [...]
 
> OK, I wrote that one without actually looking it up, as
> the book wasn't nearby.
> 
> The thing I was not very well explaining is that when you 
> load F or G float into a register that the bits are moved
> around to undo the 16 bit word swap that you noted above.

That may be true (probably is true?) for IA64, but my 
understanding is that the Alpha architecture supported the
VAX F_float and G_float natively, as well as IEEE S_float 
and T_float natively.  OTOH, I admit I haven't read an
Alpha architecture book nor compared the machine code
generated with and without /FLOAT=IEEE qualifier on the
compilation command...

> Also, when you load F or S float into a register, the 8 bit
> exponent is expanded to 11 bits.

Again, I believe that is an IA64 thing...

> > All that said, Alpha supports both IEEE and VAX floating 
> > point formats. As noted before, the VAX formats are F_float
> > and G_float, with D_float being converted to G_float on 
> > read.  The IEEE formats are named S_float and T_float,
> > for single and double precision, respectively (with a 128-bit
> > format named X_float also being available in software).  
> > These have the IEEE 754 bitwise representations.
> 
> > It is the conversion of D_float to G_float, that loses 3 bits
> > of mantissa in the process, which Glen was refering to.  It
> > is not D_float to "IEEE" as implied.
> 
> The bits are reordered to IEEE order. There are some
> differences in the meaning of the bits between the IEEE and
> VAX formats.

Again, about the bit reordering, I don't think so...except on IA64. 
But yes, the VAX representation uses an asymetric exponent range
whereas IEEE uses a sysmetric range, plus "denorms", plus all the
"exceptional" values (NaN, Inf, etc.).  or the VAX representations,
there are very few bit patterns that are not valid floats...

    Regards, Ken

ken.fairfield@gmail.com wrote:

(snip, I wrote)
>> OK, I wrote that one without actually looking it up, as
>> the book wasn't nearby.
 
>> The thing I was not very well explaining is that when you 
>> load F or G float into a register that the bits are moved
>> around to undo the 16 bit word swap that you noted above.

> That may be true (probably is true?) for IA64, but my 
> understanding is that the Alpha architecture supported the
> VAX F_float and G_float natively, as well as IEEE S_float 
> and T_float natively.  OTOH, I admit I haven't read an
> Alpha architecture book nor compared the machine code
> generated with and without /FLOAT=IEEE qualifier on the
> compilation command...

Yes, that is the part that I didn't explain right at first.

It rearranges the bits on load, but there are still separate
instructions for F, G, S, and T float. It would seem that the
bit rearrangement is convenient in that when they go into the
appropriate ALU, all the bits will be in the right place,
though they do have to be operated on differently.

The exponent bit rearrangement also means that an F-float
loaded is ready to be used in G-float operations, and S-float
loaded is ready for T-float operations without additional
conversion.

Conversion (both directions) between D-float and G-float is
done in registers. Conversion from G-float to F-float, or
from T-float to S-float, again done in registers, must be 
done before F or S operations, including store, to be sure 
that the exponent is in range, and any overflow has 
been signalled.

>> Also, when you load F or S float into a register, the 8 bit
>> exponent is expanded to 11 bits.

> Again, I believe that is an IA64 thing...

See above.

(snip)

>> The bits are reordered to IEEE order. There are some
>> differences in the meaning of the bits between the IEEE and
>> VAX formats.

> Again, about the bit reordering, I don't think so...except on IA64. 
> But yes, the VAX representation uses an asymetric exponent range
> whereas IEEE uses a sysmetric range, plus "denorms", plus all the
> "exceptional" values (NaN, Inf, etc.).  or the VAX representations,
> there are very few bit patterns that are not valid floats...

The bits are reordered, but load and store don't signal exceptions.

Given this ordering, I was remembering figuring out some time
ago that you could, except for some small exceptions, use
the F load instruction on S data, or G load instruction on T data,
to work with IEEE data in VAX word order, or the other way around to
work on VAX data in IEEE word order.

Load/store rearrange bits but don't signal any data exceptions.
The difference between F-load and S-load is only in the case that
the exponent bits are all one. (Exceptional in IEEE, ordinary in VAX.)

-- glen

In article <jlvgq5$d32$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes: 

> >> For Alpha, the VAX formats were supported by converting to/from
> >> IEEE format. That is, the memory formats were supported, but when
> >> loaded into registers they became IEEE format. (I have the manuals,
> >> though I never did assembly programming on Alpha.) In that case,
> >> the extra bits were silently lost.
> 
> > Right.  This was basically just for compatibility with 
> > programs reading or writing binary data in the non-standard 
> > VAX format.
> 
> Note that though the VAX format is slightly different, they byte
> order is very different. It seems that it was inherited from
> some hardware used with the PDP-11, and has little-endian 16 bit
> words, in big endian order. I used to have some VAX Fortran
> programs initializing arrays with hex constants, which are,
> as usual, in the appropriate order for 32 bit integers.

The actual physical order in which they are stored is rather strange.  
It has the side effect that passing real values to double-precision 
dummy arguments or vice versa will "do the right thing".  This is 
probably the reason for the strange order.

In article <ron-shepard-FBEEC3.00592310042012@news60.forteinc.com>, Ron
Shepard <ron-shepard@NOSPAM.comcast.net> writes: 

> In article <jlv1an$eku$7@online.de>,
>  helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
>  reply) wrote:
> 
> > In article <ron-shepard-FD6D28.11011609042012@news60.forteinc.com>, Ron
> > Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> > 
> > > This is why it seems so regressive to me to see 
> > > someone programming with old fashioned REAL and DOUBLE PRECISION and 
> > > with hardwired constants with D exponents.  I certainly understand 
> > > why that is still in the language for back compatibility and legacy 
> > > code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT 
> > > WAY.
> > 
> > What about an initiative to make them OBSOLESCENT?
> 
> It would not get my support: "back compatibility and legacy code".  
> That issue is simply too important.

But isn't that the point of OBSOLESCENT (as opposed to DELETED)?  It is 
still supported, but this indicates that its use in new code is 
discouraged.

Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
(snip)
>> > What about an initiative to make them OBSOLESCENT?
 
>> It would not get my support: "back compatibility and legacy code".  
>> That issue is simply too important.

> But isn't that the point of OBSOLESCENT (as opposed to DELETED)?  It 
> is still supported, but this indicates that its use in new code is 
> discouraged.

But it is also supposed to mean that it might be removed in
future versions of the standard. Now, that rarely happens so
maybe it doesn't really mean that.

-- glen

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

(snip, I wrote)
>> Note that though the VAX format is slightly different, they byte
>> order is very different. It seems that it was inherited from
>> some hardware used with the PDP-11, and has little-endian 16 bit
>> words, in big endian order. I used to have some VAX Fortran
>> programs initializing arrays with hex constants, which are,
>> as usual, in the appropriate order for 32 bit integers.

> The actual physical order in which they are stored is rather strange.  
> It has the side effect that passing real values to double-precision 
> dummy arguments or vice versa will "do the right thing".  This is 
> probably the reason for the strange order.

It has some history with the PDP-11 that I never really knew.
The PDP-11 uses 16 bit words, inherited by VAX.

There was some kind of floating point add-on for some version
of the PDP-11 that used big-endian ordering of 16 bit words.

VAX was originally defined as a PDP-11 extension, and even 
included compatibility mode to run PDP-11 software. (Removed
in later models.) 

-- glen

On 4/10/2012 4:51 PM, glen herrmannsfeldt wrote:
> Phillip Helbig---undress to reply<helbig@astro.multiclothesvax.de>  wrote:
> (snip)
>>>> What about an initiative to make them OBSOLESCENT?
>
>>> It would not get my support: "back compatibility and legacy code".
>>> That issue is simply too important.
>
>> But isn't that the point of OBSOLESCENT (as opposed to DELETED)?  It
>> is still supported, but this indicates that its use in new code is
>> discouraged.
>
> But it is also supposed to mean that it might be removed in
> future versions of the standard. Now, that rarely happens so
> maybe it doesn't really mean that.

Maybe we need another category--say DEPRECATED, maybe?  :)

--

In article <jm28gg$5cu$5@online.de>,
 helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
 reply) wrote:

> In article <ron-shepard-FBEEC3.00592310042012@news60.forteinc.com>, Ron
> Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> 
> > In article <jlv1an$eku$7@online.de>,
> >  helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
> >  reply) wrote:
> > 
> > > In article <ron-shepard-FD6D28.11011609042012@news60.forteinc.com>, Ron
> > > Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> > > 
> > > > This is why it seems so regressive to me to see 
> > > > someone programming with old fashioned REAL and DOUBLE PRECISION and 
> > > > with hardwired constants with D exponents.  I certainly understand 
> > > > why that is still in the language for back compatibility and legacy 
> > > > code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT 
> > > > WAY.
> > > 
> > > What about an initiative to make them OBSOLESCENT?
> > 
> > It would not get my support: "back compatibility and legacy code".  
> > That issue is simply too important.
> 
> But isn't that the point of OBSOLESCENT (as opposed to DELETED)?  It is 
> still supported, but this indicates that its use in new code is 
> discouraged.

Maybe I misremembered what that word means in the standard.  I 
thought it meant that it was a candidate for removal.  What I meant 
to say above is that I do not think that REAL and DOUBLE PRECISION 
(and the E and D exponents in constants) should ever be removed from 
the language.

$.02 -Ron Shepard

Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> In article <jm28gg$5cu$5@online.de>,
>  helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
>  reply) wrote:
> 
> > In article <ron-shepard-FBEEC3.00592310042012@news60.forteinc.com>, Ron
> > Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> > 
> > > In article <jlv1an$eku$7@online.de>,
> > >  helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to 
> > >  reply) wrote:
> > > 
> > > > In article <ron-shepard-FD6D28.11011609042012@news60.forteinc.com>, Ron
> > > > Shepard <ron-shepard@NOSPAM.comcast.net> writes: 
> > > > 
> > > > > This is why it seems so regressive to me to see 
> > > > > someone programming with old fashioned REAL and DOUBLE PRECISION and
> > > > > with hardwired constants with D exponents.  I certainly understand
> > > > > why that is still in the language for back compatibility and legacy
> > > > > code, but programmers now are simply NOT SUPPOSED TO PROGRAM THAT
> > > > > WAY.
> > > > 
> > > > What about an initiative to make them OBSOLESCENT?
> > > 
> > > It would not get my support: "back compatibility and legacy code".
> > > That issue is simply too important.
> > 
> > But isn't that the point of OBSOLESCENT (as opposed to DELETED)?  It is
> > still supported, but this indicates that its use in new code is 
> > discouraged.
> 
> Maybe I misremembered what that word means in the standard.  I 
> thought it meant that it was a candidate for removal.  What I meant 
> to say above is that I do not think that REAL and DOUBLE PRECISION 
> (and the E and D exponents in constants) should ever be removed from 
> the language.

You remember correctly. Philip's description of "use in new code is
discouraged" sounds much more like the "deprecated" category, which dpb
alludes to (and that's no doubt why he made the allusion). Although it
was in early drafts of f90, the deprecated category never made it into a
published standard because it was too controversial. I don't recall
whether double precision was among the things labelled as deprecated in
the f90 draft, but it is at least plausible that it might have been. In
any case, ss noted, that was just a draft, and the whole concept never
made it into the published standard.

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

On 2012-04-09, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <slrnjo6fds.qaq.foo@hugo.hut.fi>, JB <foo@bar.invalid>
> writes: 
>
>> > That would be interesting.  At home, I have ALPHAs (and VAXes, though
>> > none of these in use at the moment) and the Fortran95 compiler.  AFAIK
>> > there is no more modern compiler for ALPHA from DEC/Compaq/HP, and VAX
>> > didn't make even Fortran90.  (At work, we have only IA64 now, but no
>> > Fortran on the machines I use.)  Does anyone know if there is anything 
>> > later than Fortran95 for ALPHA?  For IA64?
>> 
>> GCC supports both. For alpha, at least the alpha*-dec-osf* target was
>> somewhat regularly tested up to the 4.7 release, at some point
>> alpha-linux-gnu was also supported by GCC, though I don't know of the
>> current status nor if gfortran ever worked on it. 
>
> Isn't Linux on Alpha dead?  I'm pretty sure RedHat no longer supports 
> it.

If by dead you mean "no longer supported by RedHat", I suppose
so. That being said, both the Linux kernel and GCC still support
Alpha. However, considering that Alpha hardware hasn't been produced
for a decade or so(?), I suspect it's only a matter of time before
they will bitrot away.


-- 
JB

> GCC supports both. For alpha, at least the alpha*-dec-osf* target was
> somewhat regularly tested up to the 4.7 release, at some point
> alpha-linux-gnu was also supported by GCC, though I don't know of the
> current status nor if gfortran ever worked on it.

For Alpha/Tru64 Unix, it was fully supported in GCC until 4.7, and will
be dropped in the upcoming 4.8 series. gfortran worked well there.

For Alpha on GNU/Linux, it is fully supported and regularly tested for
all GCC versions, and gfortran works perfectly there.

Alpha on OpenVMS is more complicated, and gfortran currently doesn't work
there. The fine folks at AdaCore are working on it, though, and we might
get a fully functional gfortran compiler for the 4.8 series. (But I don't
know how many user (singular) we'll get!)

> For IA-64, hppa2.0w-hp-hpux11.11 is still supported and AFAIK gfortran
> works, also at least some ia64-unknown-linux-gnu target was supported
> at some point though I don't know if gfortran worked there.

I think here you mixed PA-RISC (= hppa) and Itanium (= IA-64). PA-RISC is
supported on both HP/UX and GNU/Linux. As far as I know, the only problem
with gfortran there is some limitations of the system's math library on
HP/UX.

For IA-64, GCC in general and gfortran in particular is fully supported
on both GNU/Linux and HP/UX.

-- 
FX, somewhat of an exotic hardware nerd :)

On Sunday, April 15, 2012 2:30:06 AM UTC-7, FX wrote:
> > GCC supports both. For alpha, at least the alpha*-dec-osf* target was
> > somewhat regularly tested up to the 4.7 release, at some point
> > alpha-linux-gnu was also supported by GCC, though I don't know of the
> > current status nor if gfortran ever worked on it.
> 
> For Alpha/Tru64 Unix, it was fully supported in GCC until 4.7, and will
> be dropped in the upcoming 4.8 series. gfortran worked well there.
> 
> For Alpha on GNU/Linux, it is fully supported and regularly tested for
> all GCC versions, and gfortran works perfectly there.
> 
> Alpha on OpenVMS is more complicated, and gfortran currently doesn't work
> there. The fine folks at AdaCore are working on it, though, and we might
> get a fully functional gfortran compiler for the 4.8 series. (But I don't
> know how many user (singular) we'll get!)

I'd load gfortran on my OpenVMS/Alpha hobbyist machine in
second if it were available to me!  :-) :-)  Phillip H. might
be talked into it too, so that's two of us. ;-}

Should we expect some sort of public announcement from the 
AdaCore if and when that happens?

    Thanks, Ken

> I'd load gfortran on my OpenVMS/Alpha hobbyist machine in
> second if it were available to me!  :-) :-)  Phillip H. might
> be talked into it too, so that's two of us. ;-}

World domination starts somewhere.

> Should we expect some sort of public announcement from the 
> AdaCore if and when that happens?

Well, AdaCore is mostly interested in the Ada compiler part, of course.
They are putting effort into other parts, including the Fortran runtime
library (which is the hard part; the compiler itself is pretty portable),
but I wouldn't expect any formal announcement from them.

I suggest you bookmark the gfortran mailing-list web archive page (at
http://gcc.gnu.org/ml/fortran/) and swing by every few months to see if
VMS is discussed. Or, when 4.8.0 is released, just come around and ask if
your favorite platform is supported!

-- 
FX