Interpretation of literal reals
Author Message
Interpretation of literal reals

Group:

The short program below frames an issue with porting a large program.

According to the rules of fortran (77, 90, 95, 2000) a real constant
with no decimal point, with or without an exponent field, is treated
differently in program source than during formatted input.

List directed input works as a user would expect. As the ISO-F95
standard says in Sec. 10.9.1 (emphasis added),

Quote:
> When the next effective item is of type real, the input form is
> that of a numeric input field. A numeric input field is a field
> suitable for F editing (10.6.1.2.1) that is assumed to have _no
> fractional digits_ unless a decimal symbol appears within the
> field.

whereas, for F editing with no decimal point in the input field, Sec.
10.6.1.2.1 says:

Quote:
> The input field consists of an optional sign, followed by a string
> of one or more digits optionally containing a decimal symbol,
> including any blanks interpreted as zeros. The d has no effect
> on input if the input field contains a decimal symbol. If the
> decimal symbol is omitted, the rightmost d digits of the string,
> with leading zeros assumed if necessary, are interpreted as
> _the_fractional_ part of the value represented.

N. Shamsundar
University of Houston

_____________________________________________________
program tst
implicit none
real :: x,y
character(len=10) :: lin
!
x=123
lin='123'
!
write(*,'(1x,1p,2e15.5)')x,y
write(*,'(1x,1p,2e15.5)')x,y
write(*,'(1x,1p,2e15.5)')x,y
!
stop
end program tst

RESULTS:

1.23000E+02    1.23000E-03
1.23000E+02    1.23000E-03
1.23000E+02    1.23000E+02

Sun, 20 Jul 2008 22:08:34 GMT
Interpretation of literal reals

Quote:

> According to the rules of Fortran (77, 90, 95, 2000) a real constant
> with no decimal point, with or without an exponent field, is treated
> differently in program source than during formatted input.

I can't make any sense out of that sentence. In particular, there is no
such thing as "a real constant with no decimal point". There certainly
is no such thing "in program source". A string of digits with no decimal
point in program source would be an integer rather than a real constant.

x=123

the 123 is *NOT*, let me repeat that *NOT* a real constant. If you think
of such things as real constants, you will go down a road to many
errors. It is an integer constant. The assignment statement causes the
integer value to be converted to a real before it is assigned to x, but
that is not at all the same thing as saying that the 123 is a real
constant in the first place. Yes, it makes a difference. For a trivial
example,

x = 2/3

will give you a value of zero for x. That is because the 2 and 3 are
integers, so the division is the integer division operation. The
conversion to real does not happen until later, when the resulting value
is assigned to x.

As for I/O, I think old versions of the standard might have misused the
term "constant" to refer to formatted I/O fields, but formatted I/O
fields really do not contain constants; they are just strings of
characters that get converted during I/O. The syntax has similarities to
that of a constant, but it is not the same thing and should not be
confused.

Although I can't figure out what the above says, I can make more sense
of the example code.

Quote:
> List directed input works as a user would expect. As the ISO-F95
> standard says in Sec. 10.9.1 (emphasis added),

[elided]
Ok.

Do note, however, that in f77 this does *NOT* apply to internal I/O, as
used in your example. List-directed formatting is not allowed for
internal files in standard f77, and there used to be f77 compilers that
didn't do it. I believe that relatively recent f77 compilers tend to
support it as an extension, but older ones didn't.  (Heck, most recent
f77 compilers are f90/f95 compilers).

This probably doesn't directly relate to your question, but as long as I
am in pendant mode, I'll note it.

Quote:
> whereas, for F editing with no decimal point in the input field, Sec.
> 10.6.1.2.1 says:

[elided]

Quote:

Well, my first comment is that one should generally put the decimal
point in. I realize, however, that there are cases where that isn't
going to happen. For example, if a user interactively types in a value
without a decimal point, the program ought to be able to deal with it
rather than give strange results.

As far as I can tell, the complaint is that both the "10" and the ".5"
part of e10.5 and f10.5 actually mean something. I'm puzzled about why
List-directed input is more like a ".0". If that is what the people in
question wanted, then they should have used a ".0". I just don't
understand why they would put a ".5" and expect it to be ignored and act
like a ".0".

I agree that the ".5" does "strange" things on input. In my opinion, it
is a throwback to some of the worst aspects of the punch-card days,
where the decimal point might have beeen omitted to save a precious
column. My rule is to *NEVER* use anything other than ".0" for real
input formats if there is any possibility that the input data might have
an omitted decimal point, even by accident. That includes any case where
the input data might be manually prepared. In cases where the input data
is always generated by a formatted write, I might relent and allow the
same format to be used for reading, even though it has something other
than ".0".

But I am very mystified as to why this could be a porting issue, as I
have trouble imagining any compiler that would not have correctly
treated the ".5", where "correctly" here means the way that you seem to
not expect. I *DO* know of a vaguely related porting issue, which can be
a problem even when using the ".0" as I recommend. I am more than a
little suspicious that this other issue is your real problem and that
you just haven't identified it. It is an issue I ran into long ago.

The issue is an artifact of f66 and earlier, but its effects linger on
into f77. It involves the treatment of blanks in formatted input.

In f66, blanks in numeric fields acted like zeros. Thus, if you had a
field width of 10, with contents of "123       ", this was effectively
the same thing as "1230000000", which I agree I sure find strange. This
makes no difference when you have an explicit decimal point, because,
for example, "123.000000" has the same value as without the trailing
zeros.

F77 mostly fixed this oddity (in my opinion) of blank treatment. By
default, blanks are treated as blanks. Thus all works "sensibly" (as
long as you use ".0" in your edit descriptors; if you use something like
".5", you are still going to get nonsense just as it explicitly asks for
- don't do that). The new f77 OPEN statement allowed you to specify the
old f66 behavior if you neede compatibility with it.

However, the caveat that I ran into about 20 years ago, and I guess
perhaps the one that is hitting you now... the f77 standard specified
this "new" behavior only via the OPEN statement. For files accessed
without using an OPEN statement, the standard was silent about whether
to apply the new or old behavior. I didn't at first notice this because
the standard didn't actually say that it was processor-dependent. The
standard just specified what happened in an OPEN statement and was
otherwise silent.

Internal I/O does not involve an OPEN statement.

Some compilers did the "sensible" thing and made internal I/O act just
like an opened file in this regard. Other compilers did the other
sensible thing and made internal I/O act just like f66 I/O on this.  :-(

The f90 standard "laid down the law" (figuratively) and specified that
internal I/O has to treat blanks as blanks (instead of as zeros) by
default in internal I/O. So all f90 compilers should be the same in this
regard (though some might have switches for compatibility with old
compiler-dependent codes). But f77 compilers are not all the same.

Therefore, if your code might ever need to run on a pre-f90 compiler,
and you do internal reads of real data that might omit the decimal
point, you have to make your requirements for blank treatment explicit
explicit by using the bn or bz edit descriptors. BN stands for
blanks-null (that is, a blank is sort of like nothing being there). BZ
stands for blanks-zero (a blank is like a zero being there).

So you probably want a format something like "(bn,f10.0)". That will
interpret "123       " as just "123", giving you the real value 123.0.
You "shouldn't" need to do this for f90 becasue it is what the standard
specifies. If you wanted the old f66-ish behavior (ignoring the fact
that f66 didn't have internal I/O), you'd use "(bz,f10.0)", though I
regard that last one as an abomination, and it doesn't sound like what
you want either.

So yes, f77 had several portability issues in the area of internal I/O.
List-directed internal I/O was nonstandard (and not universally
supported). And the default blank treatment for internal IO was
compiler-dependent.

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

Mon, 21 Jul 2008 01:07:47 GMT
Interpretation of literal reals

Quote:

>>According to the rules of Fortran (77, 90, 95, 2000) a real constant
>>with no decimal point, with or without an exponent field, is treated
>>differently in program source than during formatted input.

> I can't make any sense out of that sentence. In particular, there is no
> such thing as "a real constant with no decimal point". There certainly
> is no such thing "in program source". A string of digits with no decimal
> point in program source would be an integer rather than a real constant.

>    x=123

> the 123 is *NOT*, let me repeat that *NOT* a real constant. <-- CUT-->

You are correct. I oversimplified the encapsulated program. Here is the
version I had tried prior to posting and my comments were based more on
this version:

program tst
real x,y
character*10 lin
lin='123e0'
x=123e0
write(*,'(1x,1p,2e15.5)')x,y
stop
end

With the 'e0' in there, there are no integers as in the previous post
and the integer to real conversion, which you wrote about, does not come
into play. However, the printed result is, still,

1.23000E+02    1.23000E-03

N. Shamsundar

Mon, 21 Jul 2008 05:04:59 GMT
Interpretation of literal reals

Quote:

>        lin='123e0'
...

Oh. So you are combining implied decimal points in formatted I/O with
exponent notation. I don't think I've ever seen that. My only comments
would be

1. Yukk!  (I have to add that one :-)).

2. If you really must do that, read through the words in the standard
word-at-a-time to figure out what to expect. I don't think I'd try to
intuit it. I guess you have done that reading. I won't bother to repeat
the excercise because if you have done it, and if I understood you, your
compiler agrees with your reading of the standard. I just threw it at 3
compilers of independent vintage (nag f90, g77, g95) on this machine and
all got the same result that yours did. That's enough to give me
reasonable verification that you probably read the standard correctly,
even though I didn't pick through the details by hand myself. If the
result disagrees with your intuition, then I'd just say that this isn't
an intuitive case and you shouldn't try to intuit it (and I'd wonder
what your intuition thinks that the ".5" in the e10.5 intuitively means
here).

3. As before, formatted real values do not have the same syntax as
real literal constants. They have similarities; simple cases will be the
same. This is not a simple case. Another difference of note is that
formatted real values do not have kinds - not even conceptually and also
not in the syntax. Don't try something like 123.0_4, much less
123.0_single in a real input field.

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

Mon, 21 Jul 2008 05:31:45 GMT
Interpretation of literal reals

Quote:

>        program tst
>        real x,y
>        character*10 lin
>        lin='123e0'
>        x=123e0
>        write(*,'(1x,1p,2e15.5)')x,y
>        stop
>        end

> With the 'e0' in there, there are no integers as in the previous post
> and the integer to real conversion, which you wrote about, does not
> come into play. However, the printed result is, still,

>       1.23000E+02    1.23000E-03

Yes, that's what I would expect it to do.  Note:
that's not what I would want it to do, but the
standard requires a lot of things I don't want.

I double checked in the F77 document (which
is what I have closest at hand).  For Fw.d the
input consists of an optional sign, followed by a
string of digits optionally containing a decimal point,
followed by an optional exponent part.  If the decimal
point is omitted the string of digits is right-justified
in a w-wide field (implicitly padded with zeros on the
left) and the implied decimal point is put to the left of
the rightmost d digits.  For Ew.d, input is the same as
for an Fw.d specifier.

As long as we're talking peculiarities of floating-point
input, there's what (I think) is an unintended requirement
when blanks are being treated as zeros.  Suppose that
the string for your program was:

lin = '1.23e2'

And suppose your input statement was

The actual ten characters of the string are

1.23e2????

Where I use ? to make the blanks visible.  Now,
if blanks are to be treated as zeros, this means
that the above is the same as

1.23e20000

Some compilers do treat it that way.  But, is it really
intended?  Do all compilers do it?  If omitting a decimal
point is a likely user error, not filling the whole w-width
field for each input item must be even more common
(and the consequences more mysterious).  Of course,
using BZ (or the corresponding open statement specification)
is pretty {*filter*} anyway - at least for normal user input.

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

Mon, 21 Jul 2008 06:25:28 GMT
Interpretation of literal reals

Quote:
> Some compilers do treat it that way.  But, is it really
>  intended?

Yes.

Quote:
> Do all compilers do it?

All standard-conforming processors do.

Remember that when FORTRAN was designed, punched cards were the
primary medium for data input.  The rules for the implied decimal point
come from that era.  Cards typically had a fixed number of columns,
which put a premium on the number of characters required for input.
Card punches had "zones,"  usually indicated by a drum card, which made
aligning characters easy.

Bob Corbett

Mon, 21 Jul 2008 08:28:20 GMT
Interpretation of literal reals
...

Quote:
> Remember that when FORTRAN was designed, punched cards were the
> primary medium for data input.  The rules for the implied decimal
> point come from that era.  Cards typically had a fixed number of
> columns, which put a premium on the number of characters required for
> input. Card punches had "zones,"  usually indicated by a drum card,
> which made aligning characters easy.

Well, a blank takes as much space on a card as a zero
does.  So, while your statement makes a little sense
in the description of why the decimal point is optional,
it doesn't give any reason for the rule of where to put
it if there is an exponent part.  Using keypunches does
provide some motivation for allowing spaces to be
treated as nulls within numeric input, but it doesn't provide
much motivation for allowing blanks to be treated as zeros
in an exponent part (in the significand part, yes, but not
in the exponent).  I used keypunches almost exclusively
for 15+ years, and I don't see that any of their properties
explain the issues in question here.

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

Mon, 21 Jul 2008 09:48:33 GMT
Interpretation of literal reals

(previous snip regarding F format for input)

Quote:
> Remember that when FORTRAN was designed, punched cards were the
> primary medium for data input.  The rules for the implied decimal point
> come from that era.  Cards typically had a fixed number of columns,
> which put a premium on the number of characters required for input.
> Card punches had "zones,"  usually indicated by a drum card, which made
> aligning characters easy.

and punching card fields without decimal points was likely much older.

Before computers, punched cards were used with a variety of unit record
machines.  Machine that would apply simple operations to a card or cards.

The P format descriptor also dates back to the 704, among other uses
output formatting without changing the value stored in the variable.

It is definitely much easier to get the field positions right on cards
then typing them in on a terminal.

-- glen

Mon, 21 Jul 2008 16:13:25 GMT
Interpretation of literal reals

(snip)

Quote:
> Well, a blank takes as much space on a card as a zero
> does.  So, while your statement makes a little sense
> in the description of why the decimal point is optional,
> it doesn't give any reason for the rule of where to put
> it if there is an exponent part.  Using keypunches does
> provide some motivation for allowing spaces to be
> treated as nulls within numeric input, but it doesn't provide
> much motivation for allowing blanks to be treated as zeros
> in an exponent part (in the significand part, yes, but not
> in the exponent).  I used keypunches almost exclusively
> for 15+ years, and I don't see that any of their properties
> explain the issues in question here.

"To permit economy in keypunching certain relaxations in input
data format are permitted.

1) Numbers for E conversion need not have 4 columns devoted to
the exponent field.  The start of the exponent must be marked by
an E, or if that is omitted, by a + or - (not a blank).  The E2, E02,
+2, +02, E 02, and E+02 are all permissible exponent fields.

2) Numbers for E or F conversion need not have the decimal point
punched.  If it is not punched the FORMAT Specification sets its
effective position; for example, -09321+2 with E12.4 will be treated
as if the decimal point had been punched 4 places before the start
of the exponent field, that is between the 0 and the 9.  If the
decimal point is punched, its position overrides the value of d
in the FORMAT specification."

From the 704 Fortran manual.

-- glen

Mon, 21 Jul 2008 16:25:52 GMT
Interpretation of literal reals

Quote:

>>According to the rules of Fortran (77, 90, 95, 2000) a real constant
>>with no decimal point, with or without an exponent field, is treated
>>differently in program source than during formatted input.

> I can't make any sense out of that sentence. In particular, there is no
> such thing as "a real constant with no decimal point". There certainly
> is no such thing "in program source". A string of digits with no decimal
> point in program source would be an integer rather than a real constant.

>    x=123

> the 123 is *NOT*, let me repeat that *NOT* a real constant. If you think
> of such things as real constants, you will go down a road to many
> errors. It is an integer constant. The assignment statement causes the
> integer value to be converted to a real before it is assigned to x, but
> that is not at all the same thing as saying that the 123 is a real
> constant in the first place. Yes, it makes a difference. For a trivial
> example,

>   x = 2/3

> will give you a value of zero for x. That is because the 2 and 3 are
> integers, so the division is the integer division operation. The
> conversion to real does not happen until later, when the resulting value
> is assigned to x.

> As for I/O, I think old versions of the standard might have misused the
> term "constant" to refer to formatted I/O fields, but formatted I/O
> fields really do not contain constants; they are just strings of
> characters that get converted during I/O. The syntax has similarities to
> that of a constant, but it is not the same thing and should not be
> confused.

> Although I can't figure out what the above says, I can make more sense
> of the example code.

>>List directed input works as a user would expect. As the ISO-F95
>>standard says in Sec. 10.9.1 (emphasis added),

>   [elided]
> Ok.

> Do note, however, that in f77 this does *NOT* apply to internal I/O, as
> used in your example. List-directed formatting is not allowed for
> internal files in standard f77, and there used to be f77 compilers that
> didn't do it. I believe that relatively recent f77 compilers tend to
> support it as an extension, but older ones didn't.  (Heck, most recent
> f77 compilers are f90/f95 compilers).

> This probably doesn't directly relate to your question, but as long as I
> am in pendant mode, I'll note it.

>>whereas, for F editing with no decimal point in the input field, Sec.
>>10.6.1.2.1 says:

>   [elided]

> Well, my first comment is that one should generally put the decimal
> point in. I realize, however, that there are cases where that isn't
> going to happen. For example, if a user interactively types in a value
> without a decimal point, the program ought to be able to deal with it
> rather than give strange results.

> As far as I can tell, the complaint is that both the "10" and the ".5"
> part of e10.5 and f10.5 actually mean something. I'm puzzled about why
> List-directed input is more like a ".0". If that is what the people in
> question wanted, then they should have used a ".0". I just don't
> understand why they would put a ".5" and expect it to be ignored and act
> like a ".0".

> I agree that the ".5" does "strange" things on input. In my opinion, it
> is a throwback to some of the worst aspects of the punch-card days,
> where the decimal point might have beeen omitted to save a precious
> column. My rule is to *NEVER* use anything other than ".0" for real
> input formats if there is any possibility that the input data might have
> an omitted decimal point, even by accident. That includes any case where
> the input data might be manually prepared. In cases where the input data
> is always generated by a formatted write, I might relent and allow the
> same format to be used for reading, even though it has something other
> than ".0".

> But I am very mystified as to why this could be a porting issue, as I
> have trouble imagining any compiler that would not have correctly
> treated the ".5", where "correctly" here means the way that you seem to
> not expect. I *DO* know of a vaguely related porting issue, which can be
> a problem even when using the ".0" as I recommend. I am more than a
> little suspicious that this other issue is your real problem and that
> you just haven't identified it. It is an issue I ran into long ago.

> The issue is an artifact of f66 and earlier, but its effects linger on
> into f77. It involves the treatment of blanks in formatted input.

> In f66, blanks in numeric fields acted like zeros. Thus, if you had a
> field width of 10, with contents of "123       ", this was effectively
> the same thing as "1230000000", which I agree I sure find strange. This
> makes no difference when you have an explicit decimal point, because,
> for example, "123.000000" has the same value as without the trailing
> zeros.

> F77 mostly fixed this oddity (in my opinion) of blank treatment. By
> default, blanks are treated as blanks. Thus all works "sensibly" (as
> long as you use ".0" in your edit descriptors; if you use something like
> ".5", you are still going to get nonsense just as it explicitly asks for
> - don't do that). The new f77 OPEN statement allowed you to specify the
> old f66 behavior if you neede compatibility with it.

> However, the caveat that I ran into about 20 years ago, and I guess
> perhaps the one that is hitting you now... the f77 standard specified
> this "new" behavior only via the OPEN statement. For files accessed
> without using an OPEN statement, the standard was silent about whether
> to apply the new or old behavior. I didn't at first notice this because
> the standard didn't actually say that it was processor-dependent. The
> standard just specified what happened in an OPEN statement and was
> otherwise silent.

> Internal I/O does not involve an OPEN statement.

> Some compilers did the "sensible" thing and made internal I/O act just
> like an opened file in this regard. Other compilers did the other
> sensible thing and made internal I/O act just like f66 I/O on this.  :-(

> The f90 standard "laid down the law" (figuratively) and specified that
> internal I/O has to treat blanks as blanks (instead of as zeros) by
> default in internal I/O. So all f90 compilers should be the same in this
> regard (though some might have switches for compatibility with old
> compiler-dependent codes). But f77 compilers are not all the same.

> Therefore, if your code might ever need to run on a pre-f90 compiler,
> and you do internal reads of real data that might omit the decimal
> point, you have to make your requirements for blank treatment explicit
> instead of just using the compiler default. You make your requirements
> explicit by using the bn or bz edit descriptors. BN stands for
> blanks-null (that is, a blank is sort of like nothing being there). BZ
> stands for blanks-zero (a blank is like a zero being there).

> So you probably want a format something like "(bn,f10.0)". That will
> interpret "123       " as just "123", giving you the real value 123.0.
> You "shouldn't" need to do this for f90 becasue it is what the standard
> specifies. If you wanted the old f66-ish behavior (ignoring the fact
> that f66 didn't have internal I/O), you'd use "(bz,f10.0)", though I
> regard that last one as an abomination, and it doesn't sound like what
> you want either.

> So yes, f77 had several portability issues in the area of internal I/O.
> List-directed internal I/O was nonstandard (and not universally
> supported). And the default blank treatment for internal IO was
> compiler-dependent.

valuable. Having reread them, I feel that it may be useful to report the
actual problem rather than my oversimplified synthetic snippet.

The software that I was working on was an optimization code, Algencan
from www.ime.usp.br/~egbirgin/tango/ . The code is 11,500 lines of
Fortran 77, last revised in January 2005. (Incidentally, many ACM-TOMS
Algorithm codes still use F77 in preference to later versions of Fortran).

The in-source documentation for configurable algorithm parameters says:

- Show quoted text -

Quote:
> The specification file can have any number of lines, with at most
> 80 characters per line. Blank lines are admitted and lines starting
> with '*' are considered comment lines and will be ignored. Each
> line must have just a "keyword" or a keyword followed by an integer
> or a real value when required. As the interpreter is not case-
> sensitive, you can write the keywords in lower case, upper case or
> any combination of them. You can also insert blanks in any place
> before or after the keywords. Moreover, just the first 10 characters
> of the keyword are relevant and the rest will be ignored. Available
> keywords are:

> HESSIANS-PROVIDED
> LAGRHESS-PRODUCT-PROVIDED
> INCREMENTAL-QUOTIENTS
> BFGS-QN-APPROXIMATION
> UNPRECONDITIONED-CG
> BFGS-QN-PRECONDITIONER
> CHECK-DERIVATIVES
> FEASIBILITY-TOLERANCE

...

Mon, 21 Jul 2008 21:08:24 GMT
Interpretation of literal reals

Quote:

> Not having been bitten before by the Fw.d issue, and focusing on the
> behavior of the algorithm, I had prepared a data file with "1d-4" for
> the two real values (tolerances)...
> I was surprised and, having spent so much time chasing the culprit,
> wanted to share the finding.

Ok. Thanks. I found it informative also. I don't think I ever before had
looked at the combination of using an exponent while omitting the
decimal point. (I had to check the standard to verify that this was even
allowed).

I do think that one lesson I'd suggest taking from this is to always
include the decimal point in real values. That's been a personal
guideline of mine for longer than I can remember... certainly over 2
decades, and probably more like 3. (Long pre-f90. This is not an f90
issue.)

Of course, there is one of the "universal" rules of robust I/O. This one
is far broader than Fortran. I think I first saw it in discusssions
about email header generation and parsing, but I have since seen it many
other places. Be strict about what you send/generate.  But be liberal

I.e. in this case, being strict about what you send/generate means to
always use the decimal point when typing the input. Being liberal about
what you accept means, if you are writing the code, write it to handle
the omission of the decimal point "gracefully".  Using (bn,f10.0) would
probably achieve that.

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

Tue, 22 Jul 2008 00:25:04 GMT
Interpretation of literal reals
...

Quote:
> 1) Numbers for E conversion need not have 4 columns devoted to
> the exponent field.  The start of the exponent must be marked by
> an E, or if that is omitted, by a + or - (not a blank).  The E2, E02,
> +2, +02, E 02, and E+02 are all permissible exponent fields.

But, do they mean the same thing?  That is, if the input field
is 10 characters long consisting of (where ? represents blank):

???1.23+2?

Should that mean the same as:

???1.23+02

I think it should even if blanks are interpreted as zeros.
The BZ semantics only really make sense as part of the
significand, not the exponent.

Quote:
> 2) Numbers for E or F conversion need not have the decimal point
> punched.  If it is not punched the FORMAT Specification sets its
> effective position; for example, -09321+2 with E12.4 will be treated
> as if the decimal point had been punched 4 places before the start
> of the exponent field, that is between the 0 and the 9.  If the
> decimal point is punched, its position overrides the value of d
> in the FORMAT specification."

Again, the language design would have been better if the
implied decimal point, when an exponent part was present
and no decimal point was, were assumed to be immediately
to the left of the exponent part.  It doesn't lose any flexibility
or require more characters, and makes the data more human

Water under the bridge, of course.  But if the attempt of
others in this thread is to explain why these features were
designed as they are, they've failed.

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

Tue, 22 Jul 2008 02:12:51 GMT
Interpretation of literal reals

Quote:

>> 1) Numbers for E conversion need not have 4 columns devoted to
>> the exponent field.  The start of the exponent must be marked by
>> an E, or if that is omitted, by a + or - (not a blank).  The E2, E02,
>> +2, +02, E 02, and E+02 are all permissible exponent fields.
> But, do they mean the same thing?  That is, if the input field
> is 10 characters long consisting of (where ? represents blank):
> ???1.23+2?
> Should that mean the same as:
> ???1.23+02

The 704 manual doesn't seem to say either way, as far as
I can tell.  No space before the exponent part, though
a blank is allowed after an E.  I know the output form with
an exponent and no E has been discussed, but I hadn't thought

Quote:
> I think it should even if blanks are interpreted as zeros.
> The BZ semantics only really make sense as part of the
> significand, not the exponent.

I agree, and it might be that is true.  I don't know that
I ever saw a case where it didn't, though a strict reading
of the text might indicate differently.

Quote:
>> 2) Numbers for E or F conversion need not have the decimal point
>> punched.  If it is not punched the FORMAT Specification sets its
>> effective position; for example, -09321+2 with E12.4 will be treated
>> as if the decimal point had been punched 4 places before the start
>> of the exponent field, that is between the 0 and the 9.  If the
>> decimal point is punched, its position overrides the value of d
>> in the FORMAT specification."
> Again, the language design would have been better if the
> implied decimal point, when an exponent part was present
> and no decimal point was, were assumed to be immediately
> to the left of the exponent part.  It doesn't lose any flexibility
> or require more characters, and makes the data more human

Except for trying to read with the same format as used
in writing, in which case there will always be a decimal
point, why use a non-zero d in a read format?

Quote:
> Water under the bridge, of course.  But if the attempt of
> others in this thread is to explain why these features were
> designed as they are, they've failed.

I quote the horses mouth, as the saying goes.  No claim to
explain why, other than what the words say.

Also, the 704 indicates that the d field is taken MOD 10.
Presumably that went away somewhere along the line.

-- glen

Tue, 22 Jul 2008 02:50:44 GMT
Interpretation of literal reals

Quote:

....
>> Water under the bridge, of course.  But if the attempt of
>> others in this thread is to explain why these features were
>> designed as they are, they've failed.

> I quote the horses mouth, as the saying goes.  No claim to
> explain why, other than what the words say.

Unfortunately, horses usually fail to explain themselves.
In fact, they refuse to do so even when asked.  I think
most language features should be the other way around:
a good explanation should be a required component for
most features - especially those that contradict naive
expectations.

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

Tue, 22 Jul 2008 04:04:46 GMT
Interpretation of literal reals

Quote:

> a good explanation should be a required component for
> most features - especially those that contradict naive
> expectations.

Yep. Then all we would need is for the standard to define
what constituted "good" explanation and what constituted
"naive expectations."  :-)

Sorry, but try as many people have, you cannot enforce
things like "good explanations" with a bureaucratic
requirement (and a bureaucratic requirement is what
"required component" would turn into). In my experience,
most attempts to enforce such things by rules are
counterproductive, almost no matter who makes the rules.
I could probably fill a book with examples. Someone
probably has.

You can suggest that explanations are a good idea and should
be included. I heartily agree. But you can't make a rule
requiring it.

For a start, "you" or "I", or even the committee, literally can't make
such a rule - not an enforceable one. ISO makes the rules. Have fun
convincing them to add this one.  :-) And if you managed to convince the
Fortran committee to adopt such a rule, even by unanimous vote, it
really wouldn't mean anything more that a suggestion anyway. That's
because any "rule" adopted by the committee would have no enforcement
mechanism other than the committee itself. The rule could be overridden
in the next meeting. Or the committee could just vote that a given
proposal had met the rule, no matter how much you or I might look and
say "no it didn't." In the end, the vote is still all that matters. I
could complain all day that the committee didn't follow its own rules,
but that wouldn't invalidate the votes.

(We've had a member who seemed to think that his own view of whether
something was done properly somehow should count as a veto for a
many-to-1 vote supporting the chair's ruling. Need I say that this
didn't work well?)

ISO can actually enforce ISO rules and withdraw standards because of
failure to follow them. (Anyway, I think they can do that - it is
outside of my experience).

I'll tell you what. First you can work on getting a rule passed that
political election results don't count unless there is a majority
agreement not only on which candidate wins, but also on the reason that
candidate is the best one. Then we will talk about adopting a similar
rule for language standards. If you think that is a facetious
comparison, we are going to disagree, because my personal experience on
the committee suggests that it is a *VERY* similar situation. Note that
news commentator statements don't "count"; I want to see actual
agreement formally expressed by the voters, just like we would need for
the language standard.

Again, as a suggestion, I agree. One can even "push" a bit and say that
a particular explanation for a proposal isn't good enough. Actually that
happens quite regularly as a natural part of the debate on what features
to do. I just think there is a huge difference between a suggestion and
a rule/requirement.

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

Tue, 22 Jul 2008 06:04:09 GMT

 Page 1 of 2 [ 17 post ] Go to page: [1] [2]

Relevant Pages