FloatMathPlugin in Squeak for Croquet compatability?

> Croquet (and thus Open Cobalt) requires that squeak images
> perform floating point operations bit-identically across
> machines, and the FloatMathPlugin was added to the VM to ensure
> this is the case.
>
> Now that OpenCobalt is nearly ready for debut onto the Squeak
> trunk, I'm wondering if this should be enabled by default in
> squeak images. FloatMathPlugin is included in standard VMs, but
> is not used by non-Croquet images. I'm wondering if we should
> change that.
>
> I uploaded the code and test case for this feature at:
>
> http://bugs.squeak.org/view.php?id=7583

> On Mon, 13 Dec 2010, Matthew Fulmer wrote:
>
>> Croquet (and thus Open Cobalt) requires that squeak images
>> perform floating point operations bit-identically across
>> machines, and the FloatMathPlugin was added to the VM to ensure
>> this is the case.
>>
>> Now that OpenCobalt is nearly ready for debut onto the Squeak
>> trunk, I'm wondering if this should be enabled by default in
>> squeak images. FloatMathPlugin is included in standard VMs, but
>> is not used by non-Croquet images. I'm wondering if we should
>> change that.
>>
>> I uploaded the code and test case for this feature at:
>>
>> http://bugs.squeak.org/view.php?id=7583
>
> 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.
>
>
> Levente
>
>>
>> --
>> Matthew Fulmer (a.k.a. Tapple)
>>
>>
>
>

> 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).

> 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.

> On Tue, Dec 14, 2010 at 12:17:14AM -0800, Andreas Raab wrote:
>> On 12/13/2010 9:07 PM, Andreas Raab wrote:
>>> 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.
>>
>> I've posted a version of this into the inbox for people to look at. I
>> think it's actually a quite reasonable tradeoff; let me know what you think.
>
> I noticed you deleted the infinity check for cos but not for
> sin.