correctly-rounded base conversion

[David Hough]

The thesis of Jerome Coonen may still be available by writing to him
at Apple Computer.  Floating-Point Computation, Pat H. Sterbenz,
Prentice Hall, 1974, has been out of print for many years but a copy
to copy should be in most university libraries.  Hate mail to
Prentice Hall or love mail to Chelsea Press asking them to reprint
it may be in order.

> The primary meaning of "practical" to me (& probably to Tom MacD too)
> is "doesn't run appreciably slower than the sloppy methods we use now"

How about "doesn't have significant performance impact on realistic 
applications".    The sloppy methods you are using now probably don't
meet 754 requirements for normal exponents anyway.

> some (probably a minority of) IEEE vendors still
> favor speed over accuracy where the two conflict and 754 permits a
> tradeoff.

Aside from the supercomputer arena, speed seldom conflicts with accuracy,
if the accuracy is designed in from the beginning by sufficiently
clever people.  The TI 8847 division and sqrt are good examples.
The only place in 754 where a tradeoff between speed and accuracy 
is permitted is in the one specific instance
of base conversion of large exponents.

The most important point, however, is that among users of heterogeneous
networks, many more than I would have thought would be willing to 
sacrifice some local speed in order to get a global speedup by using
network computing.  This is a lot easier to deal with if each node
delivers exactly the same numerical results for exactly the same input data,
independent of manufacturer or compiler or library.
For IEEE 754 systems this goal is achievable with respect to expression 
evaluation, base conversion, and single precision elementary transcendental
functions, at reasonable cost; higher precision elementary transcendental
functions are still somewhat researchy, but methods that are occasionally
slow may not matter because elementary transcendental functions are not 
in the inner loops of most realistic applications.  I suspect that once
quadruple-precision hardware is available as envisioned by (at least)
the IBM 370, VAX, HP PA, and SPARC architectures, then correctly-rounded
double precision elementary transcendental functions will be a routine
expectation.  If that prospect worries anybody on this mailing list, then
they may want to take steps to support people working on publicly available
software in this area.

> >  > [Note:  the ANSI C Standard permits any of X0, X1 or X2 as an
> >  > acceptable conversion.]
> >
> 1) I'm no ANSI C expert, but I didn't find any words in the ANSI C std
>    supporting Tom's claim there.

The latitude mentioned above applies only to conversion between binary
and decimal, I think.  The wording was worked out at an X3J11 meeting in
Sunnyvale.
> 
> 2) Although it's not obvious from CRI's manuals, CRI hardware does
>    support fast "16x16->32 unsigned integer multiply and 32/16->16,16
>    unsigned integer quotient/remainder" *sequences*

Actually the issue is not 16<->32 but short<->long.  On a system with
64-bit ints, you might be talking about 32<->64 or 64<->128, depending
on what works best.
> 
> I worked at Cray for nearly a decade, and I think the answer is that
> it's not a real issue for CRI.  Most supercomputer users are much more
> interested in speed than good-to-the-last-bit accuracy, and the single
> most common gripe about Cray's fp arithmetic was the strange kinda-
> truncated-twice addition.

Most of the problems are caused by division, and to a lesser extent
multiplication, because it's very difficult to predict what the answer
will be.  I think Cray will have to deal with the issue eventually
because of network computing considerations as mentioned earlier.

> >  I think requiring correctly-rounded base conversion on non-IEEE
> >  systems is probably pointless in the NCEG report, especially if it's
> >  controversial.
> 
> I don't understand the conclusion, since the only "controversy" here is
> whether fast methods are publically available:  the "perfect" algorithms
> (based on what was said above) make no essential use of IEEE features,
> so why exempt non-IEEE vendors from implementing them?  On the other
> hand, if such algorithms can't be made "practically" fast, why force
> them on anyone?

The main point again is that IEEE systems from diverse vendors benefit
from correctly-rounded base conversion in a network computing environment,
but VAX, IBM 370, and Cray systems will still get different results from
IEEE and each other no matter how they do base conversion.  So the value
of constraining the proprietary floating-point architectures is less 
than the trouble it would take.