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

Igor Stasenko siguctua at gmail.com
Thu Sep 16 21:23:52 UTC 2010 

On 16 September 2010 23:55, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> 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)
>
yes, and this is exactly what i don't wanna see :)

as for nil's propagation, i meant that you can always assign it to any
variable or
indexed slot, and then discover it quite far away from the assignment
point, when you have to read same slot at some other place
and then you have no idea, where this nil is came from.

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



-- 
Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list