This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html
Set by lizmat on 8 June 2022.
00:48 razetime joined 01:09 razetime left 01:10 razetime joined 01:18 explorer left 01:32 deoac joined 01:33 deoac left 01:46 desmond joined
desmond # not sure why I am getting an error 01:48
# "Cannot unbox 64 bit wide bigint into native integer"
use v6.d;
my $bufa = buf8.new(3, 1, 255);
say $bufa;
my $bufb = buf64.new(3, 1, 18446744073709551615);
say $bufb;
01:55 desmond is now known as demondthesecond
_elcaro_ I can load a shared lib via Native call under Linux by specifying it's location, eg. my constant LIB = 'home/foo/bar/here/lib.so'; sub foo is native(LIB) { * } Trying to do the same thing on Windows fails, eg. my constant LIB = 'C:/Users/foo/bar/here/lib.dll'; sub foo is native(LIB) { * } Will fail with Cannot locate native library 'C:/Users/foo/bar/here/lib.dll' error 0x7e despite the fact the library 02:06
exists. Is this a bug?
MasterDuke m: my uint64 $u = 18446744073709551615; say $u; my int64 $s = 18446744073709551615; say $s   # desmond: hm, that feels like a bug. since `constant buf64 = Buf[uint64];` github.com/rakudo/rakudo/blob/main....pm6#L1418 02:59
camelia 18446744073709551615
Cannot unbox 64 bit wide bigint into native integer
in block <unit> at <tmp> line 1
MasterDuke there were dramatic improvements made to support for unsigned natives a little while ago, but i guess there is at least one thing that still needs work 03:01
_elcaro_: i can't say for sure, but i think there might be some weirdness with nativecall and windows. does anything change if you use `\` instead of `/` in the path? and/or put the path literal in the `is native` call instead of creating the constant? 03:03
_elcaro_ No I had tried changing slash direction doesn't change anything. Even tried creating a IO::Path::Win32 and using that. Putting a literal string inside native() doesn't help either. 03:06
MasterDuke m: my constant u64 = uint64; my u64 $u = 18446744073709551615; say $u    # this works fine
camelia 18446744073709551615
MasterDuke _elcaro_: huh. then i'd try pinging nine or ugexe over in #raku or #raku-dev 03:07
does it work if you're in the directory and just give a filename instead of the full path? 03:10
m: my $bufb = buf64.new(3, 1, 18446744073709551615);  # interesting, it's the printing and not the assignment that causes the error 03:12
camelia ( no output )
04:00 razetime left
MasterDuke desmond, demondthesecond: github.com/rakudo/rakudo/issues/5348 04:11
demondthesecond Awesome, thanks! 04:14
Not only for printing by the way: 04:20
use v6.d;
my $bufa = buf8.new(3, 1, 255);
$bufa[3] = $bufa[2] + 1;
say $bufa;
my $bufb = buf64.new(3, 1, 18446744073709551615);
$bufb[3] = $bufb[2] + 1;
#say $bufb;
#same error
oops
I meant: 04:21
use v6.d;
my $bufa = buf8.new(3, 1, 255);
$bufa[2] = $bufa[2] + 1;
say $bufa;
my $bufb = buf64.new(3, 1, 18446744073709551615);
$bufb[2] = $bufb[2] + 1;
MasterDuke interesting. i have a branch of MoarVM that adds a bunch of missing `*_u` versions of ops/functions, but even on that i get the same errors 04:29
anyway, off to sleep
04:44 razetime joined 05:21 habere-et-disper joined 05:34 siavash joined 05:55 habere-et-disper left 07:53 razetime left, razetime joined 08:07 razetime left 08:12 razetime joined, dakkar joined 08:16 tea3po left, tea3po joined 08:20 teatwo joined 08:23 tea3po left 08:38 razetime left 08:57 razetime joined
rcmlz maybe an too academic question: how could I get the computation/memory complexity of build in functions? For example, I did the solution to theweeklychallenge.org/blog/perl-w...lenge-228/ like this sub task2(@input) { my UInt $operations = 0; my @working = @input; for @input.sort -> $element { my $pos = @working.first($element, :k); @working = @working.rotate($pos); 09:24
@working.shift; $operations += $pos + 1; } return $operations; } (find gist here gist.github.com/rcmlz/1a2f20339f20...6624ab958) and are now wondering if my estimation of O(nlog(n) + n*(n + n + n + 1)) <= O(n^2) is corret, estimating the @input.sort as nlog(n) and .first .rotate and .shift als also n and addition as 1. Is the complexity of the build in functions like .first or .rotate or
.shift documented?
09:27 teatwo left 09:28 teatime joined
nemokosch I don't think there is anything like that. If there is, please notify me as well 😛 09:37
rcmlz (if I had to do e.g. .rotate manually it probably would be at least O(n) - there is so much "magic" going on in Raku under the hood, perhaps there is an algorithm for that in log(n) or less that has been implemented by someone ...
nemokosch If you think about it, we don't know the complexity of arithmetic operations or the cost of a function invocation either 09:38
as much as this is a theoretic point, it is also a practical point with regards to Raku because it's not obvious how integer operations are implemented on bigints
lizmat rotate produces a Seq... it will first internally produce the values that are needed at the end, then produce the values of the source until exhausted, then produce the previously saved values 09:39
rcmlz Due to the huge number of CS conepts available in Raku, I beliefe Raku is suitable for learning programming rigerously. However, O-notation is an important part of the academic world ... 09:40
nemokosch I think there is lowkey a conflict of interest here. A mere user is counter-interested in "complexity compatibility", for example 09:41
And so is an implementor, pretty much
rcmlz @lizmat: so my guess of O(n) was correct?
lizmat well, yes and no 09:42
it depends on what it works on 09:43
nemokosch it's rather the complete retrieval/list conversion that will be the O(n) step, as much as I understand
lizmat in the case of a reified list, it's really O(1)
nemokosch and there is no way around that.
lizmat ah, no, duh, O(n) 09:44
rcmlz so my explicit use of arrays makes it slower?
nemokosch like, if you have a mere iterator, there is no other way to make it into a list than to retrieve all the values
by the way, I also have an academic question for you - a question that I asked myself earlier 09:45
do you care about how good your algorithm is, or how efficient the code will actually run? 09:46
if it's the former, then I'd say you shouldn't care about these things
rcmlz yes, the way I implemented it it will not be blow nlog(n) (sorting once), but in case rotor and first and shift are in O(1), then my total solution would be in O(nlogn + n * (1 + 1+ 1+1)) <= O(nlog(n))
nemokosch this solution is akin to one that Bruce Gray showed on the last Raku Study meeting 09:48
it combines two individual optimizations shown there
rcmlz I do not care about how fast the Raku solution is in a real world compared to Rust ;-) It is just for teaching, as it sometimes involves estimating the complexity of an developed solution. 09:49
nemokosch hm, you still have a point with rotor(n) though, that's not such a trivial algorithm in itself 09:50
rcmlz thank you. 09:51
nemokosch for the rest part I'd say you don't have to care too much. There are obviously data structures where popping one element from the front and adding it to the end are cheap
but a data structure where basically indexing and reordering links are both cheap, hm... 09:52
but to be honest, I don't think .first is ever going to be O(1) 09:54
in which case, 1. it doesn't matter that much 2. the rotation step could be in theory baked into the search step and not add much cost 09:55
lizmat rcmlz my solution: gist.github.com/lizmat/d9bbe9ed03f...d64482501a 09:58
perhaps the question about rotate is an entirely different one ? 09:59
rcmlz OK, just wanted to make sure that there is not an obvious way. For instance the Java guys put in the source code of the JRE sometimes the complexity of operations.
lizmat I'm not sure .sort or .rotate are needed for this task 10:00
nemokosch it's better to not add it than to get it wrong, don't you think?
lizmat FWIW, on MoarVM, .shift is implemented really as moving the pointer of the start of the array 10:02
afaik :-) 10:03
rcmlz Variable '$first' is not declared. Did you mean '&first'?
nemokosch it was meant to be $target I think
lizmat yeah, sorry, incomplete renaming for clarity 10:04
rcmlz yes, thank you
lizmat gist fixed
nemokosch the snippet illustrates a point quite well
if first were really O(1), it would be this simple to solve this task in O(n) 🤠 10:05
but realistically this is an O(n^2) solution and I couldn't think of a fundamentally better way 10:06
rcmlz I wanted to avoid multiple min() on the array (assuming O(n) for one min() (thats why the sort) and thought that rotor() is bettern than shifting k times.
nemokosch to be honest, if first was anything below O(n), this would be an easy win
it is probably better than shifting k times on the micro scale 10:07
but you would still need to determine the part to be pushed to the end, I suppose 10:08
rcmlz yes, I meant shifting and appending k times
nemokosch this is why I said that the biggest win I can imagine is to build this whole thing into the search
but then somebody might argue that lizmat's solution is a radical approach on "building the rotation into the search" 😄
lizmat well, the task is about calculating the number of operations, *not* processing values in ascending order 10:09
so I don't see how you could do it any other way than this way ?
nemokosch all these solutions boil down to the same challenge
I had another thing in mind - counting how many times each elements need to be pushed to the end, and then simply summing that 10:10
however, I realized that it requires something that I never managed to solve below O(n^2)...
namely the following task: "given array A, for each index I, calculate the ordered position of A[I] in the sub-array A[1..I]" 10:11
rcmlz shift and first would need to be O(1) 10:12
nemokosch first without a predicate, yes
but first with a predicate is a search
lizmat shift *is* basically O(1) on MoarVM
10:13 razetime left
nemokosch if you are gonna respect the positions instead of building a custom data-structure to aid your search, that's never going to be better than O(n) 10:13
lizmat as it is in most programming languages nowadays, I would say
nemokosch and if you build some custom data-structure 1. you might lose the positions, cf. heap sort 2. you will have to synchronize somehow which is inefficient here 10:14
this is the problem here really. The relative positions need to be maintained - however, if they are, you have to resort to "random access" algorithms... 10:15
Nahita it works on 2021.07 10:19
rcmlz I could not resist: rcmlz: 3 seconds lizmath: 15 seconds gist.github.com/rcmlz/a38bce253c79...3731d2db75 running on my old 2015 Macbook Air on Rakudo™ v2023.04 10:33
nemokosch it's not surprising though
that version is without "the two optimizations" 10:34
"the big two" 😄
rcmlz My conclusion is, that rotate is not to bad compared to manually doing it element by element 10:35
nemokosch sure enough, and also you have precomputed sorting
but I think these are "constant factor" optimizations 10:36
lizmat I wonder of the new ".sort(:k) function would help herev :-) 10:37
nemokosch so at the end of the day, yours still might be O(n^2), a better O(n^2)
rcmlz m: my @input = (^10).pick(*); my $start; say @input; say @input.sort; say @input.sort(:k); 10:44
nemokosch considering a linked list, in one case you only need to traverse the segment to move to determine its end, in the other case you'd need to set and unset all the links inbetween
Raku eval [9 2 8 7 4 5 6 0 1 3] (0 1 2 3 4 5 6 7 8 9) (0 1 2 3 4 5 6 7 8 9)
lizmat m: m: my @input = (^10).pick(*); my $start; say @input; say @input.sort; say @input.sort(:k); 10:45
camelia [8 4 0 2 9 3 5 7 1 6]
(0 1 2 3 4 5 6 7 8 9)
(2 8 3 5 1 6 9 7 0 4)
_elcaro_ I thought that might be the case. Thanks for confirming.
lizmat I think the eval bot on discord is not up-to-date
nemokosch it's a 2022.02 iirc
opened an issue for a Nix bump on glot-images a couple of days ago
lizmat yeah, the .sort(:k) isn't in a release yet, it will be in 2023.08 10:46
rcmlz I have the "feeling" taht with .sort(:k) and some "mod array.elems" you can calculate the operations in O(n) 10:48
lizmat yeah, that was my feeling as well :-) that's why I mentioned it 10:49
nemokosch well, I already said where I've gotten with this thought
not saying that somebody else can't get further but still
the useful number didn't seem to be the position of A[I] in A but the position of A[I] in A[I..LAST] 10:50
rcmlz I procrastinated enough for today ...
nemokosch which is yucky to compute for each I 10:51
rcmlz perhaps I think about it when .sort(:k) is available
smells like DP ... 10:52
nemokosch expanding forward?
hm, well, it's worth a thought
not sure how big the "cache" will have to be 10:53
rcmlz something like: postion of an element x after rotating smalles element x' = (positionof x' before rotating + positionof x before rotating - 1) mod number of elements in array 10:55
but did not think that through, so perhaps all garbage 10:56
10:57 SmokeMachine_ joined, mjgardner_ joined
nemokosch thinking about it, what I said is also faulty, besides being pretty complex 11:01
1, 3, 2 and 3, 1, 2 are different wrt the last element
or are they, damn 💀 11:02
11:05 SmokeMachine left, mjgardner left, SmokeMachine_ is now known as SmokeMachine, mjgardner_ is now known as mjgardner 12:03 siavash left
rcmlz Maybe you can help me on the O(n log n) solution. Asusming I have this .sort(:k) in nlog n, how would I get a hash %order-and-position from that orders, basically doing: @input = [3, 4, 2] @orders = @input.sort(:k) = [1, 2, 0] %order-and-position = 0 => 2, 1 =>0, 2=>1; 12:04
12:20 jgaz left 12:21 jgaz joined
Found it m: my @input = [3, 4, 2]; my @orders = [1, 2, 0]; #@input.sort(:k) = my @positions = ^(@orders.elems); my %order-and-position; %order-and-position{||@positions} = @orders; say @input; say @orders; say %order-and-position; 12:23
found it - I guess having %order-and-position a DP solution calculating the number of operations in O(n) is possible 12:24
nemokosch won't ||@orders nest too much? 12:27
rcmlz m: my @input = [3, 4, 2]; my @rank = [1, 2, 0]; #@input.sort(:k) = my @positions = ^(@input.elems); my %rank-and-position; %rank-and-position{||@rank} = @positions; say @input; say @rank; say %rank-and-position; 12:28
Raku eval [3 4 2] [1 2 0] {0 => 2, 1 => 0, 2 => 1}
rcmlz stackoverflow.com/questions/727036...mple-array told me this solution 12:29
nemokosch but you don't seem to want the nesting
rcmlz no, but it works ;-)
nemokosch neither seems the output to be nested 12:30
|@rank is enough for sure
rcmlz True - I do not understand the difference (yet)
nemokosch it's the difference between @a[1], @a[2], @a[3] and @a1[3] basically 12:31
||@rank has the special meaning in language version e which is not yet the default so this time around it really turned into |@rank... 12:32
m: my @rank = [1, 2, 0]; my %rank-and-position = @rank Z=> (0..*); dd %rank-and-position 12:34
Raku eval Hash %rank-and-position = {"0" => 2, "1" => 0, "2" => 1}
nemokosch is it "nice enough" or "too clever"?
or neither, of course 😄
rcmlz nice and clever 13:22
dakkar m: @rank = [1, 2, 0]; my %rank-and-position=@rank.kv.reverse; dd %rank-and-position 13:46
camelia ===SORRY!=== Error while compiling <tmp>
Variable '@rank' is not declared. Did you mean '&rand'?
at <tmp>:1
------> <BOL>⏏@rank = [1, 2, 0]; my %rank-and-position
dakkar m: my @rank = [1, 2, 0]; my %rank-and-position=@rank.kv.reverse; dd %rank-and-position
camelia Hash %rank-and-position = {"0" => 2, "1" => 0, "2" => 1}
dakkar same thing, but using `.kv` ("give me a list of key-value pairs") instead of the `Z=>` ("zip these two lists and make pairs") 13:47
m: my @rank = (7, 3, 5); my %rank-and-position=@rank.kv.reverse; dd %rank-and-position
camelia Hash %rank-and-position = {"3" => 1, "5" => 2, "7" => 0}
dakkar (slightly clearer with different values)
nemokosch if only there was a .vk 😂
dakkar that's what the `.reverse` is for 😜 13:48
m: my @rank = (7, 3, 5); my %rank-and-position=@rank.pairs».antipair; dd %rank-and-position 13:50
camelia Hash %rank-and-position = {"3" => 1, "5" => 2, "7" => 0}
dakkar if you want to make it clearer that we're dealing with pairs
Nahita you have @rank.antipairs directly if you want 13:54
nemokosch that's probably the most concise solution 13:57
rcmlz @rank.antipairs - thank you, all build in ;-) 13:59
dakkar oh, TIL! 14:06
rcmlz As soon as I have .sort(:k) available, I can test my O(n) solution for w228 14:09
m: sub task2_in_O_of_n(@input) { my @rank = @input; #@input.sort(:k); my %rank-and-position = @rank.antipairs; my $n = @rank.elems; my $shifting_left_previous = %rank-and-position<0>; my $shifting_left_total = $shifting_left_previous; for 1...^$n -> $rank { my $pos-initial = %rank-and-position{$rank}; my $pos-previous = (($pos-initial - $shifting_left_previous) mod ($n - $rank
+ 1) - $rank); my $pos-current = $pos-previous mod ($n - $rank); $shifting_left_previous = $pos-current; $shifting_left_total += $shifting_left_previous; } return $shifting_left_total + @input.elems; }
Raku eval
nemokosch O(n) surely not, if you have a comparing sort 14:10
rcmlz O(n log n) of course ... sorry 14:11
unless someone can run this for me: gist.github.com/rcmlz/a38bce253c79...3731d2db75 14:12
realvoidzero I'm trying zef install rakudoc with nixos but am getting the following error a bunch of times: Merging GLOBAL symbols failed: duplicate definition of symbol Fast This happens under: ===> Testing: JSON::Marshal:ver<0.0.25>:auth<zef:jonathanstowe>:api<1.0> If anyone knows what to do... ta
MasterDuke rcmlz: 2230460␤0␤2230460␤6␤2214235␤0 14:13
rcmlz ok, faster - but wrong LOL 14:14
nemokosch 😅
MasterDuke realvoidzero: i'm not 100% sure rakudoc is working right now
rcmlz bloody DP ... ;-)
MasterDuke might want to ask in #raku-doc
nemokosch I could install it
MasterDuke oh? good 14:15
realvoidzero Nemokosch, with zef? 14:16
nemokosch yep
I don't know of other common choices, to be honest
realvoidzero Ok. This might be a local issue. I'm not sure how well raku and zef are supported in the nixos environment
MasterDuke what version of rakudo do you have? 14:17
yeah, rakudoc just installed for me too
realvoidzero v2023.04
nemokosch could you run and take the output of this: zef install --dry --verbose rakudoc ? 14:18
realvoidzero Sure. One sec. 14:19
MasterDuke rcmlz: btw, gist.github.com/rcmlz/a38bce253c79...t-raku-L34 would be faster as a range, i.e., `for 1..^$n -> $rank {` (note the two periods instead of three) 14:21
but it would have different semantics 14:22
m: .say for 1..0
camelia ( no output )
MasterDuke m: .say for 1...0
camelia 1
0
MasterDuke so depends on what you want to have happen if $n == 0
m: .say for 1...^0 14:23
camelia 1
MasterDuke m: .say for 1..^0
camelia ( no output )
realvoidzero ok: gist.github.com/voidzero/d013842ae...c2ed4569ce
nemokosch JSON::Fast has decent testing... 14:24
okay, JSON::Marshal is suspicious 14:26
I have an earlier version installed
MasterDuke: what version do you have?
hm, apparently some people had it even with 0.0.24 github.com/jonathanstowe/JSON-Marshal/issues/13 right back at you... 14:27
yeah it's not the version, for me 0.0.25 also installs fine 14:28
realvoidzero Ok, that's odd then. I can try the latest comment - install deps first 14:29
nemokosch in any case, could you leave a comment there, with some notes on your environment and Rakudo version? 14:31
rcmlz I would need "1..^$n"
changed my code - will debug the algorithm when I have Raku that has .sort(:k)
realvoidzero @nemokosch yep will do
nemokosch thanks 14:32
realvoidzero Thank you for the pointers! 14:35
nemokosch yeah well, hopefully you can install it at the end of the day ^^
realvoidzero I just managed and created a comment detailing how to. (I had to do the same thing with another dep) 14:41
nemokosch oh that's great 14:43
demondthesecond Do you think the fix implemented (github.com/rakudo/rakudo/commit/43...435324c78) for the first part of the issue (github.com/rakudo/rakudo/issues/53...852473007) will resolve the second part of the issue (github.com/rakudo/rakudo/issues/53...680605291) 15:48
nemokosch you might have more luck at #raku-dev with this question 15:51
#raku-dev, in case discord did something nasty to the channel name 15:52
lizmat demondthesecond the second part is a different issue
16:06 deoac joined
realvoidzero > log 1000, 10; # 2.9999999999999996 should I use round( ) here to get 3? 16:07
demondthesecond Thanks, should I open a new issue for that case?
lizmat demondthesecond: yes please 16:10
16:22 NemokoschKiwi joined 16:33 ab5tract joined
demondthesecond Thank you, done. github.com/rakudo/rakudo/issues/5349 16:33
antononcube @realvoidzero Good question! See the discussion here: stackoverflow.com/q/47542915/14163984 . 16:36
16:37 dakkar left 16:38 razetime joined
I guess... I do not see a better option -- for example, same result is obtained with 1000.Rat.log10.narrow . 16:40
realvoidzero Ah yes indeed. Thank you for the link 16:44
17:09 razetime left 17:25 ab5tract left 18:33 ab5tract joined 19:29 ab5tract left
Nahita inaccurateness is due to floating point business allright, and, e.g., Python and Perl has the same "issue" as well. But CPython also offers a math.log10 function, which is a thin wrapper around C's log10 from libm, and it gives 3.0 as expected 19:46
Perl doesn't offer a specific log10 but probably (certainly) there are some module(s) in CPAN to address this
Raku, on the other hand, does offer a log10 built-in function; however it somewhat unfortunately defers to log($_) / log(10), and we see the same (slightly) inaccurate result with it as well 19:47
m: say log(1000, 10), "\n", log10(1000) 19:48
Raku eval 2.9999999999999996 2.9999999999999996
Nahita if only it reached out the C's log10, we can get our 3.0
m: use NativeCall; sub log10(num64 --> num64) is native({ $*DISTRO.is-win ?? "msvcrt.dll" !! "" }) {*} say log10(1000.Num);
Raku eval 3
19:52 NemokoschKiwi left 19:59 deoac left 20:15 teatime left, teatime joined
librasteve nahita: that’s a good idea … maybe you should post as a feature request issue on github rakudo/rakudo 20:19
having said that i think it’s a bit weird that Cs log10 unless it uses something like bcd under the hood since the numbers i use on my machine are binary … and the point of Rats in raku is to handle rationals not irrationals where continuous functions are at play and i would oppose a request to replace raku Rats with bcd (or some other special handling of decimals) 20:23
according to this www.tutorialspoint.com/c_standard_..._log10.htm we have double log10(double x) if true then (i) i don’t get how Cs log10 is different to raku s and (ii) you are probably just lucky with 3 (or have some default rounding mode set in a better way on your FPU) 20:27
fwiw i would support some kind of (settable) default Num rounding at the last decimal place to improve this … but this goes into areas where eg CPU/FPU architectures are different depending on your platform so non trivial to do at the language level afaik 20:31
gfldex m: dd nqp::div_n(nqp::log_n(1000e0), nqp::log_n(10e0)); 20:36
camelia ===SORRY!=== Error while compiling <tmp>
Could not find nqp::log_n, did you forget 'use nqp;' ?
at <tmp>:1
------> dd nqp::div_n(nqp::log_n(1000e0)⏏, nqp::log_n(10e0));
gfldex m: use nqp; dd nqp::div_n(nqp::log_n(1000e0), nqp::log_n(10e0));
camelia 2.9999999999999996e0
gfldex @librasteve this ^^^ is what Rakudo does. Rakudo: „NQP, your problem please!“. 20:37
Given MoarVM, we end up here: github.com/MoarVM/MoarVM/blob/75fe...erp.c#L967 20:42
Nahita > if true then (i) i don’t get how Cs log10 is different to raku s Raku(do) computes log10($x) as log($x) / log(10) which loses accuracy compared to a specific log10 implementation, e.g., here www.netlib.org/fdlibm/e_log10.c 21:14
if you printf("%.16f", log(1000) / log(10)) in C, you'd get 2.99999 stuff as well. But log10(1000) is 3
i don't think nor know a NativeCall based solution to this would be acceptable in Rakudo, i guess first MoarVM considers a route for log10, then nqp gets nqp::log10_n andthen Rakudo calls that, is a better solution 21:17
gfldex You need to add the OPs for MoarVM and JVM. 21:18
librasteve per @Nahita link to netlib... 21:30
* Note 1: * To guarantee log10(10**n)=n, where 10**n is normal, the rounding * mode must set to Round-to-Nearest.
^^^ this is what I just said 21:31
sooo - maybe we need to control the rounding mode on the IEEE754 FPU
i have tried this on python and they get it right (ie the way of C) so I think we should at least register this as an issue - please can you share the link back here so that we can chip in? 21:48
gist.github.com/librasteve/fc2999c...7abf554524 21:49
just writing up new issue here github.com/MoarVM/MoarVM/issues/1765 22:00

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!