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

Fri Nov 21 13:32:26 UTC 2014

In Pharo the Integer hierarchy is:

Integer
      LargeInteger
            LargeNegativeInteger
            LargePositiveInteger
      SmallInteger

For consistency l'll suggest:

Float
      LargeFloat
      SmallFloat

Now as Float are doubles by opposition to other floating pointers libraries
or ScaledDecimal, we may want to use double instead of float. But
smalltalkers are used to Float for doubles so I don't really see the point.

Double
      LargeDouble
      SmallDouble

If we add instead as suggested:

Float
      BoxedFloat
      ImmediateFloat

Are we going to change the Integer class hierarchy to match it like that:

Integer
      BoxedInteger
            BoxedNegativeInteger
            BoxedPositiveInteger
      ImmediateInteger

?

LargeIntegers are variable sized byte objects that are from 4 bytes to many
bytes long so it is more than just a boxed int.

On the other hand, non immediate floats are just boxed doubles. So having
BoxedFloat by opposition to LargeFloat to mean that this is just a boxed
object may make sense...

But does ImmediateInteger make sense ?

2014-11-21 14:01 GMT+01:00 J. Vuletich (mail lists) <juanlists at jvuletich.org
>:

>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141121/25368709/attachment.htm