failing/errors Pharo Tests with CogVM
Locked
12
12
failing/errors Pharo Tests with CogVM
 
|
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 |
Re: failing/errors Pharo Tests with CogVM
|
|
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 <[hidden email]>: > > 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 > > |
Re: failing/errors Pharo Tests with CogVM
|
|
I mean the M7260-primitiveSmallIntegerCompareNan-Patch-nice.1.cs part, the rest has already been applied in COG. Nicolas 2010/9/16 Nicolas Cellier <[hidden email]>: > 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 <[hidden email]>: >> >> 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 >> >> > |
Re: failing/errors Pharo Tests with CogVM
|
|
Well, embarassing, once the "not" bug is eliminated from the .cs of course (successFlag ifTrue: [^self booleanCheat: aBool].) Nicolas 2010/9/16 Nicolas Cellier <[hidden email]>: > I mean the M7260-primitiveSmallIntegerCompareNan-Patch-nice.1.cs part, > the rest has already been applied in COG. > > Nicolas > > 2010/9/16 Nicolas Cellier <[hidden email]>: >> 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 <[hidden email]>: >>> >>> 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 >>> >>> >> > |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Nicolas Cellier
Hi Nicolas, 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.
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 <[hidden email]> wrote:
|
Re: failing/errors Pharo Tests with CogVM
|
|
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 > <[hidden email] > <mailto:[hidden email]>> 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 <[hidden email] > <mailto:[hidden email]>>: > > 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 <[hidden email] > <mailto:[hidden email]>>: > >> > >> 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 > >> > >> > > > > |
Re: failing/errors Pharo Tests with CogVM
|
|
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 <[hidden email]> 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 >> <[hidden email] >> <mailto:[hidden email]>> 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 <[hidden email] >> <mailto:[hidden email]>>: >> > 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 <[hidden email] >> <mailto:[hidden email]>>: >> >> >> >> 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. |
Re: failing/errors Pharo Tests with CogVM
|
|
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<[hidden email]> 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 >>> <[hidden email] >>> <mailto:[hidden email]>> 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<[hidden email] >>> <mailto:[hidden email]>>: >>> > 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<[hidden email] >>> <mailto:[hidden email]>>: >>> >> >>> >> 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 >>> >> >>> >> >>> > >>> >>> >> > > > |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Andreas.Raab
On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> wrote:
We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly.
FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open.
The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode.
best, Eliot
|
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Andreas.Raab
On 16 September 2010 23:55, Andreas Raab <[hidden email]> 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) > 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<[hidden email]> 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 >>>> <[hidden email] >>>> <mailto:[hidden email]>> 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<[hidden email] >>>> <mailto:[hidden email]>>: >>>> > 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<[hidden email] >>>> <mailto:[hidden email]>>: >>>> >> >>>> >> 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. |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Andreas.Raab
Andreas, I realise we need to be more precise. Are you talking about NaNs specifically or NaN and Inf? The Squeak VM happily answers Inf from its float primitives. In fact the only guard against a NaN or Inf result being produced by the floating-point primitives is the guard against dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) isInfinite and there is no failure. So specifically failing for aFloat / 0.0 seems a bit of a fig leaf to me.
So what would your ideal semantics be? a) - fail whenever the result is Inf or NaN? b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf c) - fail whenever the result is NaN but fail aFloat / 0.0
d) - the Interpreter status quo, fail only for aFloat / 0.0 e) - never fail and answer Nan and Inf as specified in IEEE 754 The situation with VW before IEEE was that it did a) and we changed it so that the mode switch selected either a) or e), with, IIRC, the current default being e).
cheers, Eliot
On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> wrote:
|
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Eliot Miranda-2
Of course, as Andreas and Igor, I also prefer a frank exception to creeping NaNs... The main reason for having NaN is compatibility with external world indeed... Some alien code will produce some NaN and we have to deal with it. Nicolas 2010/9/16 Eliot Miranda <[hidden email]>: > > > > On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> 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. > > We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly. > FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open. >> >> 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. > > The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode. > best, > Eliot >> >> 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 >>> <[hidden email] >>> <mailto:[hidden email]>> 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> > 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> >> >>> >> 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 >>> >> >>> >> >>> > >>> >>> > > > |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Eliot Miranda-2
2010/9/16 Eliot Miranda <[hidden email]>: > > Andreas, > I realise we need to be more precise. Are you talking about NaNs specifically or NaN and Inf? The Squeak VM happily answers Inf from its float primitives. In fact the only guard against a NaN or Inf result being produced by the floating-point primitives is the guard against dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) isInfinite and there is no failure. So specifically failing for aFloat / 0.0 seems a bit of a fig leaf to me. > So what would your ideal semantics be? > a) - fail whenever the result is Inf or NaN? > b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf > c) - fail whenever the result is NaN but fail aFloat / 0.0 > d) - the Interpreter status quo, fail only for aFloat / 0.0 > e) - never fail and answer Nan and Inf as specified in IEEE 754 > The situation with VW before IEEE was that it did a) and we changed it so that the mode switch selected either a) or e), with, IIRC, the current default being e). > cheers, > Eliot > Note that IEEE 754 authorize both: - answering an exceptional value - or raising an exception It's all in programmer's hands... (well if they have a good library from within C code, else in assembler). Nicolas > On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> 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 >>> <[hidden email] >>> <mailto:[hidden email]>> 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> > 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 <[hidden email] >>> <mailto:[hidden email]>>: >>> >> >>> >> 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 >>> >> >>> >> >>> > >>> >>> > > > |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Nicolas Cellier
On 17 September 2010 00:44, Nicolas Cellier <[hidden email]> wrote: > > Of course, as Andreas and Igor, I also prefer a frank exception to > creeping NaNs... > > The main reason for having NaN is compatibility with external world indeed... > Some alien code will produce some NaN and we have to deal with it. > If Alien calls interpreterProxy->floatObjectFrom(C float) (forgot exact name) then actually, you have only a single point to decide what to do (and its in VM, not in Alien, or any other plugin which dealing with math). At that point you can easily check that passed float is NaN, and answer some NotANumber object, instead of instance of Float, which contains IEEE NaN > Nicolas > > 2010/9/16 Eliot Miranda <[hidden email]>: >> >> >> >> On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> 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. >> >> We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly. >> FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open. >>> >>> 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. >> >> The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode. >> best, >> Eliot >>> >>> 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 >>>> <[hidden email] >>>> <mailto:[hidden email]>> 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 <[hidden email] >>>> <mailto:[hidden email]>>: >>>> > 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 <[hidden email] >>>> <mailto:[hidden email]>>: >>>> >> >>>> >> 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. |
Re: failing/errors Pharo Tests with CogVM
|
|
2010/9/17 Igor Stasenko <[hidden email]>: > > On 17 September 2010 00:44, Nicolas Cellier > <[hidden email]> wrote: >> >> Of course, as Andreas and Igor, I also prefer a frank exception to >> creeping NaNs... >> >> The main reason for having NaN is compatibility with external world indeed... >> Some alien code will produce some NaN and we have to deal with it. >> > > If Alien calls interpreterProxy->floatObjectFrom(C float) (forgot exact name) > then actually, you have only a single point to decide what to do (and > its in VM, not in Alien, or any > other plugin which dealing with math). > At that point you can easily check that passed float is NaN, and > answer some NotANumber object, instead of instance of Float, > which contains IEEE NaN > In which case you must also inspect substructures, array elements etc... Nicolas >> Nicolas >> >> 2010/9/16 Eliot Miranda <[hidden email]>: >>> >>> >>> >>> On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> 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. >>> >>> We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly. >>> FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open. >>>> >>>> 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. >>> >>> The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode. >>> best, >>> Eliot >>>> >>>> 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 >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> 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 <[hidden email] >>>>> <mailto:[hidden email]>>: >>>>> > 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 <[hidden email] >>>>> <mailto:[hidden email]>>: >>>>> >> >>>>> >> 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. > |
Re: failing/errors Pharo Tests with CogVM
|
|
On 17 September 2010 01:37, Nicolas Cellier <[hidden email]> wrote: > > 2010/9/17 Igor Stasenko <[hidden email]>: >> >> On 17 September 2010 00:44, Nicolas Cellier >> <[hidden email]> wrote: >>> >>> Of course, as Andreas and Igor, I also prefer a frank exception to >>> creeping NaNs... >>> >>> The main reason for having NaN is compatibility with external world indeed... >>> Some alien code will produce some NaN and we have to deal with it. >>> >> >> If Alien calls interpreterProxy->floatObjectFrom(C float) (forgot exact name) >> then actually, you have only a single point to decide what to do (and >> its in VM, not in Alien, or any >> other plugin which dealing with math). >> At that point you can easily check that passed float is NaN, and >> answer some NotANumber object, instead of instance of Float, >> which contains IEEE NaN >> > > In which case you must also inspect substructures, array elements etc... > Yeah, but to fill a FloatArray, you passing floats one by one (or if you want an instance of NotANumber), so again it boils down to a single routine which converts a smalltalk object to C float. In either case, i as always, prefer all 'cleverness' to be inside an image, because we can always change the behavior of NotANumber class to either eat (propagade) all math operations, or throw an exception, based on in-image preference, without altering VM again and again in order to satisfy everyone. > Nicolas > >>> Nicolas >>> >>> 2010/9/16 Eliot Miranda <[hidden email]>: >>>> >>>> >>>> >>>> On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> 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. >>>> >>>> We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly. >>>> FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open. >>>>> >>>>> 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. >>>> >>>> The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode. >>>> best, >>>> Eliot >>>>> >>>>> 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 >>>>>> <[hidden email] >>>>>> <mailto:[hidden email]>> 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 <[hidden email] >>>>>> <mailto:[hidden email]>>: >>>>>> > 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 <[hidden email] >>>>>> <mailto:[hidden email]>>: >>>>>> >> >>>>>> >> 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. >> > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Andreas.Raab
On Friday 17 Sep 2010 1:55:30 am Andreas Raab wrote: > 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. What are the implications of mapping nil <-> NaN at the Object <-> IEEE number boundary? i.e. Both NaN and nil will evaluate as NaN in numeric contexts and nil in other contexts. Subbu |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Eliot Miranda-2
On 9/16/2010 2:44 PM, Eliot Miranda wrote: > I realise we need to be more precise. Are you talking about NaNs > specifically or NaN and Inf? NaN only. +-Inf are fine as they have a well-defined mathematical relationship over the set of numbers. NaN does not. > The Squeak VM happily answers Inf from its > float primitives. In fact the only guard against a NaN or Inf result > being produced by the floating-point primitives is the guard against > dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) > isInfinite and there is no failure. So specifically failing for aFloat > / 0.0 seems a bit of a fig leaf to me. > > So what would your ideal semantics be? > a) - fail whenever the result is Inf or NaN? > b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf > c) - fail whenever the result is NaN but fail aFloat / 0.0 > d) - the Interpreter status quo, fail only for aFloat / 0.0 > e) - never fail and answer Nan and Inf as specified in IEEE 754 > > The situation with VW before IEEE was that it did a) and we changed it > so that the mode switch selected either a) or e), with, IIRC, the > current default being e). f) Fail whenever the result is NaN or when dividing by zero. My preference for f) is that division by zero should be consistent between floating point numbers and integers. It would be strange if "1 / 0" => boom but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't division by zero and may silently result in Inf. In other words: self should:[1.0 / 0.0] raise: ZeroDivide. but (#successor produces the smallest float larger than the receiver) self shouldnt:[1.0 / 0.0 successor] raise: Error. self assert: (1.0 / 0.0 successor) = Float infinity. Cheers, - Andreas |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Nicolas Cellier
On 9/16/2010 2:44 PM, Nicolas Cellier wrote: > Of course, as Andreas and Igor, I also prefer a frank exception to > creeping NaNs... > > The main reason for having NaN is compatibility with external world indeed... > Some alien code will produce some NaN and we have to deal with it. Right. But that's not inconsistent from my perspective. I'm not saying disallow NaN altogether; I'm saying don't allow silently introducing it in arithmetic operations. Thus, if you have external code that produces NaN you can't use that easily to produce further NaN's by means of just arithmetic. BTW, I'd be *really* curious to see what kind of code people would really argue to have propagating NaNs for. It seems we're all violently agreeing that none of us want silent NaN propagation so why exactly are we arguing again? ;-) Cheers, - Andreas > > Nicolas > > 2010/9/16 Eliot Miranda<[hidden email]>: >> >> >> >> On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab<[hidden email]> 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. >> >> We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly. >> FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open. >>> >>> 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. >> >> The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode. >> best, >> Eliot >>> >>> 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 >>>> <[hidden email] >>>> <mailto:[hidden email]>> 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<[hidden email] >>>> <mailto:[hidden email]>>: >>>> > 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<[hidden email] >>>> <mailto:[hidden email]>>: >>>> >> >>>> >> 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 >>>> >> >>>> >> >>>> > >>>> >>>> >> >> >> > |
Re: failing/errors Pharo Tests with CogVM
|
|
In reply to this post by Igor Stasenko
2010/9/17 Igor Stasenko <[hidden email]>: > > On 17 September 2010 01:37, Nicolas Cellier > <[hidden email]> wrote: >> >> 2010/9/17 Igor Stasenko <[hidden email]>: >>> >>> On 17 September 2010 00:44, Nicolas Cellier >>> <[hidden email]> wrote: >>>> >>>> Of course, as Andreas and Igor, I also prefer a frank exception to >>>> creeping NaNs... >>>> >>>> The main reason for having NaN is compatibility with external world indeed... >>>> Some alien code will produce some NaN and we have to deal with it. >>>> >>> >>> If Alien calls interpreterProxy->floatObjectFrom(C float) (forgot exact name) >>> then actually, you have only a single point to decide what to do (and >>> its in VM, not in Alien, or any >>> other plugin which dealing with math). >>> At that point you can easily check that passed float is NaN, and >>> answer some NotANumber object, instead of instance of Float, >>> which contains IEEE NaN >>> >> >> In which case you must also inspect substructures, array elements etc... >> > > Yeah, but to fill a FloatArray, you passing floats one by one (or if you want > an instance of NotANumber), so again it boils down to a single routine which > converts a smalltalk object to C float. > Not necessarily, the image can just pass a pointer to a matrix storage area from one FFI call to another. The conversion to a Smalltalk Float may well be differed far after the computations. > In either case, i as always, prefer all 'cleverness' to be inside an > image, because > we can always change the behavior of NotANumber class to either eat (propagade) > all math operations, or throw an exception, based on in-image preference, > without altering VM again and again in order to satisfy everyone. > I can't really disagree on this. >> Nicolas >> >>>> Nicolas >>>> >>>> 2010/9/16 Eliot Miranda <[hidden email]>: >>>>> >>>>> >>>>> >>>>> On Thu, Sep 16, 2010 at 1:25 PM, Andreas Raab <[hidden email]> 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. >>>>> >>>>> We went through a long series of discussions with customers taking exactly the position you are and finally capitulated because some customers required IEEE behavior. NaNs do all that you say, but for good reason. If they appear in one's calculations then one's calculations are unsafe. NaNs exist anyway; they creep in through the FFI even if the VM refises to produce them. So they're hard to sweep under the carpet. One principled position is to allow them and deal with them correctly. >>>>> FWIW, I'm with you. I would rather the primitives always failed But I've lost that argument against people who knew what they were talking about (I'm no floating point expert). So I like the flag because it keeps people's options open. >>>>>> >>>>>> 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. >>>>> >>>>> The current situation in Cog is certainly wrong. But as discussed above I don't think it's wrong for the VM to introduce them if it is explicitly in such a mode and I know from experience that users want and even need such a mode. >>>>> best, >>>>> Eliot >>>>>> >>>>>> 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 >>>>>>> <[hidden email] >>>>>>> <mailto:[hidden email]>> 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 <[hidden email] >>>>>>> <mailto:[hidden email]>>: >>>>>>> > 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 <[hidden email] >>>>>>> <mailto:[hidden email]>>: >>>>>>> >> >>>>>>> >> 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. >>> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |