2017-06-01 15:29 GMT+02:00 Nicolas Cellier < [email protected]>:
> 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 > > (is looks like a shift of 1 bit) > 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 >> > >
