05:55
ACfromTX left
05:56
ACfromTX joined
17:35
human-blip left
17:36
human-blip joined
18:54
msiism joined
|
|||
msiism | Is there a way to have two unrelated counter variables in any kind of loop construct in Raku? | 18:55 | |
Hm… thinking about it more, this wouldn't help solving my problem (which I have already solved) anyway. | 18:57 | ||
antononcube | You can use Cartesian product of the "counting variables." E.g. ((^12) X (^4)).map({ ... }). | 18:59 | |
20:17
librasteve_ joined
|
|||
lizmat | msiism: I guess you could abuse Complex numbers for that ? | 20:26 | |
ab5tract | I'm having fun imagining what "two unrelated counter variables in a loop construct" might actually mean | 20:27 | |
does one count up and the other count down? does one increase by interval X and the other by interval Y? maybe it means you can only view one or the other in the loop body, but never both? | 20:28 | ||
msiism | I was thinking something along the lines of `loop ($x = 0; $x < 100; ++$x; $y = 0; $y < 10; $i + 2) {…}`. | 21:19 | |
That doesn't really make sense, though. | |||
I was trying to find a shortcut to using nested loops. As it turns out, Raku already provides that. | 21:57 | ||
ab5tract | you've managed to make me even more curious :) | 22:26 | |
msiism | I was trying to solve a task in the examples section of the Raku course. Let me find it… | 22:37 | |
course.raku.org/essentials/positio.../solution/ | 22:38 | ||
Err… I meant exercises, not examples. But these exercises surely do exemplify a few things. | 22:40 | ||
I did actually go with nested loops instead there because, IMO, that resulted in way more transparent code. | 22:41 | ||
22:57
librasteve_ left
23:10
lizmat left
23:11
lizmat joined
|
|||
ab5tract | msiism: got it, thanks! | 23:16 | |
msiism | When I enter a number as a command-line argument, it seems I have to convert it to a numeric type explicity before using it in calculations. | 23:23 | |
Like, you apparently can't just say `my $input = @*ARGS[0];` and then do, e.g., `my $result = $input div 10 - 2;`. | 23:26 | ||
23:28
lizmat left
|
|||
ab5tract | one way around that is to use a coercion | 23:28 | |
msiism | Yeah, seem div does not force its arguments to be integers. | ||
`Int($input)` works. | |||
23:28
lizmat joined
|
|||
msiism | I could also do that on the input right up top. | 23:29 | |
lizmat | docs.raku.org/syntax/%25%2ASUB-MAIN-OPTS | ||
ab5tract | indeed, as an argument to `MAIN` | ||
lizmat | you probably want :coerce-allomorphs-to(Int) | 23:30 | |
ab5tract | lizmat++ | ||
msiism | I'm just doing `my $input = Int(@*ARGS[0]);` for now. But I'll keep a note. Thanks! | ||
ab5tract | (what I had in mind was `sub MAIN(Int() $input)` | 23:31 | |
msiism | I see. I'm not in the subs chapter yet. | ||
lizmat | that would work also, but you'd need a sub MAIN then | ||
SUB-MAIN-OPTS works before that, interpreting the command line args and setting up @*ARGS | 23:32 | ||
afk& | 23:33 | ||
ab5tract | yeah, it's even better for this case | ||
nahita3882 | msiism: it works for me, e.g., my $input = @*ARGS[0]; say my $result = $input div 10 - 2; with raku prog.raku 12, it prints -1 and exits | 23:46 | |
msiism | Interesting. | 23:48 | |
nahita3882 | $input is of type Str but in numeric context, it's tried to be interpreted as a numeric value implicitly for us | ||
msiism | Well, I get an error when I do this. | 23:51 | |
paste.debian.net/plainh/b109547b | 23:52 | ||
nahita3882 | hmm, I think this is to do with divs behaviour and it changed along the way | 23:54 | |
(i realized you already said " div does not force its arguments to be integers", sorry) | |||
i used 2024.10 and it worked, so I assume your version is different | |||
msiism | Yeah, it's v2022.12. | 23:55 |