[Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

[J. Vuletich (mail lists)]

Quoting Bert Freudenberg <bert at freudenbergs.de>:

> On 21.11.2014, at 04:19, David T. Lewis <lewis at mail.msen.com> wrote:
>
>> On Thu, Nov 20, 2014 at 05:51:42PM -0800, Eliot Miranda wrote:
>>> Hi All,
>>>
>>>    64-bit Spur can usefully provide an immediate float, a 61-bit subset of
>>> the ieee double precision float.  The scheme steals bits from the mantissa
>>> to use for the immediate's 3-bit tag pattern.  So values have the same
>>> precision as ieee doubles, but can only represent the subset with exponents
>>> between 10^-38 and 10^38, the single-precision range.  The issue here is
>>> how to organize the class hierarchy.
>>>
>>> The approach that looks best to me is to modify class Float to be an
>>> abstract class, and add two subclasses, BoxedFloat and SmallFloat, such
>>> that existing boxed instances of Float outside the SmallFloat range will
>>> become instances of BoxedFloat and instances within that range will be
>>> replaced by references to the relevant SmallFloat.
>>>
>>> With this approach ...
>>>
>>> - Float pi etc can still be used, even though they will answer instances of
>>> SmallFloat.  But tests such as "self assert: result class == Float." will
>>> need to be rewritten to e.g.  "self assert: result isFloat".
>>>
>>> - BoxedFloat and SmallFloat will not be mentioned much at all since floats
>>> print themselves literally, and so the fact that the classes have changed
>>> won't be obvious.
>>>
>>> - the boxed Float primitives (receiver is a boxed float) live in BoxedFloat
>>> and the immediate ones live in SmallFloat.  Making SmallFloat a subclass of
>>> Float poses problems for all the primitives that do a super send to retry,
>>> since the boxed Float prims will be above the unboxed ones and so the boxed
>>> ones would have to test for an immediate receiver.
>>>
>>>
>>> An alternative, that VW took (because it has both Float and Double) is to
>>> add a superclass, e.g. LimitedPrecisionReal, move most of the methods into
>>> it, and keep Float as Float, and add SmallFloat as a subclass of
>>> LimitedPrecisionReal.  Then while class-side methods such as pi would
>>> likely be implemented in LimitedPrecisionReal class, sends to Float to
>>> access them find them via inheritance.  An automatic reorganization which
>>> moves only primitives out of LimitedPrecisionReal is easy to write.
>>>
>>> Thoughts?
>>
>> I have always felt that the mapping of Float to 64-bit double and FloatArray
>> to 32-bit float is awkward. It may be that 32-bit floats are becoming less
>> relevant nowadays, but if short float values are still important, then it
>> would be nice to be able to represent them directly. I like the  
>> idea of having
>> a Float class and a Double class to represent the two most common  
>> representations.
>> A class hierarchy that could potentially support this sounds like a  
>> good idea to me.
>>
>> I have no experience with VW, but a LimitedPrecisionReal hierachy  
>> sounds like a
>> reasonable approach.
>>
>> Dave
>
> I'd suggest BoxedDouble and ImmediateDouble as names for the  
> concrete subclasses (*). Names do mean something. (**)
>
> You're right about the FloatArray confusion. However, note that the  
> IEEE standard calls it single and double. It's only C using "float"  
> to mean "single precision".
>
> I'd name the abstract superclass Float, for readability, and the  
> isFloat test etc. Also: "Float pi" reads a lot nicer than anything  
> else. I don't see the need for having a deep LimitedPrecisionReal -  
> Float - BoxedDouble/ImmediateDouble deep hierarchy now.
>
> If we ever add single-precision floats, we should name them  
> BoxedSingle and ImmediateSingle. At that point we might want a  
> Single superclass and a LimitedPrecisionReal supersuperclass, but we  
> can cross that bridge when we get there.
>
> - Bert -
>
> (*) Since we're not going to see the class names often, we could  
> even spell it out as BoxedDoublePrecisionFloat and  
> ImmediateDoublePrecisionFloat. Only half joking. It would make the  
> relation to the abstract Float very clear.
>
> (**) We could also try to make the names googleable. I was surprised  
> to not get a good hit for "boxed immediate". Only "boxed unboxed"  
> finds it. Maybe there are two better words?

I very much agree with Bert. But I'd suggest SmallDouble instead of  
ImmediateDouble for consistency with SmallInteger.

Cheers,
Juan Vuletich