|
03:29
nine left,
camelia left
03:30
nine joined
03:31
camelia joined
04:09
apogee_ntv left,
apogee_ntv joined
05:05
shareable6 left
05:06
shareable6 joined
|
|||
| Voldenet | fwiw dotnet has "default" sorting behavior on floats is slightly different from total order, so dotnet has added TotalOrderIeee754Comparer | 09:00 | |
| it is fairly ugly, but doesn't break anything and most people don't really care whether -NaN < NaN | 09:05 | ||
| lizmat | m: dd -NaN | 10:39 | |
| camelia | NaN | ||
| lizmat | hmm | ||
| Voldenet | continuing: intriguing thing about dotnet's NaN is that it's usually -NaN | 11:18 | |
| lizmat | so is -NaN < -Inf true ? | 11:19 | |
| Voldenet | …nope ;> | 11:20 | |
| i'm just throwing in the intriguing bits, but I don't know the rationale behind it | |||
| lizmat | m: dd -NaN == NaN | 11:21 | |
| camelia | Bool::False | ||
| lizmat | m: dd NaN == NaN | ||
| camelia | Bool::False | ||
| lizmat | hmmm | ||
| m: dd -NaN cmp NaN | |||
| camelia | Order::Same | ||
| Voldenet | I'm actually surprised that -NaN on dotnet does nothing, while it works on raku fairly well | 11:35 | |
| `dd -NaN` is a lie | |||
| m: use nqp; my $n = -NaN; my $buf := nqp::list_i(); nqp::writenum($buf, 0, $n, 13); nqp::readuint($buf, 0, 13).base(16).uc.say; | 11:36 | ||
| camelia | FFF8000000000000 | ||
| Voldenet | m: use nqp; my $n = NaN; my $buf := nqp::list_i(); nqp::writenum($buf, 0, $n, 13); nqp::readuint($buf, 0, 13).base(16).uc.say; | ||
| camelia | 7FF8000000000000 | ||
| lizmat | aha! | 11:38 | |
| [Coke] | What do flags of 13 mean? (writenum is in the nqp op docs, but the flags aren't) | 13:13 | |
| lizmat | number of bits | ||
| its not a flag? | 13:14 | ||
| [Coke] | * `writenum(buffer $target, int $offset, num $value, int $flags)` | 13:17 | |
| doc issue? | 13:18 | ||
| lizmat | think so | ||
| japhb | Number of bits and endianness, IIRC | 14:49 | |
| [Coke] | I didn't do the git blame, but it was probably me, and I'm guessing I made the same face when I looked at the source of the code block the last time. :) | 14:59 | |
| dev.azure.com/Raku/nqp/_build/resu...a236382af3 | 18:16 | ||
| lizmat | OOM, right ? | 18:17 | |
| [Coke] | Looks like JVM build is failing with OOM error - can someone open a ticket so we know we have to resolve the CI (and take a look at the build and see how much memory it's using? Did it go up recently or is this a longer standing issue) | ||
| lizmat | And yet another Raku Weekly hits the Net: rakuweekly.blog/2026/10/26/2026-42...iate-raku/ | 18:32 | |