On Tue, 2010-04-13 at 05:42 -0700, Ira Byerly wrote:
Note that one test in t/spec/S32-list/sort.t fails...
not ok 4 - array of mixed numbers including Inf/NaN
# got: [-Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf, NaN]
# expected: [NaN, -Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf]
This is due to NaN sorting greater than Inf, rather than less than -Inf.
Since this is consistent with the Rakudo spaceship operator...
$ perl6 -e 'say NaN <=> Inf'
1
... I'm not sure that is appropriate to "fix" it in the code; it might be
better to change the test to match Rakudo's behavoir, or perhaps the test
should accept either >+Inf or <-Inf. The IEEE 754 standard just specifies
that than NaN should be "unordered".
Note that one test in t/spec/S32-list/sort.t fails...
not ok 4 - array of mixed numbers including Inf/NaN
# got: [-Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf, NaN]
# expected: [NaN, -Inf, -61/20, -1e-07, 1/10, 11/10, 2, 42, Inf]
This is due to NaN sorting greater than Inf, rather than less than -Inf.
Since this is consistent with the Rakudo spaceship operator...
$ perl6 -e 'say NaN <=> Inf'
1
... I'm not sure that is appropriate to "fix" it in the code; it might be
better to change the test to match Rakudo's behavoir, or perhaps the test
should accept either >+Inf or <-Inf. The IEEE 754 standard just specifies
that than NaN should be "unordered".
should be implementation-dependent (unless $Larry has declared
otherwise). However, that does not mean you should take NaN out of the
sort testing -- you still want to test that it can be "sorted" against
any other numeric value without invoking HCF (Halt and Catch Fire).
Probably the easiest solution is just to do the sort, check that it
contains a NaN somewhere, then grep the NaN out of the results and
compare the cleaned results against an expected list with no NaN in it.
-'f
