Seems like both NaN <= $x and NaN >= $x should return false for any $x, which makes me think NaN <=> $x should maybe return something undefined?
On Tuesday, April 13, 2010, Geoffrey Broadwell <ge...@broadwell.org> wrote: > 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". > > 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. > > > -'f > > > -- Mark J. Reed <markjr...@gmail.com>
