>>>> "sjt" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "Raymond" == Raymond Toy
<raymond.toy(a)ericsson.com> writes:
Raymond> If you don't get 1.0,
you have a badly broken system, if
Raymond> you are using IEEE 754. 0.125 and 0.875 can be
Raymond> represented exactly, and so can their sum. If you don't
Raymond> get 1.0, then your reader is broken or your printer. Or,
Raymond> perhaps, + is broken. :-)
sjt> But what if I get 1.000? Where is something broken? My point is that
sjt> a conscientious human presented with the problem
Oops. Sorry. I misinterpreted what you wanted. The true answer is
exactly 1, but you wanted it printed out with trailing zeroes.
sjt> Yup. `string-to-int' is an alias for `string-to-number',
sjt> which is (ultimately) just a wrapper around the platform's
sjt> printf implementation.
sjt> What you get is what you get.
Raymond> But it is possible to do a better job.
Raymond> CMUCL prints "8.18e-1" exactly like that.
sjt> Which is *arguably wrong* because you've lost a digit of precision. I
sjt> really don't think *Rodney* can win this way. Yes, *we* could get
sjt> prettier output for the occasional number, but he's working with
sjt> tables.
I think this is a similar confusion on my part. I meant that the
result is printed as 0.818 instead of 0.8179999...
sjt> Microsoft's apparent do, Unices don't. Not worth our effort to
sjt> replace them, I suggest, unless somebody != me :-) wants to look up
sjt> the various algorithms *and* present the rationales, *and* document
sjt> the algorithms so people know what to expect, *as well as* update our
The algorithm for printing floating point numbers accurately is
available in C on the web, along with a document describing the
algorithm. (Look for Dybvig.)
But I don't use xemacs for floating point work so I have no intentions
of doing this either. :-)
Ray