Perfect FP <-> decimal conversions

[Tim Peters]

>  [dgh]
>  Anyway, available means the idea is written up in Coonen's thesis
>  (in an appendix) and implemented in Pascal.  Sterbenz' book is a
>  good place to start if you haven't thought about the details
>  before.

Thanks for the pointers!  Don't recognize the Sterbenz reference --
have a title handy?

It's easy enough to think of ways to do perfect conversions, what
seems to be at issue are the meanings of "available" and "practical".
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"
-- and I doubt that fast perfect conversion algorithms are publically
available.  If not, it will be hard to sell NCEG's more-extreme-than-
754's position here:  some (probably a minority of) IEEE vendors still
favor speed over accuracy where the two conflict and 754 permits a
tradeoff.  If the claim is that 754 was overly permissive in this
area, the place to fix that is in a revision to 754 (although I sure
understand the politics of ramming it into NCEG first to prove to IEEE
that it's now accepted practice <grin>).

>  No floating-point hardware or large tables are used - it's all
>  done with integer arithmetic. ...

That's enough clues for me (thanks again!) -- I'll think about how
fast I could make it run.

>  > [tom macd]
>  > [Note:  the ANSI C Standard permits any of X0, X1 or X2 as an
>  > acceptable conversion.]
>
>  But even that will be extremely difficult to produce on a Cray!
>  Especially for big exponents or double precision.

1) I'm no ANSI C expert, but I didn't find any words in the ANSI C std
   supporting Tom's claim there.  On inexact int->float conversions
   they require the implementation to return one of (implementor's
   choice) the closest representable floats, on inexact float->int
   they require truncation, & on inexact float->float they require one
   of (implementor's choice) the closest representable floats, but I
   couldn't find anything constraining the accuracy of decimal(ASCII)
   <-> float conversions.  Tom?

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* (not up to Dr.
   Rubin's expectations, but what is <grin>?).  If fast perfect
   conversions can indeed be built out of those operations, there's no
   reason to let CRI off the hook.

>  I'd say the real issue for Cray is this:  how will an architecture
>  like Cray's, where even integer division is chancy or expensive,
>  respond to expectations of higher accuracy and numerical quality
>  developed in an arena of relatively low performance personal
>  computers and workstations?

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.  If CRI fixed just that, I think most of its
users would be happy (that's a prediction, not an argument <grin> -- I
don't feel they *should* be happy then, just predicting that most
*would* be happy <sigh>).

>  IBM for sure, and possibly DEC are working toward correctly-rounded
>  transcendental functions, as well ...

Why?  I can't think of anyone I've ever met or heard of who both has
budget authority and would buy a machine on this basis.  But I suppose
IBM can afford to fund projects that are "just" good for the soul; & I
hope they succeed.

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

having-arrived-back-at-the-departure-point-ly y'rs  - tim

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