Can't reproduce in Squeak trunk 64bits with latest opensmalltalk-VM, So for me it should'nt be a VM problem, (or it's fixed already).
2017-06-01 15:31 GMT+02:00 Nicolas Cellier < [email protected]>: > > > 2017-06-01 15:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> 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 >>> >> >> >
