Fortran - Formatted read question

Author

Formatted read question

Steven G. Kargl

2004-12-28, 8:58 pm

Gang,

What is the "correct" behavior for a conforming compiler
with following code

program a
character*15 b
real x
b = 'E+00'
read(b,'(E15.8)') x
print *, x
end

My interpretation of the standard and what a compiler should
do is at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

g77 gives
troutmask:kargl[218] f77 -o a a.f
troutmask:kargl[219] ./a
0.

gfortran gives
troutmask:kargl[220] gfc -o a a.f
troutmask:kargl[221] ./a
At line 5 of file a.f
Fortran runtime error: Bad value during floating point read

NAG's FreeBSD compiler agrees with gfortran.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Dick Hendrickson

2004-12-28, 8:58 pm

Steven G. Kargl wrote:
> Gang,
>
> What is the "correct" behavior for a conforming compiler
> with following code
>
> program a
> character*15 b
> real x
> b = 'E+00'

For F95, a real constant must have a digit-string and
optionally, a decimal point before the exponent letter
(rule 412, Page 33, etc.). So, B doesn't contain a valid
representation of a real constant.

> read(b,'(E15.8)') x

According to line 33 of Page 167, the allowed forms
for E input are the same as fro F input. That's remarkably
obtuse, even for a standard, sigh. But, looking at the F
input (page 167, line 7), the input field "consists of ...
string of one or more digits optionally containing a decimal
point...[optionally] followed by an exponent...

So, the input string isn't "correct" for the format.

Unfortunately, "the set of input/output error conditions
is processor dependent." (page 149, line 40) So, there's
no "correct" processor behaviour. An error message is fine,
but so is calling it zero (or starting WWIII).

At least, that's the way I'd read F95. I don't think
anything interesting has happened here in F2003.

Dick Hendrickson

> print *, x
> end
>
> My interpretation of the standard and what a compiler should
> do is at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
>
> g77 gives
> troutmask:kargl[218] f77 -o a a.f
> troutmask:kargl[219] ./a
> 0.
>
> gfortran gives
> troutmask:kargl[220] gfc -o a a.f
> troutmask:kargl[221] ./a
> At line 5 of file a.f
> Fortran runtime error: Bad value during floating point read
>
> NAG's FreeBSD compiler agrees with gfortran.
>

Steven G. Kargl

2004-12-28, 8:58 pm

In article <RpkAd.1180609$Gx4.349371@bgtnsc04-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> writes:
>
> Steven G. Kargl wrote:
>
> For F95, a real constant must have a digit-string and
> optionally, a decimal point before the exponent letter
> (rule 412, Page 33, etc.). So, B doesn't contain a valid
> representation of a real constant.
>
>
> According to line 33 of Page 167, the allowed forms
> for E input are the same as fro F input. That's remarkably
> obtuse, even for a standard, sigh. But, looking at the F
> input (page 167, line 7), the input field "consists of ...
> string of one or more digits optionally containing a decimal
> point...[optionally] followed by an exponent...
>
> So, the input string isn't "correct" for the format.
>
> Unfortunately, "the set of input/output error conditions
> is processor dependent." (page 149, line 40) So, there's
> no "correct" processor behaviour. An error message is fine,
> but so is calling it zero (or starting WWIII).

Dick, thanks for your interpretation. It matches my reading of
the various standards. I, however, find calling it zero to
lead to some confusion with the last sentence of the sections
I quote below.

From F77:

13.5.9 Numeric Editing
The I, F, E, D, and G edit descriptors are used to specify input/output
of integer, real, double precision, and complex data. The following
general rules apply:
(1) On input, leading blanks are not significant. The interpretation
of blanks, other than leading blanks, is determined by a combination
of any BLANK= specifier and any BN or BZ blank control that is
currently in effect for the unit (13.5.8). Plus signs may be omitted.
A field of all blanks is considered to be zero.

From a May 2004 draft of F2003:

10.6.1 Numeric editing
The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to
specify the input/output of integer, real, and complex data. The
following general rules apply:
(1) On input, leading blanks are not significant. When the input field
is not an IEEE exceptional specification (10.6.1.2.1), the
interpretation of blanks, other than leading blanks, is determined
by the blank interpretation mode (10.7.6). Plus signs may be omitted.
A field containing only blanks is considered to be zero.

It seems odd to me that one would set x to zero if the 'input string is not
"correct" for the format', because the user cannot distinguish this
possible error from the standard mandate of "A field containing only blanks
is considered to be zero."

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Dick Hendrickson

2004-12-28, 8:58 pm

Steven G. Kargl wrote:
> In article <RpkAd.1180609$Gx4.349371@bgtnsc04-news.ops.worldnet.att.net>,
> Dick Hendrickson <dick.hendrickson@att.net> writes:
>
>
>
> Dick, thanks for your interpretation. It matches my reading of
> the various standards. I, however, find calling it zero to
> lead to some confusion with the last sentence of the sections
> I quote below.
>
>
> From F77:
>
> 13.5.9 Numeric Editing
> The I, F, E, D, and G edit descriptors are used to specify input/output
> of integer, real, double precision, and complex data. The following
> general rules apply:
> (1) On input, leading blanks are not significant. The interpretation
> of blanks, other than leading blanks, is determined by a combination
> of any BLANK= specifier and any BN or BZ blank control that is
> currently in effect for the unit (13.5.8). Plus signs may be omitted.
> A field of all blanks is considered to be zero.
>
> From a May 2004 draft of F2003:
>
> 10.6.1 Numeric editing
> The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to
> specify the input/output of integer, real, and complex data. The
> following general rules apply:
> (1) On input, leading blanks are not significant. When the input field
> is not an IEEE exceptional specification (10.6.1.2.1), the
> interpretation of blanks, other than leading blanks, is determined
> by the blank interpretation mode (10.7.6). Plus signs may be omitted.
> A field containing only blanks is considered to be zero.
>
> It seems odd to me that one would set x to zero if the 'input string is not
> "correct" for the format', because the user cannot distinguish this
> possible error from the standard mandate of "A field containing only blanks
> is considered to be zero."
>
Steve,

Yeah, it's odd. Personally, I'd prefer an error message
since I don't like compilers to (silently) fix my mistakes.
(Did I mean to enter "0E+00" or "9E+00" when I didn't hit
the sticky digit key hard enough?) But, the standard
generally allows the processor to silently extend things and
calling "no mantissa" a zero is more reasonable than
launching a nova bomb into the sun.

Dick Hendrickson

Dr Ivan D. Reid

2004-12-29, 8:57 am

On Tue, 28 Dec 2004 22:07:38 +0000 (UTC),
Steven G. Kargl <kargl@troutmask.apl.washington.edu>
wrote in <cqslfa$j1a$2@gnus01.u.washington.edu>:

> 13.5.9 Numeric Editing
> of blanks, other than leading blanks, is determined by a combination
> of any BLANK= specifier and any BN or BZ blank control that is
> currently in effect for the unit (13.5.8). Plus signs may be omitted.
> A field of all blanks is considered to be zero.
....
> A field containing only blanks is considered to be zero.

A field containing 'E+00' can not be considered to be all blanks!

--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@brunel.ac.uk Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".

Steven G. Kargl

2004-12-29, 3:58 pm

In article <slrnct4usp.21v.Ivan.Reid@loki.brunel.ac.uk>,
"Dr Ivan D. Reid" <Ivan.Reid@brunel.ac.uk> writes:
> On Tue, 28 Dec 2004 22:07:38 +0000 (UTC),
> Steven G. Kargl <kargl@troutmask.apl.washington.edu>
> wrote in <cqslfa$j1a$2@gnus01.u.washington.edu>:
>
> ...
>
> A field containing 'E+00' can not be considered to be all blanks!
>

Yes, I know. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

I have seen reports that some commercial compilers will print 0
while others issue an error. I suspect, but cannot verify, that
some of those that print 0 are confusing "field" with "significand".

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Sponsored Links