I am more interested in some minor changes:
Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
COSD, SIND, and TAND will standardize what is a common extension.

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many
more variants.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
[...]

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many

more variants.

Yes, the accuracy of these function references can sometimes be a
problem. For example, there is no guarantee that the two expressions you
give above are the same to the last bit, so if a programmer uses one in
one place and the other in another place, and later checks for equality,
chaos may ensue. There is also the issue of rounding modes. If the
programmer sets one rounding mode in one place, and another rounding
mode in another, does he expect different values of PI to be returned
with those expressions?

However for the intrinsic constants approach, there would need to be
different versions of those constants for each real type, not just a
single version. How should those different kinds be denoted, given that different compilers might associate different kind integer values to the available candidates? For example, if they were given an integer label associated with the REAL_TYPES(:) array, then it might be complicated
for the programmer to write portable code. Another possibility might be
to introduce intrinsic functions, similar to HUGE() and EPSILON(), that
return values of the kind of its argument. If these were resolved at run
time, then it would be the same efficiency as a parameter reference, but
if they had to be done at run time, then it would cost machine cycles to
access those constants.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 24, 2022 at 1:22:25 AM UTC+11, john.a...@jtekt.com wrote:

I am more interested in some minor changes:
Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
COSD, SIND, and TAND will standardize what is a common extension.

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many

more variants.

4*ATAN(1D0) will give adequate accuracy, double precision;
4*ATAN(1.0) will do the same for single precision.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ron Shepard <nospam@nowhere.org> schrieb:

On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
[...]

I wish a standard constant for PI, E would be included,
instead of everyone having to create their own every time it is
needed. I have seen numeric definitions with not enough digits,
with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
many more variants.

Yes, the accuracy of these function references can sometimes be a
problem. For example, there is no guarantee that the two expressions you
give above are the same to the last bit,

From a numerical standpoint, arctan makes a lot more sense because
the derivative of acos(x) has a pole at x=-1.

4*atan(1.d0) is much better. This is also guaranteed to be evaluated
at compile-time and suitable for a parameter.

so if a programmer uses one in
one place and the other in another place, and later checks for equality, chaos may ensue.

As is usual for equality comparisons if it is indeed unknown that
the values _are_ exact.

You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
but otherwise floating point expressions should be treated with
care (and +/- epsilon).

There is also the issue of rounding modes. If the
programmer sets one rounding mode in one place, and another rounding
mode in another, does he expect different values of PI to be returned
with those expressions?

4*atan(1.d0) is a constant expression, so I do not think that the
IEEE rounding modes apply.

However for the intrinsic constants approach, there would need to be different versions of those constants for each real type, not just a
single version.

Not necessarily. A constant of the longest available real mode
could serve in principle, but could cause intermediate calculations
in higher precision than anticipated, which might be problematic.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/23/22 1:10 PM, Thomas Koenig wrote:

Ron Shepard <nospam@nowhere.org> schrieb:

On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
[...]

I wish a standard constant for PI, E would be included,
instead of everyone having to create their own every time it is
needed. I have seen numeric definitions with not enough digits,
with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
many more variants.

Yes, the accuracy of these function references can sometimes be a
problem. For example, there is no guarantee that the two expressions you
give above are the same to the last bit,

From a numerical standpoint, arctan makes a lot more sense because
the derivative of acos(x) has a pole at x=-1.

4*atan(1.d0) is much better. This is also guaranteed to be evaluated
at compile-time and suitable for a parameter.

Where in the standard is that required, either within an expression or
as part of a parameter definition? Isn't a compiler always allowed to
defer that evaluation until run time?

so if a programmer uses one in
one place and the other in another place, and later checks for equality,
chaos may ensue.

As is usual for equality comparisons if it is indeed unknown that
the values _are_ exact.

That was the point of the original post. Namely if there is a single
defined constant, then it should always be equal to itself, no matter
the optimization level, rounding mode, etc.

You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
but otherwise floating point expressions should be treated with
care (and +/- epsilon).

Normally yes, but in the case of PI and E and other such constants, the simplest way to guarantee their value would be with an intrinsic
constant, not a run time or even a compile time expression. Even if you
specify the constant manually with a literal, you really need about
three more digits than the epsilon in order to guarantee correct
rounding to the last bit.

There is also the issue of rounding modes. If the
programmer sets one rounding mode in one place, and another rounding
mode in another, does he expect different values of PI to be returned
with those expressions?

4*atan(1.d0) is a constant expression, so I do not think that the
IEEE rounding modes apply.

Why not? Is that part of the standard specification, or it it just the
way one compiler choose to do it?

However for the intrinsic constants approach, there would need to be
different versions of those constants for each real type, not just a
single version.

Not necessarily. A constant of the longest available real mode
could serve in principle, but could cause intermediate calculations
in higher precision than anticipated, which might be problematic.

That would be one approach. However, as you say, the programmer would
always need to assign the long value to a parameter or variable of the
correct kind first, and then use that local entity rather than the long intrinsic value in the expression. Otherwise, as you point out, the
programmer would lose control of the precision of the intermediate
results in the expression.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, March 23, 2022 at 9:08:31 PM UTC-7, Ron Shepard wrote:

On 3/23/22 1:10 PM, Thomas Koenig wrote:

(snip)

4*atan(1.d0) is much better. This is also guaranteed to be evaluated
at compile-time and suitable for a parameter.

Where in the standard is that required, either within an expression or
as part of a parameter definition? Isn't a compiler always allowed to
defer that evaluation until run time?

integer, save :: x(int(4000*atan(1.)))
x=3.1
print *,size(x)
end

Dimensions of saved arrays need to be known at compile time.
To be even more sure, put it in COMMON.

Note also, regarding comparisons for equality, at least some compilers
I know evaluate compile time expressions to different accuracy than
for run-time expressions. compile time atan(1.0) might differ from
run-time atan(1.0)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ron Shepard <nospam@nowhere.org> schrieb:

On 3/23/22 1:10 PM, Thomas Koenig wrote:

Ron Shepard <nospam@nowhere.org> schrieb:

On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
[...]

I wish a standard constant for PI, E would be included,
instead of everyone having to create their own every time it is
needed. I have seen numeric definitions with not enough digits,
with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
many more variants.

Yes, the accuracy of these function references can sometimes be a
problem. For example, there is no guarantee that the two expressions you >>> give above are the same to the last bit,

From a numerical standpoint, arctan makes a lot more sense because
the derivative of acos(x) has a pole at x=-1.

4*atan(1.d0) is much better. This is also guaranteed to be evaluated
at compile-time and suitable for a parameter.

Where in the standard is that required, either within an expression or
as part of a parameter definition?

F2018:

10.1.12 Constant expression

1 A constant expression is an expression with limitations that
make it suitable for use as a kind type parameter, initializer,
or named constant. It is an expression in which each operation is
intrinsic, and each primary is

(1) a constant or subobject of a constant,

[...]

and where each subscript, section subscript, substring starting
point, substring ending point, and type parameter value is a
constant expression

and

3.38.2
named constant
named data object with the PARAMETER attribute (8.5.13)

and finally

8.5.13 PARAMETER attribute

1 The PARAMETER attribute specifies that an entity is a named
constant. The entity has the value specified by its constant-expr,
converted, if necessary, to the type, type parameters and shape
of the entity.

So, while evaluation at compile-time is not strictly mandated by
the standard (because the standard has no concept of compilation,
for example) the effect is the same.

Isn't a compiler always allowed to
defer that evaluation until run time?

As long as the change is invisible to the user, yes (which
is another way of saying "no").

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 24, 2022 at 3:08:31 PM UTC+11, Ron Shepard wrote:

On 3/23/22 1:10 PM, Thomas Koenig wrote:

Ron Shepard <nos...@nowhere.org> schrieb:

On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
[...]

I wish a standard constant for PI, E would be included,
instead of everyone having to create their own every time it is
needed. I have seen numeric definitions with not enough digits,
with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
many more variants.

Yes, the accuracy of these function references can sometimes be a
problem. For example, there is no guarantee that the two expressions you >> give above are the same to the last bit,

From a numerical standpoint, arctan makes a lot more sense because
the derivative of acos(x) has a pole at x=-1.

4*atan(1.d0) is much better. This is also guaranteed to be evaluated
at compile-time and suitable for a parameter.

Where in the standard is that required, either within an expression or
as part of a parameter definition? Isn't a compiler always allowed to
defer that evaluation until run time?

.
Certain expressions are required to be evaluated at compile time.
Those that aren't could be evaluated at compile time or evaluated at
run time.
For example, those that have the PARAMETER attribute are
required to be evaluated at compile time, e.g.
integer, parameter, wp = kind (1.0d)

Those expressions that can be evaluated at compile time usually
are. It saves having to evaluate them at run time.

so if a programmer uses one in
one place and the other in another place, and later checks for equality, >> chaos may ensue.

As is usual for equality comparisons if it is indeed unknown that
the values _are_ exact.

That was the point of the original post. Namely if there is a single
defined constant, then it should always be equal to itself, no matter
the optimization level, rounding mode, etc.

You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
but otherwise floating point expressions should be treated with
care (and +/- epsilon).

Normally yes, but in the case of PI and E and other such constants, the simplest way to guarantee their value would be with an intrinsic
constant, not a run time or even a compile time expression. Even if you specify the constant manually with a literal, you really need about
three more digits than the epsilon in order to guarantee correct
rounding to the last bit.

There is also the issue of rounding modes. If the
programmer sets one rounding mode in one place, and another rounding
mode in another, does he expect different values of PI to be returned
with those expressions?

4*atan(1.d0) is a constant expression, so I do not think that the
IEEE rounding modes apply.

Why not? Is that part of the standard specification, or it it just the
way one compiler choose to do it?

However for the intrinsic constants approach, there would need to be
different versions of those constants for each real type, not just a
single version.

Not necessarily. A constant of the longest available real mode
could serve in principle, but could cause intermediate calculations
in higher precision than anticipated, which might be problematic.

That would be one approach. However, as you say, the programmer would
always need to assign the long value to a parameter or variable of the correct kind first, and then use that local entity rather than the long intrinsic value in the expression. Otherwise, as you point out, the programmer would lose control of the precision of the intermediate
results in the expression.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/24/22 2:05 AM, gah4 wrote:

On Wednesday, March 23, 2022 at 9:08:31 PM UTC-7, Ron Shepard wrote:

On 3/23/22 1:10 PM, Thomas Koenig wrote:

(snip)

4*atan(1.d0) is much better. This is also guaranteed to be evaluated
at compile-time and suitable for a parameter.

Where in the standard is that required, either within an expression or
as part of a parameter definition? Isn't a compiler always allowed to
defer that evaluation until run time?

integer, save :: x(int(4000*atan(1.)))
x=3.1
print *,size(x)
end

Instead of 4000*atan(1.), how about 10**7*atan(1.)? Now we are in the
realm where the last bit of the function evaluation makes a difference
in the result. Now there can be problems associated with differences in
the evaluation of that expression at run time, compile time, different
floating point rounding modes, different optimization levels, compiler
options, and so on.

It still looks like intrinsic run time constants would solve many of
those issues.

Dimensions of saved arrays need to be known at compile time.
To be even more sure, put it in COMMON.

You are right about common being fixed size, but not about the first
statement. It is allowed to save an allocatable array whose size is
known only at run time.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/24/22 2:05 AM, gah4 wrote:

Note also, regarding comparisons for equality, at least some compilers
I know evaluate compile time expressions to different accuracy than
for run-time expressions. compile time atan(1.0) might differ from
run-time atan(1.0)

Good point. This is yet another good argument for having some intrinsic constants defined. I have used cross-compilers where the compile time expressions were evaluated with the numerical library of the host
machine, while the run time version of the same expression was evaluated
with the numerical library of the target machine. Those results
sometimes differed in the last few bits. My experience with this was in
the 1980s, but as far as I know, that is still allowed with modern
compilers.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/24/22 2:42 AM, Thomas Koenig wrote:

As long as the change is invisible to the user, yes (which
is another way of saying "no").

Haha. Sometimes you just have to take "yes" as an answer.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 24, 2022 at 8:38:00 AM UTC-7, Ron Shepard wrote:


(snip, I wrote)

integer, save :: x(int(4000*atan(1.)))

(snip)

You are right about common being fixed size, but not about the first statement. It is allowed to save an allocatable array whose size is
known only at run time.

I was going to disagree, as mine doesn't have the ALLOCATABLE
attribute, but then again, I am not sure that the compiler can't do the allocation at run time, anyway. I presume it can't look like it has
the allocatable attribute, though.

(It better not pass one to a subroutine with an ALLOCATABLE
argument, for example.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 24, 2022 at 12:42:11 AM UTC-7, Thomas Koenig wrote:

(snip)

10.1.12 Constant expression

1 A constant expression is an expression with limitations that
make it suitable for use as a kind type parameter, initializer,
or named constant. It is an expression in which each operation is
intrinsic, and each primary is

(1) a constant or subobject of a constant,

and where each subscript, section subscript, substring starting
point, substring ending point, and type parameter value is a
constant expression

(snip)

So, while evaluation at compile-time is not strictly mandated by
the standard (because the standard has no concept of compilation,

I have sometimes wondered why no Fortran interpreter.

Depending on how it is done, an interpreter could change the order
that things are done, but still give the effect that the standard requires.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 24, 2022 at 6:05:30 PM UTC+11, gah4 wrote:

Note also, regarding comparisons for equality, at least some compilers
I know evaluate compile time expressions to different accuracy than
for run-time expressions. compile time atan(1.0) might differ from
run-time atan(1.0)

That is a poor-quality implementation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:

I am more interested in some minor changes:
Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
COSD, SIND, and TAND will standardize what is a common extension.

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many

more variants.

I still have pi memorized to ten places from college. Wow, I graduated
from TAMU 40 years ago with a degree in Mechanical Engineering.

3.141592654d0

Lynn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 9:08:29 AM UTC+11, Lynn McGuire wrote:

On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:

I am more interested in some minor changes:
Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
COSD, SIND, and TAND will standardize what is a common extension.

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and

many more variants.

I still have pi memorized to ten places from college. Wow, I graduated
from TAMU 40 years ago with a degree in Mechanical Engineering.

3.141592654d0

.
Not enough for double precision.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:

I am more interested in some minor changes:
Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
COSD, SIND, and TAND will standardize what is a common extension.

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many

more variants.

I still have pi memorized to ten places from college. Wow, I graduated
from TAMU 40 years ago with a degree in Mechanical Engineering.

3.141592654d0

Not quite enough for double precision. I have (from school
days) just enough numbers for double precision memorized:
3.1415926535897932

Curiously appropriate, I had occasion to look at some
Fortran code at work yesterday, which set a double
precision variable named pi to 3.1415927 . Hmm...

The code also had two other characteristics: It had ^Z as the
last character in each file (which a modern compiler choked on,
but easy enough to remove), so it probably originated on MS-DOS
and some files had

$define test 0

and

$if test

(I'd have to boot may work laptop to make sure I have the
syntax remembered correctly). Out of interest: Any idea
what the compiler might have been? Maybe Microsoft Fortran
for MS-DOS?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 26, 2022 at 2:04:18 AM UTC-7, Thomas Koenig wrote:

Lynn McGuire <lynnmc...@gmail.com> schrieb:

(snip)

3.141592654d0

Not quite enough for double precision. I have (from school
days) just enough numbers for double precision memorized:
3.1415926535897932

Curiously appropriate, I had occasion to look at some
Fortran code at work yesterday, which set a double
precision variable named pi to 3.1415927 . Hmm...

A large number of programs need double precision to get
single precision results. If, for example, you do a numerical
derivative. Or even more, a second or third derivative,
you lose precision fast.

You might be especially unlucky, especially with some case of
trigonometric functions, but often enough it is close enough.

The code also had two other characteristics: It had ^Z as the
last character in each file (which a modern compiler choked on,
but easy enough to remove), so it probably originated on MS-DOS
and some files had

The ^Z convention came from text files on CP/M, where the file
system only keeps track of whole disk blocks. For some reason
that I never knew, it stayed around way too long on MS-DOS
systems, where the file system keeps byte file lengths.

It mostly depends on the editor, as some would add them,
and many programs would accept them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/26/22 4:04 AM, Thomas Koenig wrote:

Curiously appropriate, I had occasion to look at some
Fortran code at work yesterday, which set a double
precision variable named pi to 3.1415927 . Hmm...

I hate it when that happens. You don't know without looking through the
code if correcting that value for pi will make things better or
introduce internal consistency errors. And you seem to find these
mistakes at the worse time possible, when you are tracking down other
bugs with deadlines approaching.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <t1legp$m39$1@dont-email.me>, Lynn McGuire
<lynnmcguire5@gmail.com> writes:

On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:

I am more interested in some minor changes:
Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
COSD, SIND, and TAND will standardize what is a common extension.

I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many

I still have pi memorized to ten places from college. Wow, I graduated
from TAMU 40 years ago with a degree in Mechanical Engineering.

3.141592654d0

I knew 150 at one time, but still know 50.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ron Shepard <nospam@nowhere.org> schrieb:

On 3/26/22 4:04 AM, Thomas Koenig wrote:

Curiously appropriate, I had occasion to look at some
Fortran code at work yesterday, which set a double
precision variable named pi to 3.1415927 . Hmm...

I hate it when that happens. You don't know without looking through the
code if correcting that value for pi will make things better or
introduce internal consistency errors. And you seem to find these
mistakes at the worse time possible, when you are tracking down other
bugs with deadlines approaching.

In that particular case, it wasn't critical - it was an old
code where the question if it needs to be resurrected or not.
The algorithm is well documented, there is an executable that still
works, and the program isn't very big. The only problem I found
was that the source was incomplete. Finally, there is no hurry.

So, the decision will probably be to re-implement and test against
the old executable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)