Re: Formatting a real with an I edit descriptor.

On Apr 23, 8:55 am, Ron Shepard <ron-shep...@xxxxxxxxxxxxxxxxxx>
wrote:
In article <49edcf37$0$2705$cc2e3...@xxxxxxxxxxxxxx>,



LR <lr...@xxxxxxxxxxxxx> wrote:
Another thread in another group aroused my curiosity.

I was wondering what this snippet should produce according to the
standard. (I've been reading a working draft from 2004, but whatever the
latest version says would be better.)

real f
f = 10.0
write(*,'(i20,3x,f20.2)') f,f

FWIW, my compiler produces:
1092616192 10.00
but I'm not sure this is correct. Should it be:
10 10.00

Others have commented about what "correct" might mean with a nonstandard
program. Nonetheless, it appears that what you *want* to happen is
really given by something like

write(*,'(i20,3x,f20.2)') nint(f),f

Maybe it should be int(f) rather than nint(f), but you didn't specify
enough in your post to make sure. Look also at the floor(), ceiling(),
and mod() intrinsics, they all do similar but different things. Anyway,
my point is that the conversion from floating point to integer is done
with an intrinsic function reference, not by the format descriptor.

What your compiler is doing (and this is common) is to take the string
of bits that define the floating point number and print out its value
"as if" that same string of bits occurred in an integer variable. You
can do this in a standard way with the transfer() intrinsic. You can
also do it in a different nonstandard (but also common) way using the
equivalence statement. (Well I think this is nonstandard. I've done it
so many times assuming it was nonstandard, I don't know for sure.)

real f
integer if
equivalence (f,if)
f = 10.0
write(*,'(i20,3x,f20.2)') if,f

$.02 -Ron Shepard

OK - I'll ask the dumb question: what's nonstandard about Ron's code?
Equivalencing default real and default integer is explicitly allowed
in both the f95 and f2003 standards section 5.5.1, and I see no
failure to obey the 9 constraints in f95 or the 11 constraints in
f2003.

John Harper
.

Relevant Pages

  • Re: Formatting a real with an I edit descriptor.
    ... can do this in a standard way with the transferintrinsic. ... equivalence statement. ... (Well I think this is nonstandard. ... The compiler could detect the undefined case as an error and report ...
    (comp.lang.fortran)
  • Re: Formatting a real with an I edit descriptor.
    ... Others have commented about what "correct" might mean with a nonstandard ... and modintrinsics, they all do similar but different things. ... can do this in a standard way with the transferintrinsic. ... equivalence statement. ...
    (comp.lang.fortran)
  • Re: Fortran
    ... > The F66 standard says something like the value is undefined. ... If something is nonstandard, ... variables is nonstandard and indeed won't compile at all with some ... If something gives a processor-dependent result, ...
    (comp.lang.fortran)
  • Re: endian test
    ... it was never standard conforming. ... That doesn't necessarily guarantee portability across processor families, but it goes a very long way towards improving portability across like processors within a family and gaining real and needed functionality in the language. ... Equivalence will remain a necessary thing or some reasonable substitute is required. ... I have a requirement to calculate a checksum of all of the various types of a file record on a byte by byte basis and store that as a value at the end of the record. ...
    (comp.lang.fortran)
  • Re: Printing a 64-bit binary number with GFortran 4.1.2
    ... The standard only allows the Z ... edit descriptor for integers, just like the B edit descriptor. ... you could use an equivalence. ... the lack of such a bitch sounds like a compiler bug. ...
    (comp.lang.fortran)