[squeak-dev] Float hierarchy for 64-bit Spur
J. Vuletich (mail lists)
juanlists at jvuletich.org
Fri Nov 21 12:29:32 UTC 2014
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
More information about the Squeak-dev
mailing list
|