🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:07 reportable6 left 00:09 reportable6 joined 00:56 frost joined 01:19 frost left 01:59 frost joined 02:05 frost left 02:24 frost joined 02:30 frost left 02:43 frost joined 03:12 discord-raku-bot left, discord-raku-bot joined 03:16 frost left 03:21 frost joined 03:41 frost left 03:51 frost joined 03:56 frost left 06:07 reportable6 left 06:19 frost joined 07:10 reportable6 joined 07:38 frost left 07:47 frost joined 07:53 frost left
nine Ooooh....now I know where the spectest failures on my laptop are coming from. I've got 6.d-errata checked out 08:46
Geth rakudo/fix_unsigned_for_merge: 6 commits pushed by (Stefan Seifert)++ 09:02
10:13 linkable6 left, evalable6 left 10:16 evalable6 joined 10:27 frost joined 10:32 frost left 10:42 frost joined 10:55 frost left 11:02 frost joined 11:26 frost left 11:47 frost joined 11:51 frost left 12:07 reportable6 left 12:14 linkable6 joined 13:07 frost joined 13:33 carlmasak joined 13:41 frost left
lizmat m: dd 0.8144262510988963255087469.nude # what's wrong with this picture ? 14:08
camelia (8144262510988963255087469, 10000000000000000000000000)
lizmat m: dd 0.8144262510988963255087469.^name
camelia "Rat"
lizmat both values *exceed* the size of 64 native ints
14:10 reportable6 joined
lizmat but we're ok with that, as Rats currently are created with Int attributes, rather than with 'int" attributes 14:12
moon-child inb4 rat (with a lowercase r) 14:14
codesections lizmat that's all correct (at least according to the current docs)
lizmat m: dd Rat.new(8144262510988963255087469,10000000000000000000000000).nude # the real issue
camelia (8144262510988963255087469, 10000000000000000000000000)
lizmat that should either have become a Num or a FatRat, or warn or die 14:15
basically, we don't check for upgrading on creation of a Rat
and perhaps we should ?
moon-child ah, yeah, because:
codesections The docs *explicitly* allow for that, though: "When constructing a Rat (i.e. when it is not a result of some mathematical expression), however, a larger denominator can be used" 14:16
moon-child m: my $x = Rat.new(8144262510988963255087469,10000000000000000000000000); say WHAT $x; say WHAT 1*$x;
camelia (Rat)
(Num)
moon-child seems odd
codesections and give my $c = Rat.new(1, 2⁶⁴); as an example
lizmat seems to me the docs are describing current behaviour rather than desired behaviour
if Rats had been created with native ints, this would not have worked 14:17
codesections Well, in general the docs don't (intentionally) describe bugs – so the author of that section (Zoffix, I think?) thought it was desired 14:18
moon-child S02-types/num.t: ‘Rat supports extended precision rational arithmetic’ 14:19
14:19 carlmasak left
nine Or just didn't know any better 14:19
codesections Hmm, that section of the docs previously read: 14:22
> When I<constructing> a L<Rat> (i.e. when it is not
a result of some mathematical expression), however, a "fattish" L<Rat> with
larger denominator will be created.
github.com/Raku/doc/blame/6c9a97c2...erics.pod6 14:23
(not sure what a "fattish" Rat is :D )
MasterDuke we used to have Texas operators, we could have NYC rats... 14:25
moon-child haha
lizmat well, the "fattish" Rat is a Rat with out of range numerator / denominator values
that *would* be ok in a FatRat
codesections MasterDuke: no thanks! nude FatRats are frightening enough 14:26
lizmat of course, if we would silently upgrade to FatRat or downgrade to Num, this would fail: 14:27
m: my Rat $a = 0.8144262510988963255087469
camelia ( no output )
lizmat m: say Num ~~ Rat; say FatRat ~~ Rat 14:28
camelia False
False
codesections lizmat yeah. And that change was based on a Rat normalization grant, so it presumably _was_ intentional 4 years ago. (Which isn't to say it's correct, just probably not an accident)
moon-child m: say Rat ~~ FatRat 14:29
camelia False
lizmat if we leave things as they are, then I think that
0.8144262510988963255087469 would need a compile time worry
14:48 MasterDuke left
lizmat afk for a few hours& 14:50
14:52 qorg11 left 14:53 qorg11 joined 15:06 carlmasak joined, MasterDuke joined 15:16 carlmasak left 15:36 carlmasak joined, carlmasak left 16:31 kjp left 16:34 kjp joined
codesections .tell lizmat it looks like the `Rat` initialization is intentional (with the goal of letting users have a Rat that can be used with full precision with FatRats but isn't infectious). See news.perlfoundation.org/post/grant...6_bugfixin (describing a `MidRat` to provide this functionality) and 17:24
blogs.perl.org/users/zoffix_znet/20...-2018.html (deciding to fold that into `Rat` instead of adding `MidRat`)
tellable6 codesections, I'll pass your message to lizmat
lizmat codesections: but that is not achieved, as precision is lost!
codesections Well, only when it's printed :) 17:26
m: my $var = 0.8144262510988963255087469; my $var2 = 1.FatRat × $var; say $var2; 17:27
camelia 0.8144262510988963255087469
lizmat m: my $var = 0.8144262510988963255087469; my $var2 = 1 × $var; say $var2 17:28
camelia 0.8144262510988963
lizmat m: my $var = 0.8144262510988963255087469; my $var2 = 2 × $var; say $var2
camelia 1.6288525021977927
lizmat looks to me it's losing precision unless you *know* you want a FatRat ?
in any case, I just found out that 0.1234.FatRat is codegenned as a fattish constant Rat with the .FatRat called on it at runtime :-( 17:29
codesections It's a weird creature. It _has_ the precision internally, but it loses it whenever it's used with anything other than a FatRat 17:30
lizmat and since a FatRat is not a Rat, we cannot just simply create a FatRat constanrt
meh 17:31
codesections It seems like your idea of special-casing how Rats print when they have a denominator that's a power of 10 would solve 95% of the issue 17:33
lizmat actually, that was a bad idea 17:35
MasterDuke m: class A is FatRat {}.new.raku.say; class B is Rational {}.new.raku.say   a bunch of other classes have this problem, they hard-code their name in their `method raku` instead of using `self.^name` 17:36
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> say; class B is Rational {}.new.raku.say⏏   a bunch of other classes have this pr
expecting any of:
infix
infix stopper
…
MasterDuke m: class A is FatRat {}.new.raku.say; class B is Rational {}.new.raku.say  # a bunch of other classes have this problem, they hard-code their name in their `method raku` instead of using `self.^name` 17:37
camelia FatRat.new(0, 1)
B.new(numerator => 0, denominator => 1)
[Coke] MasterDuke: that seems like an easy fix, yes? 17:39
lizmat yeah, that'd be an easy fix 17:45
[Coke] We should probably have a spectest that loops through all the predefined classes, subclasses them, and verifies that the new subclass appears in the raku. 17:57
18:04 cognominal joined
codesections [Coke] would there be any cases where we *don't* want the subclass name in the .raku output? (I'm wondering if it's ever a signal that the .raku method is a bit "weird") 18:04
[Coke] ... that's possible, but easy enough to adjust the list of classes we're testing. 18:05
probably want a specific list not "iterate all classes"
18:06 squashable6 left
codesections m: my class A is FatRat { has $.attribute}; my $a = A.new: :attribute<value I expected to see>; say $a.raku 18:06
camelia FatRat.new(0, 1)
cognominal Happy new year to everyone. 18:07
codesections I'm not sure that the string "FatRat" is the *most* surprising part of ^^^
cognominal same to you 🎉 18:08
18:08 reportable6 left
Geth rakudo: d6e6afb0b1 | (Elizabeth Mattijsen)++ | src/core.c/Rat.pm6
Make sure that subclasses of FatRat .raku correctly
 18:09
18:10 reportable6 joined 18:24 squashable6 joined
Geth rakudo: 82afbbf04d | (Elizabeth Mattijsen)++ | src/core.c/Rat.pm6
Make Rat.FatRat about 5x as fast

Since the Rat's attributes are already normalized, there is no reason to go through the whole normalization process again.
This also affects FatRat literals in the form 0.1234.FatRat, as these are currently codegenned as Rat WVal's with the .FatRat method called on them at runtime.		 18:38
rakudo/FatRat-literals: dc4d54020c | (Elizabeth Mattijsen)++ | 3 files
Make FatRat literals codegen as WVals

A literal as .123.FatRat was codegenned as a Rat WVal and a call to the .FatRat method at runtime: it is now codegenned as a FatRat WVal.
Also, if a Rat literal exceeds the precision of a Rat, it will issue a worry that mentions to either make it a Num or a FatRat.		 19:06
rakudo: lizmat++ created pull request #4710:
Make FatRat literals codegen as WVals		 19:07
19:07 [Coke]_ joined
lizmat codesections: github.com/rakudo/rakudo/pull/4710 19:07
19:10 [Coke] left
lizmat afk& 19:10
20:52 [Coke]_ left 20:55 [Coke] joined
Geth tap-harness6: 74b2f6d1d1 | (Leon Timmermans)++ | lib/TAP.pm
Rename variables in Test::Harness::run for simplification
 21:18
tap-harness6: 73c3a95516 | (Leon Timmermans)++ | lib/TAP.pm
Allow Supplier as output handle
tap-harness6: cacf119e85 | (Leon Timmermans)++ | 3 files
0.3.0
22:09 cognominal left 22:10 cognominal joined 22:11 cognominal left 23:51 evalable6 left, linkable6 left 23:53 linkable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!