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 <[email protected]>: > 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 >
