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

Igor Stasenko siguctua at gmail.com
Thu Sep 16 20:45:32 UTC 2010


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.

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


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