[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