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

Ben Coman btc at openInWorld.com
Fri Nov 21 03:00:10 UTC 2014

(sorry, I didn't notice the cross-post)

Eliot Miranda wrote:
> Hi All,
>     64-bit Spur can usefully provide an immediate float, a 61-bit subset 
> of the ieee double precision float.  

I wonder if class SmallDouble would be more intention revealing?

In practice 61 bits will be "more than enough"(tm) for anyone. But I can 
envisage in a business environment environment software needing to 
comply with (sometimes irrelevant) feature checklists, with one of those 
likely being full 64 bit compliant IEEE Doubles.  Can we have such a 
class, to which 61 bit floats are auto-promoted as required?

> 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.

My first few pages of search results lead to a few references in
conversation, but nothing that described what a boxed float is. Can
someone explain?

btw, http://www.ctan.org/pkg/float
also mentioned boxed float, ruled float and plain­top float
Anyone familiar with those?

> 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".  

This is probably a good change anyway.

> - 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.

** do you mean the current Float, or after Float become abstract?

> 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.

A Float is defined as a limited precision real [1] having several types
of precision, so I like the first option.

[1] http://en.wikipedia.org/wiki/Floating_point

cheers -ben

More information about the Vm-dev mailing list