The APL Orchard

1:44 AM

read←{r←⍺↑⍎⍵ ⋄ r⊣1(86⌶)⍵,'↓⍨←',⍕⍺} committing cursed parser crimes

I miss state monads :(

2 hours later…

4:14 AM

⋄ parse←{bm←⍷⍨⍵ ⋄ n←≢⍵ ⋄ ⍵⊂⍨⍵{n<⍵:bm ⋄ n<r←1+⍵+⍵⊃⍺:bm ⋄ bm[r]←1 ⋄ ⍺ ∇ r}1} ⋄ parse 5 1 4 6 3 7 4 6 3 8 4 4 6 2 3 5 2 4 3 4 1 2 1 5 2 2 8 8 8 8 3 4 3 10 2 3 6 9 10 9 7 9 5 10 9 8 7 5 4 6 1 8 3 1

TryAPL

@rak1507
┌───────────┬─────────┬─────────┬─────┬─────────┬─────┬──────────────────┬──────────────┬──────────────────────┐
│5 1 4 6 3 7│4 6 3 8 4│4 6 2 3 5│2 4 3│4 1 2 1 5│2 2 8│8 8 8 3 4 3 10 2 3│6 9 10 9 7 9 5│10 9 8 7 5 4 6 1 8 3 1│
└───────────┴─────────┴─────────┴─────┴─────────┴─────┴──────────────────┴──────────────┴──────────────────────┘

anything faster than that for parsing this format? n and then n cells

trying to parse something that's a few million, it's not too slow but not fast either

(much slower than the equivalent in C or whatever)

4 hours later…

8:43 AM

@rak1507 2x faster

8:58 AM

and actually 1 million elements; plus comparison with CBQN, which is only ~3x faster:
https://dzaima.github.io/paste/#0xVJNS8NAEL3nVwwESUIwZgIN2INWwZtK9SpSi7Yq2FBqQCEGKkqwqyn1o7cWNZ4EwYsHEfXg1X8xv8Cf4Oy2FA/ePLgENvNm9s2bt6vrmq6vGDPFeWNVA7XKuEBJJ5rGik/pE3oxpXdRyBCJIzp7qyNQ@kKnxya1stCi1i3anAljhh@GFOu1@r7BhUxlgFH31A/nBhBQcgHo4NzHI8IBl7tjQO3uv3xSlDcSlXN8FuWxqPEc/k0U/LI0SvujHmwc5PzarqYuYHZpkS9AB97z0sQi6@lAFEjbWzdf/e49sOVQ5dhEW8aWTUk3UKgMSVx99uy1CTp8RUouI4WdvJvsMYlzdYD3akzNrLS3tb1TKZnB1CBJIrOY58SNZWerMbSD2/MxkYciiWeuAbTlk2hmjXKw4SyXg80KyNfRFoUfpDwWXfcKFhQUWZhH1@VpmFLDScf3eOBv#mixed

and an array-y O(n log n) solution:
https://dzaima.github.io/paste/#0zVLNTsJAEL7zFHMxQMDa3YIRAtGLJ@ITEA5i0qSHNk3DwaT2IoafSo0/8QGEiwcSD2o0JF58lHkSZ7fdgsYfggedkO3s7Oz3fTsfACJchr1zv23TitETRrcYPQKenoAjKsOx2tIXw@P43HdqtFbbdtxY86iVFahUkF1djGbqsG03vZY4TkBmgIM@eAELMhDzc8H/gcykrYOjUIHeO7JsSZHT93rYDsNw/HpH77jC6BmjicjDsYXhxKeuulNN3zDoW0WJIVSaCyKM5UWkxNR@sUiYs2pOfkNo9L2YpGg2aW0laOGYqmbTjPdeQBd9py7GNXqhwQRQTPXssz0Bs810GRg9MC77OwJY3nCZmCYh5UhyJ4/DG9IZdjsBlacJTPI5sN3DLPUTahayLleJIZOM@A@IDLB3CUxju/QcOKJ7@hrg2fWf/IQonooqa5xEcRK1Xma/EwWfhCAzUjJDMxTZZmU5MvgmUkf1xtzSVQ2dO6k3lJVxZsSZMlNvLLhp/Bc3E1UlrUKqStLO8qqq…

1 hour later…

10:33 AM

Announcement: Let's talk APL/J/K right now on jitsi.

10:59 AM

Hey Adam, do you have time for a quick question or two?

In danish as well if it is ok :)

@Secret Sure, go for it!

(next time, ping me to get immediate response)

11:14 AM

Okay, så jeg arbejder som gæsteunderviser hvor jeg har en præsentation om APL. Mine spørgsmål drejer sig om hvad man kalder "monadic" og "dyadic" på dansk? Hertil var mit andet spørgsmål om du kender en nem måde at indsætte APL unicode i LaTex (det som står på wikien gav mig ikke noget hæld i første forsøg @Adám

@Secret Dansk-talende APLere siger "monadisk" og "dyadisk" (med bløde d'er).

Tak for det, det var også det jeg gik ud fra men skulle lige være 100

Det undrer mig at Wikiens metoder ikke fungerer. Jeg ved at andre har brugt dem.

Må indrømme jeg ikke prøvede rigtig længe, så mon ikke den virker hvis jeg prøver lidt mere så. Jeg skal bare ikke bruge særlig mange (meget af præsentationen er live i IDEen) så håbede på et nemt trick

11:30 AM

@dzaima nice! f[f] is clever, I wonder what makes the second one faster than the first

@rak1507 I'd guess just having less tokens in the inner dfn (and less things invoked in general), leading to less interpreter overhead

12:30 PM

@rak1507 any tips for speeding this up or faster parsing in general? doing things like chars←(numchars←1 read 'data') read 'data' etc, kinda nicer than taking/dropping everything manually, but I've got quite a bit of them and it's getting slow

is it copying stuff?

dropping from the start will be O(result length) in Dyalog in any scenario

damn, really? maybe I should increment an index instead then

it can't overwrite the start of the array with the header and avoid copying?

oh, maybe it does that actually

or maybe I should reverse it and try parsing it in reverse?

@dzaima nope, a←⍳100000 ⋄ {a↓⍨←1}¨a ⋄ ≢a is very slow

@rak1507 you'd need to slice out the part for that then, and the only way to avoid O(n)ness there (i.e. len↑pos↓data is O(pos -⍨ ≢data)) would be to do data[pos+⍳len]

@rak1507 doing it in reverse is an option; var↓⍨←-n is fast

12:38 PM

yeah

for now I'll just stick with it because it's only like, half a second anyway

probably doesn't matter for something that I'm going to run once

Marshall

This is what I've been using, basically p3 with a bitmask instead of index list.

(¯1+`≠↑ (≠∾˜≠⌊↕∘≠+1+⊢) {0≠¯1⊑𝕩?𝕩; (⊏˜𝕨)𝕊1¨⌾((𝕩/𝕨)⊸⊏)𝕩} 1∾0¨)⊸⊔

is a short version.

It's significantly slower than p3, probably because of the 1¨⌾((𝕩/𝕨)⊸⊏).

p3 gets to skip the / entirely. It's definitely doing less work.

1 hour later…

Jeremy gee

2:16 PM

@xpqz finished the book. enjoyed it. Need to continue to strengthen my problem solving skills but that will come with time. Thanks for writing a great introduction to APL.

Marshall

@dzaima Replaced all my mask-based code with this method. It's even O(log n) instead of O(log²n) critical path. Kind of embarrasing that I missed that.

Which includes all string and comment resolution in the compiler and a few other places, not just the bytecode thing I linked.