Sorry, i'm a little behind on this. I'll try to catch up over the next day or two. On Sun, 9 Apr 2000, Tim Peters wrote:
Note the example from another reply of a machine with 2-bit floats. There the user would see:
0.75 # happens to be exactly representable on this machine 0.8 # because that's the shortest string needed on this machine # to get back 0.75 internally
This kind of surprise is inherent in the approach, not specific to 2-bit machines <wink>.
Okay, okay. But on a 2-bit machine you ought to be no more surprised by the above than by >>> 0.1 + 0.1 0.0 >>> 0.4 + 0.4 1.0 In fact, i suppose one could argue that 0.8 is just as honest as 0.75, as you could get 0.8 from anything in (0.625, 0.825)... or even *more* honest than 0.75, since "0.75" shows more significant digits than the precision of machine would justify. <shrug> It could be argued either way. I don't see this as a fatal flaw of the 'smartrepr' method, though. After looking at the spec for java.lang.Float.toString() and the Clinger paper you mentioned, it appears to me that both essentially describe 'smartrepr', which seems encouraging.
BTW, I don't know that it will never print more digits than you type: did you prove that? It's plausible, but many plausible claims about fp turn out to be false.
Indeed, fp *is* tricky, but i think in this case the proof actually is pretty evident -- The 'smartrepr' routine i suggested prints the representation with the fewest number of digits which converts back to the actual value. Since the thing that you originally typed converted to that value the first time around, certainly no *more* digits than what you typed are necessary to produce that value again. QED.
- If you type in what the interpreter displays for a float, you can be assured of getting the same value.
This isn't of value for most interactive use -- in general you want to see the range of a number, not enough to get 53 bits exactly (that's beyond the limits of human "number sense").
What do you mean by "the range of a number"?
It also has one clearly bad aspect: when printing containers full of floats, the number of digits printed for each will vary wildly from float to float. Makes for an unfriendly display.
Yes, this is something you want to be able to control -- read on.
If the prompt's display function were settable, I'd probably plug in pprint!
Since i've managed to convince Guido that such a hook might be nice, i seem to have worked myself into the position of being responsible for putting together a patch to do so... Configurability is good. It won't solve everything, but at least the flexibility provided by a "display" hook will let everybody have the ability to play whatever tricks they want. (Or, equivalently: to anyone who complains about the interpreter display, at least we have plausible grounds on which to tell them to go fix it themselves.) :) Here is what i have in mind: provide two hooks __builtins__.display(object) and __builtins__.displaytb(traceback, exception) that are called when the interpreter needs to display a result or when the top level catches an exception. Protocol is simple: 'display' gets one argument, an object, and can do whatever the heck it wants. 'displaytb' gets a traceback and an exception, and can do whatever the heck it wants. -- ?!ng "Je n'aime pas les stupides gar�ons, m�me quand ils sont intelligents." -- Roople Unia