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

sjt> Welcome to floating point! All hope abandon, ye who enter here. sjt> Please note that *all* floating values are unsightly, containing a sjt> 53-bit mantissa where IEEE 754 doubles are used (about 16 digits, as sjt> in your example). As a matter of historical practice, most standard sjt> libraries truncate trailing zeros when printing. VC++ apparently sjt> applies some kind of heuristic to "simplify" trailing nines as well. sjt> However, there are always going to be examples that produce what you sjt> consider bad behavior. In fact, consider sjt> (format "%s" (+ 0.125 0.875)) => "1.0" sjt> I bet you would want 1.000, no? You just can't win. If you don't get 1.0, you have a badly broken system, if you are using IEEE 754. 0.125 and 0.875 can be represented exactly, and so can their sum. If you don't get 1.0, then your reader is broken or your printer. Or, perhaps, + is broken. :-) sjt> Yup. `string-to-int' is an alias for `string-to-number', which is sjt> (ultimately) just a wrapper around the platform's printf implementation. sjt> What you get is what you get. But it is possible to do a better job. There exist algorithms to read decimals and produce closest representable IEEE number. Likewise, there are algorithms for printing IEEE numbers such that the resulting output is the closest representation, and which, when read back, produce *exactly* the same IEEE number. CMUCL prints "8.18e-1" exactly like that. Perhaps printf/scanf doesn't use those algorithms. Ray