|
00:18
kjp left
00:33
kjp joined
00:42
kjp left
00:58
kjp joined
|
|||
| lizmat | so nqp::cmp_n has slightly different semantics to infix:<cmp>(Num,Num) | 14:27 | |
| the latter places NaN as higher than any Num value, the former assumes NaN is the same as any num value | |||
| the fix: nqp::cmp_n($a,$b) || nqp::iseq_s($a,"NaN") - nqp::iseq_s($b,"NaN") | 14:28 | ||
| I wonder how difficult it would be to incorporate this into the nqp::cmp_n op at the MoarVM level | |||
| feels like it should just be a few extra lines in interp.c at line 851 | 14:30 | ||
| (and possibly some JIT changes?) | 14:31 | ||
| japhb | NaN should *not* be higher (or lower) than any Num. In particular, it is *not comparable* in the mathematical sense, and in the IEEE sense it should return false for any comparison. | 18:47 | |
| So the current cmp implementation is incorrect if it claims NaN is More than anything else. | 18:48 | ||
| lizmat | There's a spectest expecting NaN,-Inf,Inf to sort as -Inf,Inf,NaN | ||
| m: dd (NaN,Inf,-Inf).sort | 18:49 | ||
| camelia | (-Inf, Inf, NaN).Seq | ||
| lizmat | so how should that be sorted ? | 18:50 | |
| [Coke] | I think expecting NaN to sort a certain way is probably wrong unless that's part of a standard. | 19:16 | |
| (I think making sure at least the two Inf's are sorted correctly is correct, of course) | |||
| ShimmerFairy | Unless the IEEE standard says something about it, for sorting purposes you need NaN to come out True for *something*, or else the sorting algorithm can't end (right?). But since infix:<cmp> is more general than sorting, that's not the right place to add any special sorting behavior. | 19:19 | |
| lizmat | m: dd NaN cmp Inf | 19:21 | |
| camelia | Order::More | ||
| lizmat | that's the underlying reason for the behaviour fwiw | ||
| ShimmerFairy | After a bit of digging, IEEE-754 apparently defines a totalOrder() operation that's exactly what you'd want for sorting floats: en.wikipedia.org/wiki/IEEE_754#Tot..._predicate | 19:29 | |
| So infix:<cmp> for Nums ought to be changed (as much as possible) to match that, since our cmp isn't designed to signal unordered results. | 19:30 | ||
| [Coke] | +1 | 19:31 | |
| lizmat | so that's basically what the HLL cmp does | 19:38 | |
| japhb | That's ... rather odd. I mean, I get why they went there, but I was not expecting this. I sit corrected. | 21:16 | |
| Turns out my knowledge there was just out of date. | 21:21 | ||
| Normally at this point I would go read the spec changelogs, but ... I'm a bit busy at the moment for that. | 21:22 | ||