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