[squeak-dev] Re: FloatMathPlugin in Squeak for Croquet compatability?

Andreas Raab andreas.raab at gmx.de
Tue Dec 14 05:07:44 UTC 2010


On 12/13/2010 7:42 PM, Levente Uzonyi wrote:
> On Mon, 13 Dec 2010, Andreas Raab wrote:
>
>> On 12/13/2010 5:35 PM, Levente Uzonyi wrote:
>>> There were plans about using the primitives during the developement of
>>> Squeak 4.1. They also give a nice speed up if you're using SqueakVM, but
>>> some of them (#sin, #cos, etc.) are slower with CogVM.
>>> In Kernel-mtf.527 the behavior of the methods is different if the
>>> receiver is NaN.
>>
>> Yes. NaNs are -as the name says- not numbers and these operations are
>> defined for numbers only, so all the float math plugin primitives fail
>> for NaN. If you want to introduce NaNs silently you could do that in
>> the primitive fallback code, but from my point of view, I found that
>> raising an exception causes potential problems to show at a much
>> earlier stage and not when you're trying to do an operation like
>> truncate, round or whatnot (which sooner or later you will do).
>
> The current implementation defines them as: return NaN if the operand is
> NaN, while the new implementation raises an error. This may break
> existing code, so it should be mentioned in the release notes.

True. We could also have a class var indicating whether to use signaling 
vs. non-signaling NaNs. Virtually no code will care and but if it does 
you can flip the switch for compatibility.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list