Re: reading what you write

Gene Wagenbreth wrote:
I have two programs. The writer writes data that the reader reads.
To avoid work, I use a '*' format. So I have:

writer: write(6,*) (a(i,j,k,l),i=1,ni)

reader: read(6,*,end=999,err=998) (a(i,j,k,l),i=1,ni)

The reader takes the err branch to 998. The file in question was
over 100 mbyte with over 100,000 lines. It took a while to track
down.

Problem 1:

Normally zero was written out as 0.000000000 . Occassionally it
came out as 0.0000000000E+000 . I asume this is because there
was unormalized zero or something. The reader got an error on
this.

I am aware that some implementations output differently for denormal
numbers than for ordinary values, but such a value is *not* zero and
should not output as zero. However you say your problem is on input
and for that both the above forms are legal inputs and have the same
value (zero). Assuming your problem is really this, your I/O library
is broken.

Problem 2:
Some output was 'NaN' . I think the reader also got an error
on this.

I suppose that it's possible that the program that wrote the data used
a Fortran implementation that supports NaNs on I/O and the program
you're reading the data with used a different Fortran compiler.
You don't say what implementation you use or what system you're
on, so it's speculation. If the I/O library supports the IEEE stuff,
then NaN is a valid input (with a sign even). You can even have
an indication after the NaN in the input (it's implementation dependent
and appears to be intended to allow you to distinguish between
quiet and signaling NaNs).

I believe that in general, whatever is written with a '*' format
should be acceptable to be read with a '*' format.

Exactly so. Especially if both input and output are in accordance with
the standard - it's required. Well, for this stuff it is. Depending on how
you've opened a file, when you output a character string it may not be
delimited in a way that permits subsequently reading it as just a character
value. But that has nothing to do with floating point I/O.

As often the case here, you probably need to provide more specific
information for someone to help. An actual pair of short programs
that fail as you've seen would be good.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.

Relevant Pages

  • Re: reading what you write
    ... I use a '*' format. ... The reader takes the err branch to 998. ... manage to find a compiler that couldn't sucessfully read both of these ... For the NaN case, things are more complicated. ...
    (comp.lang.fortran)
  • Re: Newbie to Forums, SIMD question
    ... Both of these converse most rapidly when x is near zero. ... mov ebx,ecx ... So far we've ignored zeros, denormals, infinities and NaNs. ... infinity or NaN, nor will it work for a negative x. ...
    (comp.lang.asm.x86)
  • Re: On writing negative zero - with or without sign
    ... Using a different convention for zero magnitude values still ... "first differences of temperature readings". ... If the reader of the data doesn't know what first differences are, ...
    (comp.lang.fortran)
  • Re: Im always a winner
    ... Divide by zero in any equation and you get ... so you can't just check it against a NaN you happen to have ... True, but then infinity isn't a number either, ...
    (alt.usage.english)
  • Re: Im always a winner
    ... If black is not a color then zero is not a number. ... Divide by zero in any equation and you get ... NaN is that it isn't equal to anything, including itself, so you can't ... opposite signs or subtract an infinite value from another with the ...
    (alt.usage.english)