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'

... 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".
In that case, the spec test should not care where the NaN sorts -- it
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.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 4 | next ›
Discussion Overview
groupperl6-compiler @
postedApr 13, '10 at 12:43p
activeApr 13, '10 at 9:56p



site design / logo © 2021 Grokbase