Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fortran 202X

515 views
Skip to first unread message

chinoun...@gmail.com

unread,
Oct 29, 2020, 6:43:27 AM10/29/20
to
Fortran 202x contains several extensions to Fortran 2018; these are listed below.

• Source form: The maximum length of a line in free form source has been increased*. The maximum length of a statement has been increased. The limit on the number of continuation lines has been removed.

• Data declaration: A data object with a coarray component can be an array or allocatable. TYPEOF and CLASSOF type specifiers can be used to declare one or more entities to have the same type and type parameters as another entity.

• Data usage and computation: Binary, octal, and hexadecimal literal constants can be used in additional contexts. A deferred-length allocatable errmsg-variable is allocated by the processor to the length of the explanatory message. An ALLOCATE statement can specify the bounds of an array allocation with array expressions. A pointer assignment statement can specify lower bounds or rank remapping with array expressions.

• Input/output: The AT edit descriptor provides output of character values with trailing blanks trimmed. The LEADING_ZERO= specifier in the OPEN and WRITE statements, and the LZP, LZS and LZ control edit descriptors, provide control of optional leading zeros during formatted output. A deferred-length allocatable iomsgvariable is allocated by the processor to the length of the explanatory message. A deferred-length allocatable io-unit in a WRITE statement is allocated by the processor to the length of the record to be written.

• Execution control: The REDUCE locality specifier for the DO CONCURRENT construct specifies reduction variables for the loop. The NOTIFY WAIT statement, NOTIFY= specifier on an image selector, and the NOTIFY_TYPE from the intrinsic module ISO_FORTRAN_ENV provide one-sided data-oriented synchronization between images.

• Intrinsic procedures and modules: The intrinsic functions ACOSD, ASIND, ATAND, ATAN2D, COSD, SIND, and TAND are trigonometric functions in which angles are specified in degrees. The intrinsic functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI are trigonometric functions in which angles are specified in halfrevolutions (that is, as multiples of π). The intrinsic function SELECTED_LOGICAL_KIND returns kind type parameter values for type logical. The intrinsic subroutine SPLIT parses a string into tokens. The procedures C_F_STRPOINTER and F_C_STRING have been added to the intrinsic module ISO_C_BINDING to assist in the use of null-terminated strings. The subroutine C_F_POINTER in the intrinsic module ISO_C_BINDING has an extra optional dummy argument, LOWER, that specifies the lower bounds for FPTR. Additional named constants LOGICAL8, LOGICAL16, LOGICAL32, LOGICAL64, and REAL16 have been added to the intrinsic module ISO_FORTRAN_ENV. When a deferred-length allocatable actual argument of an intrinsic procedure is to be assigned character data, it is allocated by the processor to the length of the data. Execution of a collective subroutine can be successful on an image even when an error condition occurs for the corresponding execution on another image.

• Program units and procedures: A procedure can be specified to be a simple procedure; a simple procedure references or defines nonlocal variables only via its dummy arguments.

j3-fortran/20-007.pdf(Fortran 202X Working Document)/Introduction

* to 10000 characters.

Gary Scott

unread,
Oct 29, 2020, 9:05:53 AM10/29/20
to
an odd value, I would have chosen 32767 or 65535.

Dan Nagle

unread,
Oct 29, 2020, 10:23:36 AM10/29/20
to
Hi,

On 2020-10-29 13:05:49 +0000, Gary Scott said:

> On 10/29/2020 5:43 AM, chinoun...@gmail.com wrote:
>
>> Fortran 202x contains several extensions to Fortran 2018; these are
>> listed below.
>>
>>
>>
>> • Source form: The maximum length of a line in free form source has
>> been increased*. The maximum length of a statement has been increased.
>> The limit on the number of continuation lines has been removed.
>>


>> * to 10000 characters.
>>
>>
>>
> an odd value, I would have chosen 32767 or 65535.
>


Line length and statement length are human-facing quantities,
so I thought even decimal values would be best. 10000 for line length
and 1000000 for statement length seem to cover the use-cases
supporting this work-item.

C/C++ have limits of 4095 for line length.

The most important additional requirement re source form
is that the processor will be required to report too-long
a line or statement.


--
Cheers!

Dan Nagle

Gary Scott

unread,
Oct 29, 2020, 10:47:11 AM10/29/20
to
On 10/29/2020 9:23 AM, Dan Nagle wrote:
> Hi,
>
> On 2020-10-29 13:05:49 +0000, Gary Scott said:
>
>> On 10/29/2020 5:43 AM, chinoun...@gmail.com wrote:
>>
>>> Fortran 202x contains several extensions to Fortran 2018; these are
>>> listed below.
>>>
>>>
>>>
>>> • Source form: The maximum length of a line in free form source has
>>> been increased*. The maximum length of a statement has been
>>> increased. The limit on the number of continuation lines has been
>>> removed.
>>>
>
>
>>> * to 10000 characters.
>>>
>>>
>>>
>> an odd value, I would have chosen 32767 or 65535.
>>
>
>
> Line length and statement length are human-facing quantities,
> so I thought even decimal values would be best.  10000 for line length
> and 1000000 for statement length seem to cover the use-cases
> supporting this work-item.
>
> C/C++ have limits of 4095 for line length.
>
> The most important additional requirement re source form
> is that the processor will be required to report too-long
> a line or statement.
>
>
I thought 32767 because that is the default internal limit for string
length for some compilers I know of.

mies...@gmail.com

unread,
Oct 29, 2020, 4:52:33 PM10/29/20
to
Thanks to everyone working on this. My personal favorites are (3) the increased max length of a statement, (1) data objects with a coarray component can be an array or allocatable, and (2) NOTIFY WAIT.

We did discuss a NOTIFY_QUERY recently here: https://github.com/j3-fortran/fortran_proposals/issues/20
Apparently it did not make it into Fortran 202X yet. I had some hope to use NOTIFY_WAIT together with NOTIFY_QUERY as another way to develop user-defined synchronization methods.


cheers

JCampbell

unread,
Oct 30, 2020, 12:04:02 AM10/30/20
to
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 standardise what is a common extension.

john.a...@jtekt.com

unread,
Mar 23, 2022, 10:22:25 AM3/23/22
to
> 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.

Ron Shepard

unread,
Mar 23, 2022, 11:00:01 AM3/23/22
to
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

Robin Vowels

unread,
Mar 23, 2022, 12:31:05 PM3/23/22
to
4*ATAN(1D0) will give adequate accuracy, double precision;
4*ATAN(1.0) will do the same for single precision.

Thomas Koenig

unread,
Mar 23, 2022, 2:10:19 PM3/23/22
to
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.

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

Ron Shepard

unread,
Mar 24, 2022, 12:08:31 AM3/24/22
to
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?

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

gah4

unread,
Mar 24, 2022, 3:05:30 AM3/24/22
to
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)

Thomas Koenig

unread,
Mar 24, 2022, 3:42:11 AM3/24/22
to
Ron Shepard <nos...@nowhere.org> schrieb:
> 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?

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

Robin Vowels

unread,
Mar 24, 2022, 5:54:03 AM3/24/22
to
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.

Ron Shepard

unread,
Mar 24, 2022, 11:23:22 AM3/24/22
to
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

Ron Shepard

unread,
Mar 24, 2022, 11:38:00 AM3/24/22
to
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

Ron Shepard

unread,
Mar 24, 2022, 11:41:39 AM3/24/22
to
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

gah4

unread,
Mar 24, 2022, 3:34:43 PM3/24/22
to
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.


gah4

unread,
Mar 24, 2022, 3:38:14 PM3/24/22
to
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.)


Robin Vowels

unread,
Mar 25, 2022, 12:48:34 AM3/25/22
to
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.

Lynn McGuire

unread,
Mar 25, 2022, 6:08:29 PM3/25/22
to
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

Robin Vowels

unread,
Mar 26, 2022, 12:36:40 AM3/26/22
to
.
Not enough for double precision.

Thomas Koenig

unread,
Mar 26, 2022, 5:04:18 AM3/26/22
to
Lynn McGuire <lynnmc...@gmail.com> schrieb:
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?

gah4

unread,
Mar 26, 2022, 5:18:10 AM3/26/22
to
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.


Ron Shepard

unread,
Mar 26, 2022, 11:55:04 AM3/26/22
to
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

Phillip Helbig (undress to reply)

unread,
Mar 26, 2022, 2:40:16 PM3/26/22
to
In article <t1legp$m39$1...@dont-email.me>, Lynn McGuire
<lynnmc...@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.

Thomas Koenig

unread,
Mar 26, 2022, 4:01:04 PM3/26/22
to
Ron Shepard <nos...@nowhere.org> schrieb:
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.
0 new messages