[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 plaintop 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