8.5.2 floating point issues

I have found that VASmalltalk handles floating point numbers differently than other Smalltalks (specifically, VisualWorks and GemStone).

(2 raisedTo: -127) asFloat prints as 5.87747175411144e-39, but 5.87747175411144e-39 is actually equal to (2 raisedTo: -127) asFloat + ((2 raisedTo: -179) asFloat * 2).

In GemStone and in VisualWorks, 5.877471754111438d-39 is equal to (2 raisedTo: -127) asFloat. (I realize floating point numbers are an approximation, and I admit that I have no idea whether VW and GS have it correct.) However, in VASmalltalk, ((2 raisedTo: -127) asFloat + (2 raisedTo: -179) asFloat) = 5.877471754111438d-39.

Finally, when comparing the Smalltalk parser (scanner, actually) to the Smalltalk Number hierarchy API, the following test fails.
| number alternate |
number := 5.877471754111438d-39.
alternate := Float fromString: number printString.
number = alternate

This fails because the printString has "too many digits". Note that it is shorter than the one accepted by the parser/scanner. This is apparently because of the different exponent letter used. The #fromString: implementation cannot handle"d" being used instead of "e".



Please make the Number implementation compatible with that of the scanner, at least. Also, please investigate whether the current floating point algorithms are accurate to the last bit.

(Printing and rounding during printing are different issues.

Preservation of the "d" exponent would be welcome.

Being able to recreate the original value from the printed representation would be welcome. GemStone prints (2 raisedTo: -127) as 5.8774717541114375E-39 and can parse that value to get the original number. I recognize that ANSI does not require this.
In my opinion, whenever an object could be represented and recreated as a literal from its printString, it would be best if the printString were accurate enough to do so.)

Thanks for the feedback, John. Yes, Martin really does seem to know this stuff! I've tried hard to avoid it, and succeeded for the longest time. :-)

I would not argue against objections guaranteeing a specific bit pattern arising from a specific set of digits, as much as having "perfect" representations would be nice. As long as we can get the bit patterns needed using (2 raisedTo: ...) asFloat or some other way (such as basicNew, basicAt:put:), I don't really care.



On Monday, January 6, 2014 2:36:35 PM UTC-8, John O'Keefe wrote:

Richard -

I'll paraphrase from the Wikipedia article on IEEE floating point: in a normalized double, the mantissa contains 53 bits (52 explicit + 1 implicit) of information -- this corresponds to 15.95 decimal places. So I guess the first question is whether printOn:/printString/asString should produce 15 or 16 digits to the right of the decimal point. A brief survey shows VW and Pharo use 15 digits, while VA Smalltalk and Dolphin use 14. I might have chosen 16 digits myself (since 15.95 seems very close to 16), but I don't claim to be an expect on the subtle nuances of floating point arithmetic (perhaps you could ask Martin McClure about this since we have had several long discussions which prove to me that he knows a lot more than I do about floating point arithmetic).

In any case, VA Smalltalk seems wrong -- it should produce at least one more digit.

In VA Smalltalk, "d" is not used as an exponent signifier for Floats, it is the (deprecated) signifier for the ScaledDecimal precision and scale. This explains why Float fromString: '5.877471754111438d-39' fails -- the string is interpreted as a ScaledDecimal with a precision of -39. Changing this would be a migration issue for us. I will ponder this a bit more, but I don't have any good ideas right now.

John