<div dir="ltr">Hi Ben,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
(sorry, I didn't notice the cross-post)</blockquote><div><br></div><div>Thanks, Ben.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi All,<br>
<br>
64-bit Spur can usefully provide an immediate float, a 61-bit subset of the ieee double precision float. <br>
</blockquote>
<br>
I wonder if class SmallDouble would be more intention revealing?<br>
<br></span>
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?</blockquote><div><br></div><div><br class="">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.<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
<br>
</blockquote>
<br>
My first few pages of search results lead to a few references in<br>
conversation, but nothing that described what a boxed float is. Can<br>
someone explain?<br></span></blockquote><div><br></div><div>Boxed datatypes are those where the data is held in a structure (e.g. an object) and accessed throguh a pointer. So most Smalltalk objects are "boxed", for example, large integers, points, etc. But some datatypes (immediate SmallIntegers, and in Spur, the Characters, and in languages like C, all basic numeric types) are represented as pure values.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">btw, <a href="http://www.ctan.org/pkg/float" target="_blank">http://www.ctan.org/pkg/float</a><br>
also mentioned boxed float, ruled float and plaintop float<br>
Anyone familiar with those?<br></span></blockquote><div><br></div><div>Hmmm, never heard of ruled and plaintop floats. I'd like to know too.<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
With this approach ...<br>
<br>
- 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". <br>
</blockquote>
<br></span>
This is probably a good change anyway.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
- 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.<br>
<br></span>
- 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.<br>
</blockquote>
<br>
** do you mean the current Float, or after Float become abstract?</blockquote><div><br></div><div>The former. If Float stays unchanged and one tries to add SmallFloat as a subclass then one hits the primitive failure problem. If SmallFloat doesn't inherit from BoxedFloat (when Float is abstract with BoxedFloat and SmallFloat as subclasses), or if SmallFloat doesn't inherit from Float (when LimitedPrecisionReal is abstract, and BoxedFloat and SmallFloat inherit from it) then there's no such problem.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
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.<br>
<br>
</blockquote>
<br>
A Float is defined as a limited precision real [1] having several types<br>
of precision, so I like the first option.<br>
<br>
[1] <a href="http://en.wikipedia.org/wiki/Floating_point" target="_blank">http://en.wikipedia.org/wiki/<u></u>Floating_point</a><br>
<br>
cheers -ben<br></div></div></blockquote><div><br></div><div>OK, thanks! </div></div><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>