[Vm-dev] Float math in VMMaker-dtl.123

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Jul 2 17:56:22 UTC 2009


2009/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
>
>  Hi Bert,  All,
>     Hold on!
>
> On Wed, Jul 1, 2009 at 11:52 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>>
>> On 01.07.2009, at 19:02, Nicolas Cellier wrote:
>>
>>>
>>> 2009/7/1 David T. Lewis <lewis at mail.msen.com>:
>>>>
>>>> On Wed, Jul 01, 2009 at 08:32:18AM -0700, Andreas Raab wrote:
>>>>>
>>>>> Ouch. Yeah, I'd say that's right...
>>>>
>>>> This is from http://bugs.squeak.org/view.php?id=7260. I reopened the
>>>> issue on Mantis.
>>>>
>>>> I'll apply the fix to VMMaker as soon as I can (but feel free to do the
>>>> update if I don't get to it first; Bert you have developer access as well
>>>> as Andreas of course).
>>>>
>>>> Dave
>>>>
>>>
>>> Ouch again, my fault.
>>> How can the tests pass... Hmm not enough test?
>>
>>
>> the failure would only be triggered for code like
>>
>> 0.1 <= 0.2 ifTrue: [...]
>>
>> but not for
>>
>> self assert: 0.1 <= 0.2
>
> That's not my reading of booleanCheat:.  booleanCheat: takes a C boolean argument cond.  If the following bytecodes are those of a conditional branch then it either takes or skips those bytecodes based on the value of cond, otherwise it reifies cond as either true or false.  i.e. the jump and reification behaviours match (duh!).  So I think it *does* show up in both
>     0.1 <= 0.2 ifTrue: [...]
> and
>     self assert: 0.1 <= 0.2
> Further, the comment I have in my versions is I think correct:
> bytecodePrimGreaterOrEqual
> | rcvr arg aBool |
> rcvr := self internalStackValue: 1.
> arg := self internalStackValue: 0.
> (self areIntegers: rcvr and: arg) ifTrue:
> ["The C code can avoid detagging since tagged integers are still signed.
> But this means the simulator must override to do detagging."
> self cCode: '' inSmalltalk: [^self booleanCheat: (self integerValueOf: rcvr) >= (self integerValueOf: arg)].
> ^self booleanCheat: rcvr >= arg].
> successFlag := true.
>>> "Invert test so that NaN comparisons work correctly."
> aBool := self primitiveFloatLess: rcvr thanArg: arg.
> successFlag ifTrue: [^self booleanCheat: aBool not]
> Because
>     | aNaN | aNaN := Float nan.  nan >= nan
> must be false (since nan ~= nan) and because
>     | aNaN | aNaN := Float nan.  nan < nan

No, using < <= > >= = (C ==) with a NaN operand left or right (or
both) will always lead to false as result.
Rationale: NaN is not a number and cannot be ordered.
~= with a NaN operand will always be true.

> is true (because that's what the IEEE spec says (Nicholas can you confirm?)) then the inversion is correct, as with the inversion
>     | aNaN | aNaN := Float nan.  nan >= nan
> is false, which is correct, isn't it?  (might be, might not be, but IANAIEEE754L)
> So before we thrash breaking what looked a few weeks ago to be the right fix can we please write the relevant tests.  I nominate Nicholas as he wrote the bug fixes and revamped the tests we have in the first place.

That's fair.
I'll have a look this week end.

Nicolas

>>
>>
>>
>> - Bert -
>>
>>
>
>
>


More information about the Vm-dev mailing list