more comments on base conversion

[David G. Hough]

> See section 6.3.3 for another real problem:  if "relop" is in {.EQ.,
> .NE., .LT., .LE., .GT., .GE.}, Fortran *defines*
> 
>    x relop y
> 
> to be the value of the expression
> 
>   ((x) - (y)) relop 0.

I think that this kind of problem is avoided in Fortran implementations
since there is a catch-all clause allowing "mathematically equivalent"
transformations, without defining what these are.  Sun's compilers
have always done comparisons with comparison operators, and nobody
complains about that.

> Moral of the story:  754 probably isn't going to have an *easy* time
> fitting into any language painlessly.

If most of the problems relate to ambiguities in the language definitions,
they can be fixed by clarifying the definitions.
> 
> I believe that if you (correctly) print out a Cray number to 17
> digits, and read it (correctly) into a 754 double, you'll get exactly
> what you started with (barring hassles with exponent range, NaNs,
> signed zeroes, and infinities).

Yes.

> What may not work perfectly is *starting* from the machine with the
> greater precision.

Almost all the time, you'd get a different value in the less precise machine.

> Anybody think all this
> stuff out already?

Matula had some papers in CACM around 1968-70; also discussed in Sterbenz.

> In any case, what I don't understand about the networking arguments
> I've heard here is that they seem to address a non-problem -- i.e., on
> a homogeneous network (or a network of all-754 machines), I'd be much
> better off transferring data in raw binary format, or as hex strings if
> I absolutely need a text file.

You can't do this in a standard portable way, unfortunately.  Maybe a
standard is needed.

> it never occurred to me that anyone would
> configure a compiler to run with optimization off by default (no
> kidding!).

Doing things this way puts everybody into the optimizing compiler
debugging business whether they've thought about it or not.
> 
> A flawed std that isn't updated will die, as various vendors "correct"
> its failings in various ways, all the while legitimately claiming full
> conformance -- users eventually catch on to the fact that conformance
> is no guarantee of portability, and the std is considered a joke (I'll
> wager NCEG wouldn't exist today if X3J3's monumental paralysis hadn't
> left Fortran 8x in near-eternal limbo).

As long as Fortran-8x is a compatible upward superset of Fortran-77, there
will be good reasons to use C instead  (the complexity of Fortran I/O
is my particular pet peeve).

> Excellent point, and one I didn't really grasp before.  Thanks!  On
> the other hand <grin>, for purposes of portability you might just as
> well, e.g., demand truncation of the true result -- and it seems quite
> likely that nearly all systems could achieve that more cheaply

Getting correct rounding in the usual way costs little more than getting
correct chopping - in either case you have to know enough about the true
answer to permit correct conversion - chopping permits computing one less bit,
at the cost of aggravating drift problems.