@EdgyNerd 819⌶A or 1(819⌶)A

Thinking about the array of functions, technically we could implement J's agenda like this, using the string representation

basically because J's gerund is just a nested array of strings

there is this in dzaima/APL (and not on tio yet you could also do (⍎1⊃fns) 3)

Actually I think agenda can be really useful in AoC, as many challenges come with some kind of command sets, and we need to parse them and map each command to a different function

Tie, Fmap and Agenda using namespaces

...looks like namespace approach is super slow

@ngn Noted and thank you very much :D Maybe I'll go back and implement that later, but right this minute I am very tired of Advent of Code XD

@Sherlock9 yesterday's problem was good, especially part 2

today's - not so much. i had to solve it in an ugly way

yesterday's part 2 requires bigint and powmod - apl may not be the right language for it. i did it in python instead of k or apl. now that i think about it, j might have worked if i were more familiar with it.

@ngn Does it go beyond the range of ⎕FR←1287?

Hm. Yeah, I've been thinking of going to and trying to learn J again

We shall see

@Bubbler do you remember what the max number of bits is for precise arithmetic with ⎕fr?

@Bubbler if the square of 119315717514047 fits in those bits, then it should be fine

@ngn IIRC it's 34 digits in decimal. It's not measured in bits because the internal representation is also decimal.

and you'd have to implement your own powmod, which is like m|a*n but for insane values of a, n, and m

unless there's a powmod somewhere in the dfns ws

>>> len(str(119315717514047**2))
29

No powermod in dfns I think

@Bubbler ^^ 34 digits should be enough

Yeah, I just checked that too

technically, squaring can be implemented in a clever way without overflows by splitting the number into a higher and lower half of the bits, but i can't be bothered to do that

J definitely has advantage because it has both arbitrary precision and powermod idiom

knew it :)

in python it's just pow(a,n,m)

and small ints silently grow into big ints instead of overflowing

dfns does have dfns.nats though it won't get far with large powers

I didn't expect a language-agnostic competition like AoC to employ such a large number

@Bubbler nats looks like it might work. for large powers there's repeated squaring with residue at every step

the lack of negative numbers might be an inconvenience

@ngn Then there's also dfns.big that supports negatives (and different set of operations)

@Bubbler nice

powmod←{a n m←⍵⋄N←nats⋄b←⌽2⊥⍣¯1⊢n⋄⊃(m|N×N)/b/{⍵,⊂m|N×N⍨⊃⌽⍵}⍣(¯1+≢b)⊂a}

big instead of nats works too

@Bubbler @Sherlock9 do you know how to divide in GF(p)?

@ngn If p doesn't divide n, n^(p-2) ≡ n^-1 (mod p).

@Bubbler yes, that's it :) so you have all the ingredients for solving day22 part2

(assuming p is prime)

@Bubbler otherwise i would have called it n :)

or m

Another way is extended euclidean algorithm. (It doesn't require numbers bigger than p, I think)

^ would be much easier if the modulo is composite

I recall implementing it in APL before, but couldn't do it elegantly

@H.PWiz interesting, that looks more efficient

@H.PWiz I think this works

I was too lazy to google it, so I just hand-crafted it

@Bubbler (⌊⍺÷⍵)(⍵|⍺) is 0⍵⊤⍺

(i can't resist the urge to golf :) )

Anyway, I believe the numbers don't go above max(n,p) so we don't even need a bignum.

in my solution i needed powmod also to sum a geom progression, maybe there's a way around that too..

powmod itself is needed I guess, though we can simplify a geom progession into a power and a division

@Bubbler the problem of how to do powmod without bigint remains, though

Your powmod with that specific modulo does work without bignum.

@Bubbler ah right.. because you have ⎕fr

in k i'd have to do multiplication in parts to avoid overflows

it's easier to reuse my bignum impl from project euler

Fastest powmod

@Adám Is ^ a good candidate for APLcart?

@Bubbler Sure. Will you PR? Oh, you did.

@Bubbler Part of what makes f slow is the ⎕fr←1287

Also there is a typo in the aplcart modpow. There are 2 {s but only 1 }

@H.PWiz Fixed.

@H.PWiz Yeah, it does make f slow, but it's still comparable to fastest powmod even in (almost) the worst case.

and here's fastest modular inverse

@dzaima @J.Sallé @anyone-else-interested How much would you charge for rewriting about 200 lines/4kB of very simple Java into APL?

@J.Sallé I'm very certain you could do it. And you'd not be on your own. We could review it together when done.

80% is basic arithmetic, string searches, and indexing.

Sure thing. I can work on it on my free time

@J.Sallé OK, turns out he has an entire library, not just this. So I'll get back to you.

No problem. In other news, I'm changing jobs in January to a new-ish company, much closer to home.

And leaving Delphi for good, thank God.

What languages then?

I'm not sure what I'll be working with exactly, but the company has a bunch of projects using Clojure, Swift, ASP.NET and some javascript flavours

So I'm thinking one of these, and I'll be happy with any of them.

@J.Sallé Congratulations!