|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:25
sivoais left
00:26
sivoais joined
01:28
Kaiepi joined
02:53
lucasb left
|
|||
| nwc10 | good *, #moarvm | 07:14 | |
|
07:30
MasterDuke left
07:47
domidumont joined
09:05
sena_kun joined
09:15
zakharyas joined
|
|||
| jnthn | morning o/ | 10:17 | |
| nwc10 | \o | 10:21 | |
| tib | hello :) | 10:29 | |
| I opened a third issue (still related to perfs) on MoarVM repo (sorry xD). I discussed them mainly on #raku room | 10:31 | ||
| jnthn | Yeah, I've a good idea about what's going on with 2 of them | 10:32 | |
| tib | oh, great | ||
| jnthn | Will comment on them in a bit. | 10:33 | |
| nwc10 | but first more coffee? | ||
| jnthn | Fetched the coffee already; still trying to figure out if there's a cute general solution to fix a shortcoming in the abstract interpretation I'm working on at $dayjob project, or if I should just hack the code-gen to get a friendlier branch structure... :) | 10:36 | |
| dogbert17 | jnthn: are you in lockdown or has things calmed down in Prague? | 10:43 | |
| jnthn | Both, I guess | 10:53 | |
| New infections started coming down over the last couple of weeks. Numbers in hospital lag that, but now also seem to be falling. But they're both still high enough that there's not grounds for much loosening of restrictions yet. | 10:55 | ||
| Wouldn't be surprised if I'm working from home 100% for the rest of 2020. | 10:56 | ||
|
11:14
squashable6 left
|
|||
| dogbert17 | Yeah, have been working from home since March and will probably have to continue doing that. Europe is in a lot of trouble atm. | 11:14 | |
|
11:14
squashable6 joined
|
|||
| nwc10 | I've been into the office for one (er, half) a day, because we were all asked to ensure that we'd unpacked our moving boxes. | 11:15 | |
| moritz | I guess I'll work from home until there's a vaccine deployed widely | 11:27 | |
|
12:02
zakharyas left
12:10
Altai-man joined
12:12
sena_kun left
12:41
xiaomiao is now known as DrEeevil
|
|||
| timotimo | same | 13:16 | |
| nine | I'll probably only be able to enjoy working from home 100 % for a couple more weeks. Could live with a lot more ;) | 13:20 | |
| Geth | MoarVM/bigint_div_num-IEEE-rounding: 3ee36c5fd7 | (Nicholas Clark)++ | src/math/bigintops.c Minimally exact bigint/bigint => num conversion, including rounding. Given that Rakudo parses decimal constants such as 0.01 as `Rat`s (ie represents them internally as (1 / 100), and persists with this exact representation as long as possible), this effectively makes the operator that converts `Rat`s to `Num`s Rakudo's decimal => binary floating point conversion. ... (36 more lines) |
13:32 | |
| MoarVM: nwc10++ created pull request #1384: Minimally exact bigint/bigint => num conversion, including rounding. |
13:33 | ||
| nwc10 | That's a draft. The commit message might change. | ||
| and, disclaimer, there's really nothing in there about big integers. It's alo about IEEE floating point and corner case rounding. | 13:36 | ||
|
14:22
zakharyas joined
14:26
zakharyas left
14:31
zakharyas joined
16:03
patrickb joined
16:11
sena_kun joined
16:12
Altai-man left
16:36
sena_kun left,
sena_kun joined
18:09
patrickb left
18:17
domidumont left
18:51
zakharyas left
20:06
MasterDuke joined
|
|||
| MasterDuke | nwc10: nice. however, MVM_mp_get_double_shift was the most difficult part of the tommath->gmp conversion, and now i'll have to redo it... | 20:09 | |
| though i still haven't had any response from my email to their mailing list | |||
|
20:10
Altai-man joined
20:12
sena_kun left
|
|||
| nwc10 | I'm staring at its output currently | 20:14 | |
| it's fundamentally broken | |||
| you cant' converted integers to doubles that way. | |||
| no, I didn't know this a few days ago | 20:15 | ||
| MasterDuke | the existing MVM_mp_get_double_shift is broken? or my gmp conversion of it? or your PR? | 20:19 | |
| nwc10 | the existing approach | 20:20 | |
| MasterDuke | ah | ||
| nwc10 | in the general case, you can't add rounded values and have then round again and *always* get the same answer (or the correct answer) | ||
| and the really daft bit is that doubles only have 53 bits of mantissa | 20:21 | ||
| so on a 64 bit system, libtomath is using 60 bits for each big "digit" | |||
| so every time it converts one of its digits to a double there is rounding, if it's above 2**53 | |||
| I'm maybe not explaining this that well | 20:22 | ||
| but I know that the code we have generates different answers for Num(0.777777777777777777771) on 32 and 64 bit platforms | |||
| and at least one is wrong :-) | |||
| which really should be :-( | 20:23 | ||
| and it's all going wrong in MVM_mp_get_double_shift | |||
| MasterDuke | ha. well, a quick glance at your PR didn't throw any red flags as far as difficult to convert to gmp. so assuming it's (more) correct, that's all good | ||
| nwc10 | OK, after an huor of staring at bit patterns (integers and floating point %a notation) I think that I get the specific problem. 0xe vs (0x8 | 0x6) | 21:03 | |
| the former will round up | |||
| OK, if the former ends up as the last part of the conversion to double, at the correction "roation", it rounds up | 21:04 | ||
| whereas 0x8 can end up rounding to even | |||
| and then 0x6, when merged in at the next loop, rounds down. | 21:05 | ||
| no, actually it's 1C arriving together, vs 1 being the last digit added on one iteration of the loop (and being lost due to truncation) and then C arriving on the next iteration (ie 0b1100) but that 0b1000 not finding the 1 bit to the "left" to round up | 21:26 | ||
|
21:47
MasterDuke left
22:01
patrickb joined
23:02
Altai-man left
23:17
patrickb left
23:56
patrickb joined
23:57
patrickb left
|
|||