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 manymore variants.
more variants.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
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.
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.
On 3/23/22 1:10 PM, Thomas Koenig wrote:
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?
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?
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 evaluatedWhere in the standard is that required, either within an expression or
at compile-time and suitable for a parameter.
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 thatThat was the point of the original post. Namely if there is a single
the values _are_ exact.
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,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
but otherwise floating point expressions should be treated with
care (and +/- epsilon).
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 theWhy not? Is that part of the standard specification, or it it just the
IEEE rounding modes apply.
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 modeThat would be one approach. However, as you say, the programmer would
could serve in principle, but could cause intermediate calculations
in higher precision than anticipated, which might be problematic.
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.
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)
As long as the change is invisible to the user, yes (which
is another way of saying "no").
integer, save :: x(int(4000*atan(1.)))
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.
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
So, while evaluation at compile-time is not strictly mandated by
the standard (because the standard has no concept of compilation,
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)
more variants.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
On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:many more variants.
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
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
On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:more variants.
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
Lynn McGuire <lynnmc...@gmail.com> schrieb:
3.141592654d0Not 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
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...
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
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 98:24:44 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,579 |