Home > Archive > Fortran > April 2005 > What is a field of all blanks?
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 |
What is a field of all blanks?
|
|
| Steven G. Kargl 2005-03-31, 8:57 pm |
| Program FM110.FOR from the NIST Fortran 77 testsuite has
a test that can be summarized as follows:
program blanks
a = 42.
open(19)
write(19,'(A15)') 'E+00'
rewind(19)
read(19,'(E15.8)') a
print *,a
end
The newest standard states:
10.2.2 Fields
A "field" is a part of a record that is read on input or written on
output when format control encounters a data edit descriptor or a
character string edit descriptor. The "field width" is the size in
characters of the field.
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.
Should the above program issue an error or print a zero? The
definition of field in 10.2.2 is somewhat lacking.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Richard E Maine 2005-03-31, 8:57 pm |
| In article <d2hp78$pku$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
> Program FM110.FOR from the NIST Fortran 77 testsuite has
> a test that can be summarized as follows:
>
> program blanks
> a = 42.
> open(19)
> write(19,'(A15)') 'E+00'
> rewind(19)
> read(19,'(E15.8)') a
> print *,a
> end
>
> The newest standard states
>
> 10.2.2 Fields
> A "field" is a part of a record that is read on input or written on
> output when format control encounters a data edit descriptor or a
> character string edit descriptor. The "field width" is the size in
> characters of the field.
>
> 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.
>
> Should the above program issue an error or print a zero? The
> definition of field in 10.2.2 is somewhat lacking.
I'd say that it "should" issue an error. Of course, that "should" is not
required by the standard, but is my user preference. The standard just
says that the code is nonstandard; this is not a case where diagnosis of
the error is required, so a compiler is free to interpret it as an
extension.
I'm not sure what is wrong with the above-cited definition of "field"; I
don't see what is lacking. The part of this particular record that
constitutes the field is all 15 characters, that being the field width
specified in the edit descriptor. Are you perhaps thinking that just the
part before the exponent is a field? If that's what you are thinking,
then I disagree with that interpretation - that is not the "part of a
record that is read on input or written on output when format control
encounters a data edit descriptor..". The data edit descriptor describes
the whole 15 characters here - not just part of them.
Anyway, I see no digits before the exponent in this field. The
definition of Ew.d input refers to Fw.d,which requires "a string of one
or more digits..." [228:11-12] of f2003. The field does not contain only
blanks (it has an E+00 in it).
Oh. If I were to be really, really nitpicky, I would say that it is
impossible to tell what the answer should be because there is no rewind
before the write. There could possibly already be a file with something
else in the first record. The standard doesn't require that compilers
open files positioned at the beginning. All compilers do, with one very
notable exception, but the standard doesn't require it.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Phillip Helbig---remove CLOTHES to reply 2005-03-31, 8:57 pm |
| In article <nospam-94C6A1.14272231032005@news.supernews.com>, Richard E
Maine <nospam@see.signature> writes:
> The standard doesn't require that compilers
> open files positioned at the beginning. All compilers do, with one very
> notable exception, but the standard doesn't require it.
What is the notable exception?
| |
| Steve Lionel 2005-03-31, 8:57 pm |
| On Thu, 31 Mar 2005 21:14:16 +0000 (UTC), kargl@troutmask.apl.washington.edu
(Steven G. Kargl) wrote:
>Program FM110.FOR from the NIST Fortran 77 testsuite has
>a test that can be summarized as follows:
>
> program blanks
> a = 42.
> open(19)
> write(19,'(A15)') 'E+00'
> rewind(19)
> read(19,'(E15.8)') a
> print *,a
> end
>
>
>Should the above program issue an error or print a zero? The
>definition of field in 10.2.2 is somewhat lacking.
The test was written against Fortran 77, and relies on aspects of the language
which changed in Fortran 90.
In Fortran 77, the program should print a zero as the field read in would be
equivalent to:
E+0000000000000
Fortran 77 did not require any digits before the E.
In Fortran 90, you have two changes. The first is that BLANK='NULL' is the
default for units explicitly opened. so the field read in would be as if it
were the four characters E+00 and the format changed to E4.4.
The second change is that Fortran 90 requires at least one digit before the
exponent letter, making this program an error.
So, the answer depends on which standard the compiler is following. Our F95
compilers have switches for specifying F77 or F66 run-time behavior when that
conflicts with F90/F95. I imagine many other compilers do too.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Steven G. Kargl 2005-03-31, 8:57 pm |
| In article <nospam-94C6A1.14272231032005@news.supernews.com>,
Richard E Maine <nospam@see.signature> writes:
> In article <d2hp78$pku$1@gnus01.u.washington.edu>,
> kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
>
>
> I'd say that it "should" issue an error. Of course, that "should" is not
> required by the standard, but is my user preference. The standard just
> says that the code is nonstandard; this is not a case where diagnosis of
> the error is required, so a compiler is free to interpret it as an
> extension.
>
> I'm not sure what is wrong with the above-cited definition of "field";
> I don't see what is lacking. The part of this particular record that
> constitutes the field is all 15 characters, that being the field width
> specified in the edit descriptor. Are you perhaps thinking that just the
> part before the exponent is a field?
10.2.2 seems to me to be a circular definition. 'A "field" is a part
of a record ... The "field width" is the size in characters of the
field.' So what is "a part of a record". Is the missing significand
in "E+00" a part of a record?
>
> Anyway, I see no digits before the exponent in this field. The
> definition of Ew.d input refers to Fw.d,which requires "a string of one
> or more digits..." [228:11-12] of f2003. The field does not contain only
> blanks (it has an E+00 in it).
>
For my actual analysis, which agrees with your preference, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Steven G. Kargl 2005-03-31, 8:57 pm |
| In article <vcuo41pu8jc41d939n8ljei1avijcubgl7@4ax.com>,
Steve Lionel <Steve.Lionel@REMOVEintelME.com> writes:
> On Thu, 31 Mar 2005 21:14:16 +0000 (UTC), kargl@troutmask.apl.washington.edu
> (Steven G. Kargl) wrote:
>
>
> The test was written against Fortran 77, and relies on aspects of the language
> which changed in Fortran 90.
>
> In Fortran 77, the program should print a zero as the field read in would be
> equivalent to:
>
> E+0000000000000
>
> Fortran 77 did not require any digits before the E.
Well, you certainly have much more experience with Fortran than I.
But, from the Fortran 77 standard (ansi-x3dot9-1978-Fortran77.pdf)
4.4.1 Basic Real Constant
The form of a basic real constant is an optional sign, an integer part,
a decimal point, and a fractional part, in that order. Both the integer
part and the fractional part are strings of digits; either of these parts
may be omitted but not both. A basic real constant may be written with
more digits than a processor will use to approximate the value of the
constant. A basic real constant is interpreted as a decimal number.
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.
12.10.1 OPEN Statement
BLANK = blnk
blnk is a character expression whose value when any trailing blanks are
removed is NULL or ZERO. If NULL is specified, all blank characters in
numeric formatted input fields on the specified unit are ignored except
that a field of all blanks has a value of zero. If ZERO is specified,
all blanks other than leading blanks are treated as zeros. If this
specifier is omitted, a value of NULL is assumed. This specifier is
permitted only for a file being connected for formatted input/output.
I can't find a passage that requires the field read in to be
E+0000000000000.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Richard E Maine 2005-03-31, 8:57 pm |
| In article <d2hv6d$tsc$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
> 10.2.2 seems to me to be a circular definition. 'A "field" is a part
> of a record ... The "field width" is the size in characters of the
> field.' So what is "a part of a record". Is the missing significand
> in "E+00" a part of a record?
That's because you omitted part of the definition. The definition does
not say just "A field is a part of a record". It says "A field is a part
of a record *THAT*..." (emphasis mine). The "that" is important. In
fact, as an editor, I am very sensitive to the distinction between
"that" and "which". Lots of people are  by the distinction,
which is quite relevant here, because you seem to be reading it as
though it were a "which".
The words I learned were that "that" is restrictive and "which" is
descriptive. To elaborate a bit, "which" is an additional comment - one
that is not necessary to understand the meaning of what comes before it.
On the other hand "that" modifies the meaning of what comes before it;
leaving out a "that" phrase changes the meaning.
So it is part of the definition of "field" that it is a part of the
record "that is read on input or written on output when format control
encounters a data edit descriptor or a character string edit
descriptor". It isn't just any old part of a record - it is a part of a
record meeting that restriction. in this case, it is the whole 15
characters - not some smaller part.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Richard E Maine 2005-03-31, 8:57 pm |
| In article <vcuo41pu8jc41d939n8ljei1avijcubgl7@4ax.com>,
Steve Lionel <Steve.Lionel@REMOVEintelME.com> wrote:
> Fortran 77 did not require any digits before the E.
Hmm. I'm not sure of that, but I'd have to read more carefully than I
have time for at the moment. I see that f77 says "a string of digits".
Could that string have zero digits? Hmm. That needs more careful
reading. Lagter standards say "one or more" making it explicit, but I'm
less sure on f77.
> In Fortran 90, you have two changes. The first is that BLANK='NULL' is the
> default for units explicitly opened.
Now that one I *AM* sure about. This is not an f90 change. F77 also
specified blank='null' as the default for files explicitly opened. I
very distinctly recall that, and indeed I see it on page 12-20 of f77 as
explicitly as could be.
What you are almost surely thinking about is the situation when there is
*NOT* an explicit open. I recall being quite surprised when at least one
f77 compiler (VAX comes to mind :-)) treated things differently
depending on whether there was an explicit open or not. That bit me in
some of my code. I had to fix my code when it was pointed out to me that
the blank='null' default was only specified for OPEN statements, leaving
internal reads (which is where it bit me) system-dependent. That
inconsistency did get "fixed" in f90 (though incompletely, as I recall;
another forgotten case got fixed later).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Richard E Maine 2005-03-31, 8:57 pm |
| In article <d2hu3s$p7h$1@online.de>,
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
reply) wrote:
> In article <nospam-94C6A1.14272231032005@news.supernews.com>, Richard E
> Maine <nospam@see.signature> writes:
>
>
> What is the notable exception?
Stu Feldman's (I hope I spelled that right) first f77 compiler. THis was
allegedly done at least partly to make the point that the standard
didn't specify it. There was also some justification for it as useful,
given the lack of a "position file to the end" statement, but the way I
heard it (third hand at best) was that teh choice was largely intended
to make a point about the standard's inadequacy.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| John Harper 2005-04-01, 3:59 am |
| In article <nospam-1DAA24.15542931032005@news.supernews.com>,
Richard E Maine <nospam@see.signature> wrote:
>
>The words I learned were that "that" is restrictive and "which" is
>descriptive. To elaborate a bit, "which" is an additional comment - one
>that is not necessary to understand the meaning of what comes before it.
>On the other hand "that" modifies the meaning of what comes before it;
>leaving out a "that" phrase changes the meaning.
Is this a case where US usage is slightly different from UK etc?
Sir Ernest Gowers "The Complete Plain Words" agrees on 'commenting'
clauses: they must use "which". He then says "With a defining clause,
either _which_ or _that_is permissible, but _that_ is to be preferred."
What I learned was that a clause using "which" should be enclosed in
commas if it is commenting, but not if it is defining. Examples:
The programs, which had bugs, were changed.
[commenting: all those programs had bugs and they were all changed.]
The programs which had bugs were changed.
[defining: all the programs with bugs were changed, but some
programs had no bugs and were left unchanged. Permissible but not
preferred according to Gowers, disapproved of by Maine.]
The programs that had bugs were changed.
[defining: same meaning as the previous example, preferred by Gowers,
the only possibility for Maine.]
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
| |
| Phillip Helbig---remove CLOTHES to reply 2005-04-01, 3:59 am |
| In article <nospam-0AC06A.16053931032005@news.supernews.com>, Richard E
Maine <nospam@see.signature> writes:
> Stu Feldman's (I hope I spelled that right) first f77 compiler. THis was
> allegedly done at least partly to make the point that the standard
> didn't specify it. There was also some justification for it as useful,
> given the lack of a "position file to the end" statement, but the way I
> heard it (third hand at best) was that teh choice was largely intended
> to make a point about the standard's inadequacy.
Actually, in Fortran77 I would have preferred this: trivial to get to
the end of the file, and easy (REWIND) to get to the beginning.
I seem to remember one Fortran77 compiler which positioned the files at
the end after an open and stayed there if the next statement was WRITE.
However, if the next statement was READ, it did a silent REWIND.
| |
| Gordon Sande 2005-04-01, 3:59 pm |
|
Phillip Helbig---remove CLOTHES to reply wrote:
> In article <nospam-94C6A1.14272231032005@news.supernews.com>, Richard E
> Maine <nospam@see.signature> writes:
>
>
>
>
> What is the notable exception?
>
I have a strong recollection, that is somewhat short on detail, of using
OS/360 where the JCL defaulted (disk) files to opening at record 1 but
that it was fairly easy (within the notion of easy for JCL) to position
a file so that a task could start reading from the left over position.
I recall doing this either to skip initial headers or to allow multiple
sets of data to exist in a single file.
For tapes this was so much the case that at one time it was considered
good style to start with a rewind in case the tape was not at its
beginning.
| |
| Steve Lionel 2005-04-01, 3:59 pm |
| On Thu, 31 Mar 2005 16:02:50 -0800, Richard E Maine <nospam@see.signature>
wrote:
>
>Hmm. I'm not sure of that, but I'd have to read more carefully than I
>have time for at the moment. I see that f77 says "a string of digits".
>Could that string have zero digits? Hmm. That needs more careful
>reading. Lagter standards say "one or more" making it explicit, but I'm
>less sure on f77.
The implementations I worked on allowed zero digits here. I think the wording
in F77 was ambiguous.
>
>Now that one I *AM* sure about. This is not an f90 change. F77 also
>specified blank='null' as the default for files explicitly opened. I
>very distinctly recall that, and indeed I see it on page 12-20 of f77 as
>explicitly as could be.
You're right, and I had a feeling I should have looked it up before posting.
Sigh.
>
>What you are almost surely thinking about is the situation when there is
>*NOT* an explicit open. I recall being quite surprised when at least one
>f77 compiler (VAX comes to mind :-)) treated things differently
>depending on whether there was an explicit open or not. That bit me in
>some of my code. I had to fix my code when it was pointed out to me that
>the blank='null' default was only specified for OPEN statements, leaving
>internal reads (which is where it bit me) system-dependent. That
>inconsistency did get "fixed" in f90 (though incompletely, as I recall;
>another forgotten case got fixed later).
Yes, the other forgotten case was internal READ.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Steven G. Kargl 2005-04-01, 3:59 pm |
| In article <nospam-1DAA24.15542931032005@news.supernews.com>,
Richard E Maine <nospam@see.signature> writes:
> In article <d2hv6d$tsc$1@gnus01.u.washington.edu>,
> kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
>
>
>
> That's because you omitted part of the definition. The definition does
> not say just "A field is a part of a record". It says "A field is a part
> of a record *THAT*..." (emphasis mine).
(snip)
> So it is part of the definition of "field" that it is a part of the
> record "that is read on input or written on output when format control
> encounters a data edit descriptor or a character string edit
> descriptor". It isn't just any old part of a record - it is a part of a
> record meeting that restriction. in this case, it is the whole 15
> characters - not some smaller part.
>
You're reading more into the definition than it contains.
Okay. Here's the entire definition.
10.2.2 Fields
A "field" is a part of a record that is read on input or written on
output when format control encounters a data edit descriptor or a
character string edit descriptor. The "field width" is the size in
characters of the field.
You are *implicitly* assuming that the edit descriptor bestows
onto the field its width or that the field acquires it width
from the edit descriptor. The second sentence is circular. It
states that the "field width" is detemined from the "field".
The definition of a field does indicate where or how "the size
in characters" is determined. Perhaps, the second sentence
should have been
The "field width" is the size in characters of the width of the
edit descriptor.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Dick Hendrickson 2005-04-01, 8:57 pm |
|
Steven G. Kargl wrote:
> In article <nospam-1DAA24.15542931032005@news.supernews.com>,
> Richard E Maine <nospam@see.signature> writes:
>
>
>
> (snip)
>
>
>
>
> You're reading more into the definition than it contains.
>
> Okay. Here's the entire definition.
>
>
> 10.2.2 Fields
> A "field" is a part of a record that is read on input or written on
> output when format control encounters a data edit descriptor or a
> character string edit descriptor. The "field width" is the size in
> characters of the field.
>
> You are *implicitly* assuming that the edit descriptor bestows
> onto the field its width or that the field acquires it width
> from the edit descriptor.
You need to read the individual edit descriptor sections to
see more. In F2003, for E it says
"
10.6.1.2.2 E and D editing
The Ew.d, Dw.d, and Ew.d Ee edit descriptors indicate that
the external field occupies w positions"
Clearly, in an E15.4 the width is 15 positions, and the
E15.4 does determine this. Or am I missing something
here?
Dick Hendrickson
>The second sentence is circular. It
> states that the "field width" is detemined from the "field".
> The definition of a field does indicate where or how "the size
> in characters" is determined. Perhaps, the second sentence
> should have been
>
> The "field width" is the size in characters of the width of the
> edit descriptor.
>
| |
| glen herrmannsfeldt 2005-04-01, 8:57 pm |
| Gordon Sande wrote:
> Phillip Helbig---remove CLOTHES to reply wrote:
[color=darkred]
(snip)
[color=darkred]
> I have a strong recollection, that is somewhat short on detail, of using
> OS/360 where the JCL defaulted (disk) files to opening at record 1 but
> that it was fairly easy (within the notion of easy for JCL) to position
> a file so that a task could start reading from the left over position.
> I recall doing this either to skip initial headers or to allow multiple
> sets of data to exist in a single file.
Well, for OS/360 Fortran didn't have an OPEN statement.
The JCL DISP parameter is DISP=NEW for a new file, which better not
exist already, DISP=OLD for an existing file, which must exist.
DISP=MOD opens the file at the end if it exists, or at the beginning if
it doesn't.
(I suppose that is also the end of the newly created file, but with
OS/360 it was possible to start reading a new file and find the contents
left over on the disk from the previous user.)
> For tapes this was so much the case that at one time it was considered
> good style to start with a rewind in case the tape was not at its
> beginning.
I suppose if you don't know whether the file exists or not, you could
always use DISP=MOD, and then REWIND first.
-- glen
|
|
|
|
|