Assorted delayed replies

[Tim Peters]

>  [david hough]
>  ...
>  Fortran has its own dumb ideas, of course; fcvs enforces the Fortran-77
>  requirement that you can't print -0 in formatted output.

You might also enjoy sections 4.1.3 ("... zero is considered neither
positive nor negative ... the value of a signed zero is the same as
the value of an unsigned zero ...") and section notes B4 (pg B-3 lines
6-7 "A processor must not consider a negative zero to be different
from a positive zero.") in the 77 std.  Hard to know whether 754's
signed zeroes are compatible with this, but as an old Fortran
implementor I think you could get away with saying "sure they are!";
it's easy enough to quibble about what "value is the same" and "to be
different" really mean until everyone gets tired and goes home <grin>.

But you're right, 754 is in trouble with the "no -0 output" clause.  I
don't think X3J3 will ever change that rule, either.  At least not
until all scientific machines do the same thing with signed zeroes
(it's a bit unfair to call "dumb" now what has been a genuine benefit
to Fortran users up until now -- and what will continue to be a
genuine benefit so long as the sign of a zero is non-portable trash).

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.

and because of the parentheses in the defining expression a conforming
compiler is severely limited in creatively interpreting (parentheses
in Fortran are a brick wall of sorts) this definition.  The upshot is
that when I compile

   x = 1./0.  ! create an infinity -- we won't mention that
	      ! the division by zero already renders this program
	      ! non-conforming <sigh>
   if (x.eq.x) print *, 'infinity equals itself'

I have to *evaluate* it as

   if (((x)-(x)).eq.0.) ...

and there's just no way to get around doing it as (+inf)-(+inf) ->
NaN; NaN.eq.0 -> .FALSE..  I desperately tried to get X3J3 to drop the
parentheses in this definition for Fortran 90, but-- alas --they
didn't seem to get the point (apologies to Keith B <grin>, but I think
the F90 X3J3 misses an awful lot of points the F77 X3J3 grasped).

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

>  [david keaton]
>  ...
>  IEEE and non-IEEE machines represent different sets of numbers, so
>  printing them out perfectly does not solve the portability problem.
>  Even if everyone does perfect conversions, shipping the same number
>  from Cray -> Sun -> Cray is likely to yield a number that is
>  different from what it started out to be.

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).  Sketchy argument:  we start with 48
bits and end with 53; correctly printing the 48 bits to 17 digits is
really printing those 48 bits augmented by an infinite number of
appended zeros to 17 digits, thus the IEEE machine must round to those
48 bits augmented by 5 appended zeroes -- and 17 digits is known to be
"enough" to yield a correct 53-bit result.

What may not work perfectly is *starting* from the machine with the
greater precision.  I think it's possible to be off 0.5 ulp (relative to
the less precise machine) compared to what you'd get if the original
wider-precision number were rounded directly to the narrower format.
But then you (trivially) are left with a number exactly representable
in the narrower format, so if the last paragraph's argument is correct
further transfers can't cause any *more* drift.  Anybody think all this
stuff out already?

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.  Then I incur essentially no
conversion costs and guarantee perfect accuracy with trivial code.
The beauty of the decimal-string representation is that it's
*independent* of the machine type -- perfect conversions appear to
get awfully close to solving a real problem on heterogeneous networks.
Yet the NCEG thrust is to require them only where they weren't needed
to begin with ...

>  [keith b]
> I spent about a decade tending to Kalman filtering codes
> ... [discussion of causes of program failures] ...
> ...
> not a major contributor issue. As computer vendors we should strive to
> make #3 less important ... generally customers assume that their
> computer works and can't be expected to tell us which part of the
> arithmetic is _really_ causing trouble.

They vote with their dollars in the end -- & a particular segment of
the market has routinely favored raw speed over accuracy, to judge
from what they keep buying.  I'm not saying *everyone* should favor
speed over accuracy, I'm saying that it's still an appropriate tradeoff
for a (important, too -- especially to NCEG) *segment* of the market.
I want to see NCEG be useful to them too.  Thoroughly agree that as a
vendor I want to give them all the accuracy I can, for precisely the
reasons you spelled; but I think 90% of CRI customers would insist
it's much more important to them to get a "bad" division result every
cycle than a "perfect" one every 10 cycles.  And they're probably
right (else they're awfully silly geese to keep asking for the same
outcome!).

> ...
> It would not be inappropriate, IMHO, for NCEG to hold C/IEEE systems
> to a higher standard than C/non-IEEE machines.

No problem with holding IEEE machines to higher stds than non-IEEE
machines (if there's a good reason to exempt non-IEEE machines).  NCEG
is attempting qualitatively more, to hold NCEG IEEE machines to a
higher std than IEEE-754 itself.  That goes way beyond "establishing a
binding".

> Looking at run-rate figures, it would appear that natural selection
> will take care of completely non-IEEE machines anyway.

Fads come & go, Keith -- & that cuts both ways <grin>.

>  [dgh]
>  ...
>  As usual most high-performance implementations will have a "fast"
>  mode in which they bypass the more onerous requirements in favor of
>  performance.

The "usual thing" for high-performance implementations is the
opposite, to go all out by default and have a variety of "slow" modes
for the wimps <grin>.  E.g., until I was forced onto a UNIX(tm) system
a couple years ago, it never occurred to me that anyone would
configure a compiler to run with optimization off by default (no
kidding!).

>  > E.g., suppose you get perfect
>  > conversions into NCEG -- what does that accomplish?
>  Everything.

If it only applies to NCEG implementations on IEEE machines, it
doesn't help me move between Suns and Crays, and it doesn't even help
me move between Fortran and C on the same machine.  I guess I expect
more from "everything" <smile>.

>  ...
>  Putting correctly-rounded conversions in IEEE 754 doesn't do much because
>  IEEE 754 doesn't tell how to get to them from C (printf and scanf might do
>  something different if they aren't constrained to be correctly-rounded).
>  It's not worth the trouble to revise 754/854 unless the revision includes
>  language bindings to C and Fortran, in my opinion.

Agreed the bindings are essential.

>  ...
>  > Think the most effective way to correct that is to revise 754.
>  Think about the politics of that suggestion.  Put tighter
>  requirements in NCEG, a new entity, and nobody loses, at least
>  immediately.  Tighten up 754 requirements and a bunch of existing
>  stuff becomes non-conforming.  So the resistance to change in any
>  standard is pretty significant.

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).  The politics here are, far as
I can see, the same as for every other std.  Except 754 *is* still
relatively fresh -- I can see some wisdom in fiddling with it in the
relative obscurity of NCEG.  Chances are better you'll get what you
want.

>  ...
>  The only specification that can provide identical results without
>  specifying an algorithm is the best possible, i.e. correct
>  rounding.

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
(listening to speed-obsessed users for any length of time does affect
one's views <grin>).

>  ...
>  It's hard to imagine a program that ran on every previous machine
>  that Seymour Cray had a hand in, that suddenly became unglued on
>  the Cray-1.

Exactly so!  Now you understand why I used the word "livid" -- 'twas
no exaggeration <smile>.

>  ...
>  I think this was true on CDC-6400 (as far as * /) whether you coded
>  in floating-point or integer arithmetic - it all ended up being
>  done in floating point.  And the results of / at least had to vary
>  depending on whether you used Seymour's not-quite-chopped or
>  not-quite-rounded arithmetic.

Yet even under all those baffling varieties of not-quite-anything-we-
have-a-name-for "disciplines", we always had 6./3. .GE. 2.; so long as
he used a "real" division algorithm, even Mr. Cray couldn't screw that
one up <grin -- but I really do greatly admire his designs for other
reasons>.

>  [keith b]
>  There are essentially no unnetworked platforms, merely sites that
>  haven't plugged in yet.

Keith, you are *such* a cheerleader <grin>!

>  [dgh]
>  ...
>  but people still write dumb log and pow functions and still build
>  Cray-style floating-point subtraction hardware without guard digits.

I'll predict that sloppy add/subtract will vanish, even on
supercomputers, during this decade.  Sloppy multiply too, but not
entirely until the end of the decade.  But I bet I'll still find
sloppy reciprocal divisions come the new millenium ...

with-any-luck-i'll-be-dead-then-so-someone-prove-it-wrong-now-ly y'rs
   - tim

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