Adám, these videos are seriously excellent. I've learned so much just from watching them, pausing every time you arrive at a full function, and trying to reconstruct it from memory. Thanks so much for your work.
No biggie -- your voice-over makes it clear. Although maybe it's possible to add graphical annotations? "<------- should be a q, not a p" kind of overlay.
No, I edited the video, overlaying an image. Causes my face video to disappear for those parts, but that's OK, because it was anyway slightly on top of the sequence.
But yes, I think I can excuse myself for leaving it out, as the approach is otherwise very similar to the other ⍣-based ones, and the video was pretty long.
I think dyalog just doesn't support using the last reference to ⍵ as an owned reference
(what if the concatenation resulted in an error? (e.g. mismatched shape, WS FULL) You'd get thrown into the debugger, and would have to be able to use ⍵, but, were the , able to consume it, it might be freed/mutated)
@Adám Thanks - I'm wondering if it SHOULD actually be undocumented. What is the relationship between this feature of ⎕FIX and Link? Does Link use this mechanism, or is it a vestige of SALT?
> Progressive dyadic iota is similar to ⍳ except that it returns the index of subsequent matches in the left argument until they are exhausted. Write a function that implements progressive dyadic iota.
@Richard I think if you can derive the APLCart solution unaided, you're already pretty accomplished at APL. The problem here is that this is so well known it's hard not to have it "spoiled".
I started with this 'dyalog apl' {⍸⍵∘.⍷⍺} 'aaalllb' and also tried something with the key operator '{⍺⍵}⌸'dyalog apl' But both were completely the wrong track.
@Richard The main idea is that each unique row in the equality table represents a different unique value in the right argument. The ones indicate the indices where the value can be found in the lookup string, and the number of times it appeared in the right argument (≢⍺ in the operand of Key) tells us how many of these indices we need. Then we pair up these indices with the locations where they have to be appear in the output and construct the output by sorting.
Because overtaking produces 0's instead of length+1 for missing values, the @ replaces those
So I basically blot out elements as they are used.
My ⌸-based solution generates a table of contents t for ⍺, then for every unique value in ⍵ and its indices, pairs up each index with the corresponding index in the ⍵-ToC. Then we sort them back into their original locations and replace 0s with 1+≢s.
n←⎕NS⍬ is a value that doesn't equal anything else than itself.
We start by taking a copy of ⍺, but with one "overflow" element added. We loop over the elements of ⍵. For each one, we use regular ⍳ to find the first location in a, ignoring the added element. Once found, we blot out that element as being used, by overwriting it with n (which doesn't match anything else). If it wasn't found, we overwrite the added element, with no actual effect. Finally, we return that element's found index, and proceed to the next.
s←⎕A[?1e6⍴26] ⋄ t←⎕A[?1e6⍴26] ⋄ cmpx's X t' 's Y t' ⍝ same length and distribution
s X t → 1.9E¯2 | 0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
s Y t → 2.2E¯2 | +15% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
s←⎕A[?1e6⍴10] ⋄ cmpx's X t' 's Y t' ⍝ lots of missing elements
s X t → 1.5E¯2 | 0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
s Y t → 2.2E¯2 | +44% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
s←⎕A[?1e3⍴26] ⋄ cmpx's X t' 's Y t' ⍝ short haystack
s X t → 1.7E¯2 | 0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
Tomorrow I will be sitting in a bus for 14 hours :). What I normally do to figure it out is decomposite it to the parts I do understand and than slowly rebuild and play with it.
