Re: Interpretation of literal reals

N. Shamsundar wrote:
>        program tst
>        real x,y
>        character*10 lin
>        lin='123e0'
>        x=123e0
>        read(lin,'(e10.5)')y
>        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

   read(lin,'(bz,e10.5)')y

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


.

Relevant Pages

  • Re: How to Force Field Size
    ... will not *store* leading zeros, ... Public Function LeftPadToLength(strVal As String, intLength As Integer, ... I have decided to change my numbers into the 10 digits ... >>End Sub ...
    (microsoft.public.access.modulesdaovba)
  • Re: Distinguishing between characters and numbers
    ... digits is an error. ... "The input field is either an IEEE exceptional specification or ... considered as zeros. ... value separators (unless they are in a character input string). ...
    (comp.lang.fortran)
  • Re: Output n equal signs from a script
    ... Both produce a string of blanks. ... %d format specifier to get leading zeros. ... null or otherwise, should be padded with blanks, not zeros. ...
    (comp.unix.shell)
  • Re: new to java, help simple project
    ... array of digits in a number ... A constructor that uses a string representation of the integer for ... The string may contain leading zeros. ... ?public BigInt add ...
    (comp.lang.java.programmer)
  • Re: Cantors diagonal proof wrong?
    ... >> normal convention of leaving off the leading zeros (which we all ... > The positive integers are defined by the Peano axioms. ... The number of digits is a pure artifact of ... we can construct the string. ...
    (sci.math)