more comments on base conversion

[David G. Hough]

> Here's a practical-- and directly relevant --example:
> in lots of Fortran you'll see stuff like
> 
>       IF (EPS .GT. 0. .AND. 1.+EPS .EQ. 1.) THEN
> C        EPS is positive & smaller than machine epsilon
> 
> and this is about as portable a cheap test as there is; an experienced
> Fortran programmer would have no fears about relying on it.

Unless he'd had to consider the possibility of nonstandard rounding
modes!  Which is why IEEE 754 has a nextafter function that encodes
all the relevant information in one easy-to-remember package.  But
see comments below about programs already written!

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

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

> 2) While *a* program can be written to tell the difference between
>    (x-x).eq.0 and x.eq.x when, e.g., x is +inf, 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.

> The question for me is just how close to that non-insane ideal
> perfect conversions of 17-digit decimal strings on both ends can
> guarantee to get.  If x has no more than n significant bits, it seems
> that the end result of the two conversions must be x' exactly; if x
> has more than n, it seems that the result of the conversions must be
> within a half (n-bit; Cray) ulp of x', and will in fact equal x'
> exactly except for some "nearest/even" end cases.  And after that, I
> can move x' back and forth any number of times without losing anything
> more.  That's really awfully good (if true <grin>)!

I think that if you convert from 53 sig bits to 17 sig digits to 48
sig bits to 17 sig digits that will be the end of the changes.  After
that the same sig bits and sig digits patterns will repeat as long
as all conversions use some kind of deterministic round to nearest.

> >  > [tgp wondering why the all-754 shops don't just transfer numbers
> >  >  in binary or hex form]

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.