Hi Sven, SmallFloat64 consumes 3bits taken from exponent for tagging immediate value. So very small values and very large values don't fit in SmallFloat64 and require a BoxedFloat64. I don't think we should change emin and emax though. The reason is that emin and emax are public methods for accessing the underlying floating point model. Small/Boxed Float are implementation details, they both implement the same float model with different levels of optimization. For the rest of the report, it's a bug we will have to track catch and fix ASAP 2017-06-01 14:53 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
I am working in Pharo 6 RC, 64-bit on macOS 10.12.5
One of the tests of STON fails, #testFloat and I got confused about Floats on 64-bit Pharo 6.
Is there a write-up that explains the new/changed situation ?
Because, what I see is the following:
Float pi. 1.3.
Both the above give me SmallFloat64 instances.
(10 raisedTo: 100) asFloat. 1.0e100. 10.0 raisedTo: 100.
All 3 above give me BoxedFloat64 instance. But the first 2 give wrong results (correct answer is 1.0e100) !
(10 raisedTo: 100) asFloat. "5.15323791002091e91"
1.0e100. "5.15323791002091e91"
Why ?
BoxedFloat64 allInstances. SmallFloat64 allInstances.
The first is not-empty, the second is (logical since these are immediate values). I thought BoxedFloat64 should not be used in 64-bit ?
Also, should #emin, #emax and friends not be different for SmallFloat64 ?
Sven