Re: [Bug: 21.4.19] Bruised floating point numbers from string-to-int

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