On 1 Jun 2017, at 15:29, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
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.
If I am on 64-bit and SmallFloat64 is used (the default, right ?), then I have a smaller exponent range (right ?), so I should be able to access meta info about the currently applying limits, no ? I recently added that to NeoJSON to protect against overly large/small exponents when reading floats, like 1e1231231231. I understand about this being an implementation detail, but if the choice of implementation changes the range, it seems important to be able to know this, one way or another.
For the rest of the report, it's a bug we will have to track catch and fix ASAP
Thanks!
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