Is it acceptable style wise to use 1⊥ instead of +⌿ in a train?

@rak1507 I certainly do. And for floats, definitely.

Alright cool, I was just going over some of the old phase one questions for fun and wondered if 2|1⊥0=4 100 400∘.|⊢ would be acceptable, as using +⌿ there doesn't quite work

That's fine. You could use +⌿⍤= though.

Oh yeah, true

+.= works too, no?

That is even nicer, yeah, I need to spot inner products more.

Tangentially related. I'm pondering if it is finally time for me to let go of ∘.f and instead always write f⍤0 88

How come?

I don't like the anomalous syntax.

Fair enough, couldn't you say using ⍤ as rank rather than atop is anomalous as well?

No, not at all. How so? Operators can take function and/or array operands.

Does the behaviour normally change depending on the type? I can't think of many other things where that's the case

@ can take all combinations.

⍣ can take both types on the right.

⍨ can take both.

∘ can take all combos except array-array.

Ok, true, you're right

It's obviously too late for me to think properly

@Adám Just realised this is 18.0 only, so for running on that system what would be preferred, +.= or 1⊥?

@rak1507 I'd use 1⊥ but either is good. Also, you can use (+⌿=) as atop, or for that same |∘(+⌿) if you really want.

Ok, thanks

But if you're already using (+⌿×) then +.= is pretty obvious.

I think +.= might score slightly higher in the eyes of an old-timer, but phase 1 is judged by me, and I learned 1⊥ from its original inventor…

@Max Hey there, interested in APL?

@xpqz part 2 does, according to reddit: reddit.com/r/adventofcode/comments/k71h6r/2020_day_05_solutions/…

morning!

@Razetime afternoon :)

hello

@xpqz github.com/chrispsn/aoc2020/blob/main/4.k#L1

(it's a bit liberal with the validation tests)

I am alot more liberal dw

my day 4 was bad

<moon-child> new

<moon-child> oops, wrong window

There is a lot of ¨in my AOC solution, is it worth refactoring it to not use it, I tried using rank but it slowed it down significantly.

@rak1507 probably not worth it

I just managed to get rid of 4 of them anyway

github.com/rak1507/Advent-Of-Code-2020-APL/blob/main/…

@rak1507 very similar to mine :)

Did you do it in K I assume?

@rak1507 i solve it in k first, then golf it, then apl and golf it

Haha, fair enough

Personally I'm not that interested in golfing these ones

34 bytes

Using × is really cool, wouldn't have thought of that

days 4 and 6 used blank lines as separators in the input, there will likely be more, so it's good to prepare a short expression that splits such inputs into paragraphs

Right, I just reused my day 4 one

I think it's a decent ungolfed way of doing it

CMC apl-y-code: given 3 integers a, b, and l, create all length-l numbers consisting of base-10 digits a and b (a and b guaranteed to be ∊1…9)

@dzaima Is 012 a length 3 number?

@Adám disallowed 0 from being valid a/b

Oh, right.

(but i'd expect any sane code to consider 010 (so 10) as a valid answer for a←0⋄b←1⋄l←3)

@dzaima So, isn't this just a binary counter 0…2*l using a and b as digits instead of 0 and 1?

@dzaima Are we guaranteed that a≠b?

@Adám it is. But I'd assume doing just that would end up comparatively quite slow compared to smarter solutions

@dzaima Not sure. I've got 10⊥⎕[2⊥⍣¯1⍳2*⎕] in ⎕IO←0

2⊥⍣¯1 → ⊤ in Extended/dzaima, of course.

@Adám sure

@Adám my solution for a←7⋄b←9 (unfortunately not yet for general a/b, but shouldn't be impossible) is 4x faster than that on l←18 (i expected at least an order of magnitude, but oh well)

(oh, that goes into fp-territory. :/)

for l←9 it's only 1.3x faster and for l←8 it's slower

@dzaima 12 in BQN (14 if the result has to be rank 1).

Is there an easy to way to run the n9n/apl version of domino with some kind of tracing? I'm getting different results in my port, and I'd like to see where it deviates.

@EliasMårtenson would ⎕← work? i'm afraid there's no tracing

@dzaima ngn/k: {+x@!y#2} (ctrl+enter to run)

{10/x@!y#2} if lists of digits is not ok

@ngn I guess so. Can it be done from the web-based version or do I have to install it locally?

@EliasMårtenson in the web version ⎕← uses js alert()-s, so it could be a little annoying

@EliasMårtenson things that are likely to go wrong: ↗ is "throw". ⎕io is always 0. redefining squiggles is allowed. if you're looking at code from an old version of ngn/apl, monadic ↑ and ⊃ might be swapped.

@ngn Swapped compared to what? As best as I can tell, in the domino code I'm looking at, ↑ and ⊃ behaves just like ISO/GNU.

Oh wait, monadic.

initially i had ↑⍵ as "first" and ⊃⍵ as "mix" (i'm not sure what standard this is), but later i switched to dyalog's ⊃⍵ ("first") and ↑⍵ ("mix")

How did there end up being two conflicting versions?

@dzaima whats y code mean?

@Razetime was supposed to be "APLy-code", but tag didn't keep capitalization which just looked off, so i went with apl-y-code; Should've been fastest-code anyways, but since we get into >32-bit territory way before any reasonably large input, that doesn't quite work either

oh that makes sense

@rak1507 a historical accident, iirc.. @Adám can probably give you a link to a wiki or something with the full story

∘.,⍣(⎕-1)⍨⊢⍞⍞ haha I don't think this idea really works great

@Marshall does this really take >15s or is there something wrong with my browser?

@rak1507 @ngn aplwiki.com/wiki/Disclose (disambiguation)

@ngn take 15 for what input? It's somewhat expected for large ones since the JS interpreter is horribly slow

(and the formatter might be taking most of the time)

@Adám i knew you would have a link ;) thanks

Doesn't say why that's the case @Adám

@dzaima i just clicked on the link. the inputs seem to be 3 and 7‿9

@ngn takes <1s for me

@rak1507 Then I'm not sure what you're asking.

Why ↑ and ⊃ are flipped in some implementations

due to a misunderstanding probably

even dyalog can swap them

Yeah

@rak1507 The original NARS paper specified them as ↑ being Mix and ⊃ being First, so Dyalog APL and APL*PLUS implemented that. Last minute, IBM decided to swap them in APL2, causing the others to implement Migration Level. I'm open to suggestions on where to put that in.

I think that would be a good addition to the disclose article, I didn't know that

@ngn I know why my version of your domino fails now. It's my implementation of inner join that is broken.

It returns the wrong shape under some circumstances. Very odd.

Clearly my test cases don't cover everything.

@EliasMårtenson What is inner join?

F0.F1

@EliasMårtenson Note that there's a difference between APL2's definition for that and Dyalog's.

IIRC, APL2's f.g is Dyalog's f¨.g or something.

Nah, the issue is all on me. GNU APL, n9n and Dyalog all return 4 1 for the following: ⍴ (4 1 ⍴ 20 30 40 50) +.× (1 1 ⍴ 9)

KAP returns 4

Now I just need to figure out why :-)

Ah, the shape of X f.g Y is always (¯1↓⍴X),(1↓⍴Y)

Yes, and I implemented it based on the spec which says the same. Clearly I screwed up.

@dzaima my solution

@ngn It's on the order of 1s for me in both Qutebrowser (like Chrome; faster) and Firefox (slower). And yes, the formatter is taking the vast majority of the time. Returning the shape (≢) of the result is pretty quick for 15 digits while printing even the 10-digit result takes a few seconds.

here it's much better in chromium than firefox: 8 vs 15+ seconds

@Marshall thanks for mentioning qutebrowser. it looks great. i'll switch to it :)

'Vim-style key bindings' interesting

gmail will be a problem.. and all logins that rely on it

How come?

they allow only a few major browsers for "security reasons"

Oh right

@ngn Switch to neomutt too.

@Marshall i've been too lazy to configure [neo]mutt since a couple of laptops ago. maybe i should do it now, but it still wouldn't solve the problem with logins dependent on gmail. in my case that includes this chat.

@ngn I think for those purposes Qutebrowser should behave like Chrome, since it's using Blink. It's only when Google does user agent checking that you'll have a problem. I don't think I'm actually logging in anywhere with gmail credentials (Oath?) though so I can't be sure.

@rak1507 OK?

Yeah that's great

I'm not sure how it's done in APL but can I suggest entries for MD5/SHA/other hashing algorithms in aplcart?

@rak1507 Too verbose for inclusion, but the Dyalog Cryptographic Library includes implementations.

Ah, that's what I was afraid of

It'd probably be too slow in interpreted APL anyway, so that actually uses a DLL/SO.

Any thoughts on including it as a builtin? ⎕something maybe?

Wohooo. I might have fixed it. Does anyone have a good test case for domino?

⌹1 2 3 4 5

lol

Yeah, that works.

Anything more complicated?

@EliasMårtenson gitlab.com/n9n/apl/-/blob/master/t.apl#L68-72

ngn: Thanks

@ngn Odd, KAP now gives me the same results, but the shape of the result is 4, as opposed to 1 4 in n9n

I mean the other way around.

Anyway, the implementation is very close to the original. Most just mechanical changes due to syntax, and the fact that KAP does not support destructuring assignments at the moment.

github.com/lokedhs/array/blob/master/array/standard-lib/…

@rak1507 Why build a monolithic interpreter instead of letting people only load the modules they need?

Fair point but hashing is quite common, common enough that it makes sense to me to have something for it built in, it would hardly add much complexity

@rak1507 We do have one simple hash built in, and are contemplating adding a safer one, but not a whole library.

Maybe something for dfns?

@rak1507 That's a possibility, though dfns.dws is currently frozen due to the passing of John Scholes, awaiting my getting around to putting its source on GitHub so the community can contribute. Then again, why include cover functions there when DCL exists? What we do need is a properly set up package repository so you can do something like :Use DCL

Ah yeah, I forgot about that. I agree that a proper way of accessing things would be ideal, especially if it was as simple as that.

The package manager is being worked on, but things take time. We're always severely human-resource constrained :-( I've got around 200 items on my immediate to-do list.

It's grown since the 186 it was last time!

Yeah, we kicked off development for the 2021 competition.

Oh exciting