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