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