On Sep 22, 2011, at 6:20 PM, Nicolas Cellier wrote:

> 2011/9/22 Stéphane Ducasse <[email protected]>:
>> Hello nicolas
>> 
>> 
>> On Sep 22, 2011, at 12:17 AM, Nicolas Cellier wrote:
>> 
>>> It's too long for a mail, but all explained here:
>>> http://smallissimo.blogspot.com/2011/09/clarifying-and-optimizing.html
>>> 
>>> Optimizing such kernel message is important - for example when reading
>>> a file of floats...
>>> Which version do you prefer ?
>>> Shall comments be that long ?
>> 
>> YESSSSS :)
>> We love good comments!
>> And comments should be close to the code else they rot.
>> There is no problem having long nd precise comments that empower the reader.
>> 
> 
> Yes, but if you implement any RFC, you generally put a reference
> because that is too much duplicated information...
> So there must be a threshold when a link becomes more clever than
> inlined comments.
> I'm glad if I'm below this threshold.
> 
>> 
>>> Any other opinion ?
>> 
>> One important question is what is the impact of the hardware dirven solution 
>> on bit identical computation
>> on different machine. I would do the following:
>>        use the smalltalk - bit identical idea all the times
>>        provide one methods for people knowing that they want to get faster 
>> but potentially different floats on different platform.
>> 
>> Does it make sense?
> 
> Bit identical computations rely on the rounding mode which is set in
> hardware flags.
> To my knowledge, all Smalltalk dialects use the default settings and
> never change it.
> So the case of asFloat is not different from * + - / and other
> mathematical functions.
> They all rely on this setting.
> 
> I see I introduced a doubt in the blog because I took a perspective of
> possible future extensions.
> But my intention was to resolve it; case of bad English style ?

may be just that we are bad with numbers :)
So you are saying that your solutions requires that the platform are IEEE754
so the risks is low then. 

> Now if some platforms don't adhere to IEEE754, then I think that we
> must first try to find a compatibility layer at VM level
> It's not difficult to emulate floating point arithmetic in Smalltalk -
> see http://smallissimo.blogspot.com/2011/08/arbitraryprecisionfloat.html
> (which however does not handle overflow, gradual underflow and NaN).
> However it's hard to do it with decent speeds...
> 
> Nicolas
> 
>> 
>> Stef
>> 
>> 
>>> 
>>> Nicolas
>>> 
>> 
>> 
>> 
> 


Reply via email to