Home > Archive > Fortran > December 2005 > writing formatted zeros with implicit formats
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
writing formatted zeros with implicit formats
|
|
| robert.corbett@sun.com 2005-12-15, 3:58 am |
| The Fortran 95 standard requires floating-point zeros written using
list-directed formatting or namelist formatting to be written as if
formatted using an E edit descriptor. The Fortran standards
committees, J3 and WG5, issued official interpretations confirming
this requirement.
For example, when the program
PROGRAM MAIN
PRINT *, -2.1, -1.2, 0.0, 1.1, 2.2
END
is compiled using Sun f95 and run, the output is
-2.1 -1.2 0.0E+0 1.1 2.2
Writing 0.0 instead of 0.0E+0 would not be standard conforming.
The Fortran 2003 standard has a different requirement. Fortran 2003
requires floating-point zeros to be written as if formatted using an
F edit descriptor. I am much happier with the new rule, but it poses
a backward compatibility problem. The problem is compounded by
size of Fortran 2003. The time required to transform Sun f95 into a
complete Fortran 2003 compiler will span some number of releases.
Fortran 2003 contains many extensions to Fortran 95. Those can
be implemented without violating the Fortran 95 standard. Changes,
such as the change to the way zeros are formatted, introduce
incompatibilities.
I would like to know how people think implementations should handle
such changes. Possible ways include:
1) Defer implementation of the changes until a full
implementation of Fortran 2003 is complete.
2) Implement the changes, but require the user to
specify an option to put the changes into effect.
After the implementation is complete, either
remove the option, or change the option default.
3) Implement the changes, but add an option to get
Fortran 95 behavior.
Bob Corbett
| |
| Jan Vorbrüggen 2005-12-15, 3:58 am |
| > 3) Implement the changes, but add an option to get
> Fortran 95 behavior.
It's that one for me.
OTOH, the RTL will end up evaluating dozens of environment variables to
support all that optional behaviour. What a waste...
Jan
| |
| robert.corbett@sun.com 2005-12-15, 7:57 am |
| > OTOH, the RTL will end up evaluating dozens of environment variables to
> support all that optional behaviour. What a waste...
Yes, the run-time library would be even more cluttered. However, the
options
I had in mind would be specified as compile-time options, not run-time
environment variables.
Bob Corbett
| |
| Jan Vorbrüggen 2005-12-15, 7:57 am |
| > Yes, the run-time library would be even more cluttered. However, the
> options I had in mind would be specified as compile-time options, not
> run-time environment variables.
Ick. Then every call to list-directed writes of a floating-point number
either has an extra argument that specifies how this case is to be handled,
or you will provide two routines with slightly different names and slightly
different functionality, and the compiler selects which to call?
Well, the last alternative of the three (the third being the run-time control)
probably is the least onerous, so go for it.
Jan
| |
| John Harper 2005-12-15, 7:01 pm |
| In article <1134632379.672465.126120@z14g2000cwz.googlegroups.com>,
<robert.corbett@sun.com> wrote:
>The Fortran 95 standard requires floating-point zeros written using
>list-directed formatting or namelist formatting to be written as if
>formatted using an E edit descriptor.
....
>The Fortran 2003 standard has a different requirement. Fortran 2003
>requires floating-point zeros to be written as if formatted using an
>F edit descriptor.
....
>I would like to know how people think implementations should handle
>such changes. Possible ways include:
>
> 1) Defer implementation of the changes until a full
> implementation of Fortran 2003 is complete.
>
> 2) Implement the changes, but require the user to
> specify an option to put the changes into effect.
> After the implementation is complete, either
> remove the option, or change the option default.
>
> 3) Implement the changes, but add an option to get
> Fortran 95 behavior.
I'd go for (3), but I don't now remember what Bob's company did with
previous changes like f77 -> f90 and f90 -> f95. If that was different,
there's also a case for doing that again, so that long-term clients
will find the company doing something they're used to.
--
John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| robert.corbett@sun.com 2005-12-16, 3:58 am |
| > Ick. Then every call to list-directed writes of a floating-point number
> either has an extra argument that specifies how this case is to be handled,
> or you will provide two routines with slightly different names and slightly
> different functionality, and the compiler selects which to call?
We could use either approach. The parameters for formatted I/O include
a
32-bit flags argument. We currently use 22 of the bits. Calling
getenv is
much more expensive than passing an extra argument.
Bob Corbett
| |
| robert.corbett@sun.com 2005-12-16, 3:58 am |
| > I'd go for (3), but I don't now remember what Bob's company did with
> previous changes like f77 -> f90 and f90 -> f95. If that was different
> there's also a case for doing that again, so that long-term clients
> will find the company doing something they're used to.
The transition from f90 to f95 was easy. The only run-time library
routines that had to change were the ones that implement the
function SIGN. The run-time libraries now provide routines
__f90_sign and __f95_sign.
The transition from f77 to f90 was a mess. Sun f90 is based on
another vendor's implementation. The 1.x releases of Sun f90 used
that vendor's run-time libraries. Those libraries were in no way
compatible with Sun's f77 libraries. The 2.0 release of Sun f90
and all later releases are based on a library that was written from
scratch. That library was somewhat warped to make it more
compatible with the Sun f77 libraries.
Bob Corbett
| |
| Jan Vorbrüggen 2005-12-19, 3:58 am |
| > We could use either approach. The parameters for formatted I/O include
> a 32-bit flags argument. We currently use 22 of the bits.
So that approach sounds reasonable.
> Calling getenv is much more expensive than passing an extra argument.
For sure, but you'd only need to do it once and then patch the right
routine into place, I would think.
Nonetheless, if there already is an argument ready to take that option
flag, seems like the way to go.
Jan
|
|
|
|
|