which is the index from the end; is that intentional? Is there a common way to work with index-from-end? Is it expected to reverse Y then use the index?
@Adám the only answer I guess is that I don't understand it, but it's a case of everything I try throws an error until I salt and pepper it with parens everywhere
@TessellatingHeckler the result of (⊃⌽⍸4=⍵) is an array so you have arr@arr arr, which correctly is interpreted as arr @ (arr arr) just as 1@1 2 gives 1 2 as the right operand of @
@TessellatingHeckler there it's arr @ fn arr, and there fn can bind with @ just fine
dyadically they are left and right similarly to min and max, that doesn't seem like it would be useful enough to be a thing, and yet you use them allllll the time
@Adám parenthesising didn't help while I was thinking of it doing a replicate instead of a reduce; but I get it now - a dyadic atop identifying the positions of the fours, interval index, then right-reduce that
@dzaima no it isn't is it, derp. I wasn't actually thinking that it was doing the operation of looking up a position in a given array, but still slapped the wrong name on it
having the glyph have one name, the monadic operation another, the dyadic operation another, the casual understanding of "what it's doing" another term, another term if it's an operator .. I need to be more careful
@TessellatingHeckler Most documentation and guidance begins with the glyph and branches to each meaning. The idea of APLcart is to begin with the meaning and show the glyph.
at first i wanted to say that there are no glyphs that are both an operator and a function, but then i remembered about the slashes. those damn annoying things ಠ_ಠ
@Adám it does display as <\, but copying only escapes the <. it copies exactly what's passed to setUrl, and, to add to that, setUrl("%3C%5C") shows <%5C in the URL..
1 copies as is. 1 < 2 is true so the second element is 1 the result of previous application was 1 so 1<3? true so it's 1 the result of previous application was 1 so 1<4? true so it's 1 the result of previous application was 1 so 1<5? true so it's 1
so clearly I don't understand scan because that's not what it does
@Adám uhh, look for what in the truth table? that only a 0 < 1 can result in true, so as soon as there's a 1 on the left of < the rest of the scan will always be 0 ?
@TessellatingHeckler No, it uses the function once on the entire array, and the result must be a mask for the array. That mask is then ravelled and used to filter the ravelled array, and the left operand is applied to that list.
@Adám I wish I had a middleman between a function call and the specific code called, would be nice to have an )explain that does that kind of thing in my apl
@TessellatingHeckler Both versions are likely to be dramatically sped up in the next few years, and I expect them eventually to have the same performance.
@TessellatingHeckler Nah, if we introduce "thunks" they should be the same. ⊃⌽⍸ would only look for the index of the first from the end, and ⌽<\⌽ would know to begin from the end and mask out all but the first hit 1.
@TessellatingHeckler There is no such thing.
@TessellatingHeckler I can't wait for thunks. They will make a huge difference. ⊃⌽⍸⍵ is on line 11 and ⌽<\⌽ is on line 6 in the list of expressions to be dramatically sped up:
@TessellatingHeckler That is indeed it. Currently 3↑2×HugeArray does way to much multiplication. If that is held off until after the 3↑ we have potentially infinite speedup.
Similarly, ⊢/⍸ should just start looking for a 2 from the right, and return its index, rather than finding all the indices of ones, then taking the last one.
And even more so with ⊢/⍸a=b which doesn't even need to to do all those comparisons, just compare from right to left until we find a match, then return its index.
imo another good example could possibly be 1,2,arr vs (1,2),arr (though that's only a 2x speedup and doesn't generalize to different ranks, but those could be improved too)
i'm also curious how much time does the current idiom checking take, but at least it can probably sometimes be done statically with a Sufficiently Smart Compiler
