[Vm-dev] failing/errors Pharo Tests with CogVM

Andreas Raab andreas.raab at gmx.de
Thu Sep 16 20:55:53 UTC 2010


On 9/16/2010 1:45 PM, Igor Stasenko wrote:
> NaN is Not a Number,
> so, in first place, for me its a big surprise to see that NaNs
> actually understand the number protocol.
> As for propagation: nils are also propagating to every place you assigning them,
> (along with other userful stuf), so i don't agree that it
> helps/prevents catching mistakes earlier/later
> in code.

nil doesn't propagate. If you try to execute "nil + 4" the result is not 
nil. If you try to execute "(Array new: 10 withAll: 0) + nil" the result 
is not an array containing nils. However, that is exactly the case for NaNs:

	Float nan + 4 => Float nan.
	Float nan * 5.4 => Float nan.
	(FloatArray new: 10) + Float nan
	 => a FloatArray(NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN)

Don't confuse nil and the "message eating null pattern" that some people 
have advocated. The latter *is* propagating in just the same way that 
NaN is, and every bit as wrong :-)

> So, a third way to do things right is: do not fail a primitive(s) but
> answer a sole instance of NotANumber class,
> which are really not a number and don't understands anything from
> Number protocol or conversions (like asFloat/asInteger).

I would very much prefer this approach. And of course, it would be 
trivial to implement that in the fallback code for the failing primitive :-)

Cheers,
   - Andreas

> On 16 September 2010 23:25, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>
>> On 9/16/2010 12:32 PM, Eliot Miranda wrote:
>>>
>>>      I need to check these carefully.  One thing that does differ in
>>> current Cog is that the machine-code arithmetic float primitives don't
>>> fail if they produce a NaN result; they simply answer a NaN result.  IMo
>>> what needs to be done is two-fold.
>>>
>>> a) we need a NaN mode flag in the VM, that persists across snapshots and
>>> e.g. is queryable/settable via vmParameterAt:put:, that puts the
>>> floating-pont primitive into a state where NaNs are answered instead of
>>> primitives failing.
>>
>> FWIW, I don't think we need that flag. Failing the primitive instead of
>> producing something that is specifically declared not to be a number in an
>> arithmetic computation is *always* the right thing to do. The problem with
>> NaNs is that they propagate. So you start with an isolated NaN as the result
>> of a division by an underflow number and may be able to catch it. But you
>> don't because it's silent and then it propagates into a matrix because
>> you're scaling the matrix by that number. Now you've got a matrix full of
>> NaNs. As you push your geometry through that matrix everything becomes
>> complete and utter NaN garbage. And of course, NaNs break reflexivity,
>> symmetry and transitivity of comparisons.
>>
>> As a consequence we should never allow them to be introduced silently by the
>> VM. If the error handling code for some arithmetic primitive decides that
>> against all reasoning you'd like to produce an NaN as the result regardless,
>> that's fine, you have been warned. But having the VM introduce NaNs silently
>> is wrong, wrong, wrong.
>>
>> Cheers,
>>   - Andreas
>>
>>> b) the Cog code generator needs to respect this flag and arrange that
>>> when in the default mode (current behavior) the machine-code arithmetic
>>> float primitives also fail if they produce a NaN result.
>>>
>>> We can then decide at a later date whether to change the primitive
>>> behavior to answer NaNs or not.  This is also what we did in
>>> VisualWorks; there's an IEEE arithmetic mode and in recent releases VW's
>>> floating-point arithmetic will produce NaNs.
>>>
>>> Anyone interested in taking a look at this is very welcome.  Its
>>> probably a week long project at most.
>>>
>>> best,
>>> Eliot
>>>
>>> On Thu, Sep 16, 2010 at 12:19 PM, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com
>>> <mailto:nicolas.cellier.aka.nice at gmail.com>>  wrote:
>>>
>>>
>>>     I mean the M7260-primitiveSmallIntegerCompareNan-Patch-nice.1.cs part,
>>>     the rest has already been applied in COG.
>>>
>>>     Nicolas
>>>
>>>     2010/9/16 Nicolas Cellier<nicolas.cellier.aka.nice at gmail.com
>>>     <mailto:nicolas.cellier.aka.nice at gmail.com>>:
>>>      >  I see http://bugs.squeak.org/view.php?id=7260 was not integrated in
>>>      >  COG, which was the cause of most of the Floating point failures
>>>     in old
>>>      >  VM, but maybe it's now more complex than that ?
>>>      >
>>>      >  Nicolas
>>>      >
>>>      >  2010/9/16 Mariano Martinez Peck<marianopeck at gmail.com
>>>     <mailto:marianopeck at gmail.com>>:
>>>      >>
>>>      >>  Hi Eliot. I took a Pharo 1.1.1 image (which has included the
>>>     changes to run Cog) and I run all the tests with the build  r2219
>>>      >>
>>>      >>  And these are the results:
>>>      >>
>>>      >>  9768 run, 9698 passes, 53 expected failures, 15 failures, 2
>>>     errors, 0 unexpected passes
>>>      >>  Failures:
>>>      >>  FloatTest>>#testRaisedTo
>>>      >>  MCInitializationTest>>#testWorkingCopy
>>>      >>  FloatTest>>#testReciprocal
>>>      >>  ReleaseTest>>#testUndeclared
>>>      >>  FloatTest>>#testDivide
>>>      >>  MethodContextTest>>#testClosureRestart
>>>      >>  FloatTest>>#testCloseTo
>>>      >>  FloatTest>>#testHugeIntegerCloseTo
>>>      >>  FloatTest>>#testInfinityCloseTo
>>>      >>  WeakRegistryTest>>#testFinalization
>>>      >>  PCCByLiteralsTest>>#testSwitchPrimCallOffOn
>>>      >>  AllocationTest>>#testOneGigAllocation
>>>      >>  FloatTest>>#testNaNCompare
>>>      >>  FileStreamTest>>#testPositionPastEndIsAtEnd
>>>      >>  NumberTest>>#testRaisedToIntegerWithFloats
>>>      >>
>>>      >>  Errors:
>>>      >>  MessageTallyTest>>#testSampling1
>>>      >>  WeakSetInspectorTest>>#testSymbolTableM6812
>>>      >>
>>>      >>
>>>      >>
>>>      >>  I think that most of these problems were fixed in latest
>>>     official SqueakVM. I guess they were integrated in VMMaker in
>>>     versions later than the one you used for Cog. Maybe you can
>>>     integrate them and create a new version?
>>>      >>
>>>      >>  I am not a VM expert so please if you can help us with this
>>>     tests it would be cool.
>>>      >>
>>>      >>  Thanks
>>>      >>
>>>      >>  Mariano
>>>      >>
>>>      >>
>>>      >
>>>
>>>
>>
>
>
>


More information about the Vm-dev mailing list