The APL Orchard

10:05 AM

@dzaima Where are you getting "300ms" from? 659-572? Also, why do you muddle your results by including the argument generation in the timing?

@Adám 300ms was from this - indeed, I extracted the argument generation

@dzaima Now that's interesting. Do you want to email support about it, or should I ask Marshall (our main performance guy) directly? You're also using 64 bit IEEE floats, right?

@Adám I'd rather not have to write emails. yes, ⎕fr←645 was one of the first things I checked

@dzaima OK, I'll ask tomorrow.

2 hours later…

11:43 AM

more comparison because testing is fun
https://tio.run/##xZjNalNBFMf3fYq7bmCcc2bOfEDVZ7lpUQSpoiDoSlxIsal0EYkLwY0rEdwE3GRl3uS@SDz3a2Za781ypoQyMyG5P/7/8zU5ry/f1K8Ph7r5ePsYZffX3GzlyfL@wUmzXjXr9/@9fs0fTr515Lx/3fKTPrx89eJpVfHi4m1VdYvzdvOuGnb7zYP9n2rc8Se@TX3Vbv5wN/P03VG2Hy1b8/nLxfNKAC8rkFJguwgb09IxGghWzmSHwwX2mvB/KeSI1m00r55dPikkGzY33@uRzWmhePGo2yAKJztTq0oJ440vDkcRDgRFOK9AZoerGS646lwXcEE5TREOfRm4ejLklBfeFQ25lm05siknXGDTUngdM5UI8peRXreBx3b1ZHBVCnCDqyiU0jp/PpyOnoIkoQMa6yYpoBkF@VO1Po0VDoWNFU4LhGApkS@BpgIaxb7QqqbHvmCFdYAF0EKSMo1J0bpyO7YshAJoywSN0ljrDd30aDa/aqcxQ5GrWUADEzsWsKEyf93F/SaWXZV2eu5eLuYBugLB…

8 hours later…

8:06 PM

@dzaima Wow, thanks. I'll make sure to report all of that.

"speed fuzzing" :D

2 hours later…

9:44 PM

⎕←2 2 2 2∘⊤ 12 10

@TessellatingHeckler
1 1
1 0
0 1
0 0

i have no feeling for why that has come out as columns instead of rows. I was expecting it to do this

⎕←2 2 2 2∘⊤¨ 12 10

@TessellatingHeckler
┌───────┬───────┐
│1 1 0 0│1 0 1 0│
└───────┴───────┘

⎕←↓⍉2 2 2 2∘⊤ 12 10

@dzaima
┌───────┬───────┐
│1 1 0 0│1 0 1 0│
└───────┴───────┘

9:47 PM

@TessellatingHeckler it outputs the same data, just in a matrix, as that's a way more efficient format

but why isn't the matrix
1 1 0 0
1 0 1 0

⎕←↑(2 2 2 2⊤ 12) (2 2 2 2⊤ 10)

@TessellatingHeckler
1 1 0 0
1 0 1 0

@TessellatingHeckler just an arbitrary choice (or some deliberate reason which I don't know). maybe it was more efficient to make it work that way?

does it fit the design of APL in some way? If I write the numbers twenty seven, twenty eight, twenty nine, they don't show up as
2 2 2
7 8 9

if it's just "a choice", that's ok, I'm more wondering "is it showing me something fundamental about APL I need to understand"?

apart from being a single matrix rather than a nested vector

"data organised in columns is amazing because ___"

:shrug: idk

@TessellatingHeckler performance

arrays are represented in memory in row-major order. if you do b⊥ on that matrix, the interpreter would have to multiply the first row by b and add it to the second row. it's more efficient to perform operations on stretches of consecutive memory instead of jumping over gaps

10:52 PM

@ngn i understand the concept you're saying, but your phrasing isn't clear to me. If I do b⊥ on which matrix? The interpreter would have to, and that's good, or would have to and that's bad? Which way is row-major order?

@TessellatingHeckler this matrix for example:

2 2 2
7 8 9

@TessellatingHeckler if the matrix is oriented like this, it's good, otherwise bad :)

if the matrix was the transposition of the above, its elements would be represented in memory as 2 7 2 8 2 9 and the interpreter wouldn't be able to take advantage of sse/avx instructions

@ngn are you telling me that running across a row is faster than running down a column?

@TessellatingHeckler yes

modern cpus have caches and prefetch

so because the top row represents tens, and the lower row represents units, it can load all the twos and do *10 on them with SSE/AVX?

(multiply ten, not power ten)

@TessellatingHeckler yes, that's what i was trying to say. i'm not very good at expressing myself

certainly, when Iverson was designing the language there were no caches and prefetch. so he must have had other considerations in mind

11:09 PM

@ngn thank you :) there's just a lot of background knowledge I don't have; if I don't know row-major then I can see consecutive memory access is better, but still not know which axis is consecutive

I have read that J language does something different with prioritising rows / columns compared to APL

but I don't know what. Is there any record of whether Iverson was happy with how J turned out or not?

@TessellatingHeckler i don't know enough j to be confident about this, but they probably meant that things like reduction in j work by default along the leading axis (example), as opposed to apl in which reduction is last-axis by default

same example in apl

@TessellatingHeckler i don't know

@ngn I'm not familiar with leading-axis / last-axis terms either; I've mostly only played with single row vectors and a tiny bit with 2D matrixes. I do see that's adding down, instead of accross, but I imagine this matters more with more dimensions

⎕←+x←3 3 ⍴ ⍳9 ⋄ nl ⋄ +/x

11:25 PM

@TessellatingHeckler
1 2 3
4 5 6
7 8 9
VALUE ERROR

@TessellatingHeckler the convention is to treat the vertical axis as first and the horizontal axis as second

hmm, putting that nl in for a newline in TryAPL seems to break, instantly saying EXPRESSION TIME LIMIT EXCEEDED

@TessellatingHeckler a dyalog interpreter (non-interactive) is also available at tio.run/#apl-dyalog

@TessellatingHeckler is nl something tryapl-specific? i would normally do ⎕←'' to print a newline

@ngn idk, I have seen people use nl in places to concat a newline

I assumed it was a Dyalog thing, but now I'm guessing it was something specific to their environment or they defined it earlier and I didn't notice

⎕←2 2 2 2 2 ⊤ 15 20

11:47 PM

@TessellatingHeckler
0 1
1 0
1 1
1 0
1 0

this gives me enough bits to fully encode both numbers. I can also do

⎕←(5 ⍴ 2) ⊤ 15 20

@TessellatingHeckler
0 1
1 0
1 1
1 0
1 0

but it feels odd that there is no "give me enough bits to encode them all"

is that because it would imply scanning the entire array for the max value, then going back and encoding the first item afterwards?

so if I explicitly want to do that, I should explicitly do

⎕←((⌈2⍟⌈/a)⍴2) ⊤ a←15 20

@TessellatingHeckler
0 1
1 0
1 1
1 0
1 0