Ben Coman wrote:
Eliot Miranda wrote:
Hi Ben,
On Nov 20, 2014, at 8:42 PM, Ben Coman <btc@openInWorld.com> wrote:
Eliot Miranda wrote:
On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc@openinworld.com <mailto:btc@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.
a random thought on implementation of LargeDouble... is it worth considering a performance versus space tradeoff... rather than boxing LargeDouble so that access through a pointer reduces performance(?), could the value be stored in a second 64bits adjacent to the first? Or does being 128 bits in total complicate things too much? cheers -ben