A page re perfect conversion

[Tim Peters]

>  [tom macd]
>  ...
>  Finally, I don't believe that C standards activity (like NCEG)
>  should mandate one side of the speed vs. accuracy coin.  We are
>  not serving their needs by doing this.  We need to provide perfect
>  conversions for those that need it but allow for those that are
>  trying to explore new ways to solve problems in a reasonable
>  amount of time.

Are you quite sure NCEG "needs to provide perfect conversions for
those that need it"?  I.e., I don't think "someone says they need it"
is a strong enough reason for mandating it as a primitive -- else NCEG
will surpass Fortran 90 in complexity by the end of next week <grin>.
In this case, the people who say they need it seem to be the ones who
already have it <0.8 grin -- much the same could be said about vector
syntax, eh?>.

>  [earl killian]
>  ...
>  As for the 54 9's case, this raises an interesting point about what is
>  meant by accurate binary to decimal conversion.
>  ...
>  however our routines only look at the first 17 significant digits
>  of the input string ... Handling more than 17 significant digits
>  was a non-goal for us.  17 is enough so that you can convert fp ->
>  string -> fp and always get the same number back.  We also produce
>  0's after 17 digits on output, unlike David's routines.

Good question!  I initially jumped into this discussion because I
wanted to know what the NCEG text meant, and it occurs to me I haven't
heard an answer yet <grin>.  I hope that whatever NCEG does here it
makes it very clear.  E.g., I don't think the 754 text was at all
clear about the intended handling of inexact on >17 digit conversions,
and 854 confused me more by saying you "should" (not "shall") signal
inexact if you take the truncate-to-17-digits option these stds bless.

>  [david keaton]
>  ...
>       This may give rise to another problem.  If you can tell the
>  magnitude of a number by how long it takes to print it out, that opens
>  up a security hole in formerly secure systems.  I don't expect it to
>  cause problems in most cases, but there are some customers who will
>  need to be aware of it.

No, it just causes problems with everyone's biggest off-the-books
customers <grin>.  That is *really* an irritating observation, David;
but thanks for making it.

arghgh-ly y'rs  - tim

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