Eliot Miranda wrote:
>  
> Hi Ben,
> 
> On Nov 20, 2014, at 8:42 PM, Ben Coman <btc at openInWorld.com> wrote:
> 
>> Eliot Miranda wrote:
>>> On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc at openinworld.com <mailto:btc at openinworld.com>> wrote:
>>>    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?
>>> Just as SmallInteger is seamless with the large integers, so SmallFloat is seamless with boxed Float.  The SmallFloat representation is used where ever possible, since it is faster both to decode (no memory fetch) and to encode (no allocation).  But operations overflow into the boxed representation if outside the SmallFloat range.
>> (btw, rather than SmallFloat and BoxedFloat, I think SmallFloat and LargeFloat would align better with the Integer hierarchy.)
>>
>> So I understand that immediate types will overflow to boxes types :)
>>
>> To try to be more clear, integers don't have a well defined size/format.  It varies with architecture word size.  So SmallInteger and LargeInteger are reasonable descriptions.  But floats have a well defined format defined by IEEE. Since you are pivoting around the IEEE Double format (you define it as "61-bit subset of the ieee double precision float"), rather than generic SmallFloat and LargeFloat, use SmallDouble and LargeDouble. (anyway, maybe I'm off track. Its not a big deal).
> 
> Ah, I like this.  Thanks.

Cool. :)

David T. Lewis wrote:
 >
 > 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.

You also might also have Single subclassed from abstract Float.

cheers -ben