<div dir="ltr">Hi Tobias,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eliot<br>
<div><div class="h5"><br>
On 21.11.2014, at 19:06, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> Hi Tobias,<br>
><br>
> On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > On 21.11.2014, at 13:44, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> ><br>
> > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) <<br>
> > <a href="mailto:juanlists@jvuletich.org">juanlists@jvuletich.org</a>> wrote:<br>
> > ><br>
> > >> Quoting Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>>:<br>
> > >>><br>
> > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete<br>
> > subclasses (*). Names do mean something. (**)<br>
> > >>><br>
> > >>> You're right about the FloatArray confusion. However, note that the<br>
> > IEEE standard calls it single and double. It's only C using "float" to mean<br>
> > "single precision".<br>
> > >>><br>
> > >>> I'd name the abstract superclass Float, for readability, and the<br>
> > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I<br>
> > don't see the need for having a deep LimitedPrecisionReal - Float -<br>
> > BoxedDouble/ImmediateDouble deep hierarchy now.<br>
> > >>><br>
> > >>> If we ever add single-precision floats, we should name them<br>
> > BoxedSingle and ImmediateSingle. At that point we might want a Single<br>
> > superclass and a LimitedPrecisionReal supersuperclass, but we can cross<br>
> > that bridge when we get there.<br>
> > >>><br>
> > >>> - Bert -<br>
> > >>><br>
> > >>> (*) Since we're not going to see the class names often, we could even<br>
> > spell it out as BoxedDoublePrecisionFloat and<br>
> > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation<br>
> > to the abstract Float very clear.<br>
> > >>><br>
> > >>> (**) We could also try to make the names googleable. I was surprised<br>
> > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it.<br>
> > Maybe there are two better words?<br>
> > >><br>
> > >> I very much agree with Bert. But I'd suggest SmallDouble instead of<br>
> > ImmediateDouble for consistency with SmallInteger.<br>
> > ><br>
> > > Then it would have to be LargeDouble for consistency with LargeInteger,<br>
> > too. Which I don't find compelling.<br>
> > ><br>
> > > Also, with the 64 bit format we get many more immediate objects. There<br>
> > already are immediate integers and characters, floats will be the third,<br>
> > there could be more, like immediate points. For those, the small/large<br>
> > distinction does not make sense.<br>
> > ><br>
> > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead<br>
> > of "small" use "immediate":<br>
> > ><br>
> > > Float - BoxedFloat - ImmediateFloat<br>
> > ><br>
> > > A Float is either a BoxedFloat or an ImmediateFloat, depending on<br>
> > the magnitude of its exponent.<br>
> ><br>
> > I don't like the idea of putting a VM/Storage detail into the Class name.<br>
> > The running system itself does not care about whether Floats or Integers<br>
> > are<br>
> > boxed or immediate.<br>
> ><br>
><br>
> I disagree. I think at least Smalltalk-80 has a philosophy of lifting as<br>
> much out of the VM into the system, and hiding it from clients via<br>
> encapsulation. So unlike many other VMs the compiler is in the system, the<br>
> system explicitly separates SmallInteger, LargePositiveInteger and<br>
> LargeNegativeInteger and implements large integer arithmetic with Smalltalk<br>
> code that uses SmallIntegers. Note that the primitives are an optional<br>
> extra optimization that the VM does not need to implement. So for me it is<br>
> in keeping with the current system to use BoxedFloat and SmallFloat or<br>
> BoxedDouble and SmallDouble.<br>
><br>
> This lifting things up provides us with an extremely malleable system.<br>
> Pushing things down into the VM does the opposite.<br>
><br>
<br>
</div></div>I can understand. It is however a tradeoff between abstraction and malleability.<br>
I'd rather see everything done in Smalltalk. Yet primitives not exposing its<br>
innards.<br>
<br>
I think I just can't have the cake and have it, too.<br></blockquote><div><br></div><div>yes, alas it is all about tradeoffs :-). But that's great. The more varieties the merrier.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> For example in RSqueakVM (aka SPy) there is no immediate<br>
> > Integer whatsoever. Yes, tagged ints are read during image startup but they<br>
> > aren't subsequently represented as immediates or tagged ints after that.<br>
> ><br>
><br>
> Well because it's implemented above RPython I guess it is using Python's<br>
> bignum code directly. That's fine but its a bit of a cheat.<br>
<br>
</span>I was talking of SmallInts here. There is no bignum code involved.<br>
On the RPython side, SmallIntegers are just objects that have a field<br>
that is not accessible from Smalltalk but keeps a machine-word integer.<br></blockquote><div><br></div><div>Hmmm, somewhere there's got to be a discrimination between SmallIntegers and other objects, right? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> > Just as input, in the Racket language and other Schemes,<br>
> > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum<br>
> > and for floats they have flonums and "extflonums" (80bit).<br>
> ><br>
> > Best<br>
> > -Tobias<br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>