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

[J. Vuletich (mail lists)]

Quoting Tobias Pape <Das.Linux at gmx.de>:

> On 21.11.2014, at 13:29, J. Vuletich (mail lists)  
> <juanlists at jvuletich.org> wrote:
>
>>
>> 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.
>
> SmallDouble sounds odd. Why not Single?[1] ;)
>
> Best
> 	-Tobias
>
> [1] Don't take that too serious

I was taking it serious when I got it :).

Maybe QueenSizeDouble and KingSizeDouble would work?

Cheers,
Juan Vuletich