Even more conversion & Fortran blather

[Tim Peters]

>  > [tim p wondering about binary transfers on homogeneous networks]
>  [david keaton]
>       If you can do this, then there is no reason not to extend it to
>  heterogeneous environments.  Binary <--> binary conversion is much
>  faster and more precise than going through a decimal representation.
>  Something like Sun's XDR could be modified to translate floating point
>  numbers into the format of the destination machine instead of going
>  through an intermediate format.  This would solve the problem that
>  people are trying to solve with perfect decimal conversions.  That
>  would free up decimal conversions to be fast.

I think David H meant the following to be a response to the above (it
wound up in a different context):

>  [david hough]
>  But the real issue in a number of contexts is that most of the
>  Fortran programs that a computer is ever going to run are already
>  written.  So adding a new mechanism like XDR or an ASCII hex
>  standard, while helpful for new programs, doesn't solve the problem
>  most people are most interested in.

To David K:  I don't have any burning interest in the networking issues
but I imagine we're both interested in the problems that arise when
running on a single machine.  I *know* I've been burned any number of
times by pasting a CFT output into a CAL CON, or by plugging a
20-place value for a constant out of a book into a PARAMETER statement
(& in a recent mailing Cody mentioned a similar real problem with C's
#include files), or by printing a number out & reading it in later ...
and in all these cases (& more) not getting what I expected.  Even
worse, over the years CRI has fiddled with the accuracy of its
conversion routines, so the values of decimal constants in CAL & CFT
etc have, from time to time, magically "changed" even when I never
touched the source!  I believe that perfect conversions supply a
complete remedy to all these headaches at one stroke, and that would
have real value for me (depending on the cost <grin>).  How about you?
I cheerfully confess the idea continues to grow on me.

>  > [tgp]
>  > ...
>  >       IF (EPS .GT. 0. .AND. 1.+EPS .EQ. 1.) THEN
>  > ...
>  > and this is about as portable a cheap test as there is; an experienced
>  > Fortran programmer would have no fears about relying on it.
>  [dgh]
>  Unless he'd had to consider the possibility of nonstandard rounding
>  modes!

Yes, the "about" in "about as portable" was intentional.  *Nothing* is
completely portable, alas.

>  Which is why IEEE 754 has a nextafter function that encodes all the
>  relevant information in one easy-to-remember package.

"nextafter" is indeed a nice function!  I only wish 754 had required
it (i.e., a conforming 754 implementation needn't supply it).

>  > If the compiler were really free to do its "mathematically
>  > equivalent" tricks here ...
>  The mathematically equivalent clause basicly eliminates most of the
>  possible arguments about standard conformance since nobody would
>  agree what it meant:

The inherent ambiguity of those clauses has-- surprisingly! --fueled
very few long-lived controversies in *practice*, and they've been a
real benefit in allowing compilers to adapt to new architectures.  The
*real* problem with them is just that they're clearly not strong
enough to force anyone to shut up <grin> -- but that's good too,
because it keeps "different" ideas alive.

>  > (seems like they couldn't get enough
>  > current members to understand there *is* a problem).
>  The actual commercial standard is whether a compiler produces the expected
>  results with acceptable efficiency with most existing Fortran programs.

"The problem" isn't that Sun (+ 100 other vendors) uses a comparison
instruction, "the problem" is that the True Fortran Std (the ANSI
document) has gotten out of synch with the "commercial std" in this
area.  All the benefits of having a std are diminished when the std
fails to jibe with reality.

>  >    ... the very fact that it uses +inf (or a NaN ... a
>  >    non-normal) renders it non-conforming a priori.
>  I'd be surprised if usage of inf or NaN was provably nonstandard in
>  Fortran-77.  Generating the inf or NaN by an exceptional operation
>  might be, but I think there would be arguments about that.

There are arguments about everything <grin>, but fortunately for us
this one is easy.  If, as it appears, you're inclined to fight the
notion that use of non-normals in 77 is non-conforming, I suspect it's
because you're using a notion of "conformance" obtained from another
language.

In sketch form (study 1.4 of the std to flesh it out), "a program" is
"conforming" under 77 iff it limits itself to features defined by the
std.  Unlike as in, e.g., Pascal, there is *no* implication that a
non-conforming program is "bad" or "wrong", there's merely the warning
that it's unlikely to work as the user intends on *all* Fortran
platforms.  Usage of NaNs, infinities, and signed zeroes are thus
obviously non-conforming:  in the formal sense because the std clearly
doesn't define their behavior (and, by *definition*, a "conforming"
program limits itself to things the std defines); in the intuitive
sense because they're clearly *not* portable to *all* Fortran
platforms.  On the other hand, "a processor" (compiler) is
"conforming" iff it does what the std says it should do given a
conforming program -- & note that a consequence is that a processor is
*not* rendered non-conforming for supporting extensions (to the
contrary, Fortran implicitly encourages the processor to provide
extensions, and leaves the choice of whether to use them up to the
programmer -- people who wonder why Fortran never dies should think
about this deeply <0.7 grin>).

So, e.g., Sun (anyone) can support all the 754 features they like in
their compiler just so long as doing so doesn't break programs that
don't use those features.  But a program that *uses* any of those
extensions is by definition non-conforming, which in turn just means
the program is likely not to work on at least one other platform.

fortran-never-had-the-arrogance-to-believe-it-did-everything-
   right-the-first-time-around-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
timaksr.com,  ksr!timaharvard.harvard.edu