« first day (2603 days earlier)      last day (331 days later) » 

08:19
@Silas ah, thanks for spotting that. I'll fix it later
@Silas yeah, forgot to include it. probably structural only because I don't think I'll be adding function inverses
08:37
@RubenVerg If so, then I'd just make @ be that.
09:00
how?
also tonight I came up with a Filter adverb, dyadic Filter By. that's just operand-left hook-replicate though right?
@RubenVerg @a is just ⍢(a∘⊇) and @f is just ⍢(f⍛⌿)
@RubenVerg Yes.
09:18
@Adám hmm, I see, so I should make @ structural under instead?
That's what I wish I had pushed for, when @ was being designed — it just happened so quickly…
interesting. I'll consider it, but I think I might still like having both
 
2 hours later…
11:21
@Silas fixed, thanks again!
@Marshall I'll consider it. might just add both to the planning and then decide later. both options seem interesting though, so maybe I could include both with different glyphs?
could and work for behead/"belast"? or maybe swapped, idk
12:08
@RubenVerg Heh, currently ⊣⌿ is Head and ⊢⌿ is Tail. 2⊢⌿ is Behead and 2⊣⌿ is Curtail.
12:46
hmm, I guess if I add tail and init I maybe should also add head and last?
because the First and Last functions have Pick behavior
well, now they don't but I intend them to
 
2 hours later…
14:40
would it make sense to make reduce not do the weird enclose thing and just do a pure reduction over major cells?
oh, the wiki actually mentions this option. I don't know if tinyapl is leading axis model though? how can I tell
oh wait is the enclose reduce thing the same as the reduce each we were talking about yesterday?
15:09
The major cells of a list are enclosed elements, so you have to deal with enclosed stuff in either model. The only way BQN avoids it is by having ´ require its argument to be a list.
 
3 hours later…
17:41
yay reduce!
i implemented it in the most straightforward way possibile:
  let cells = majorCells xs
  let go :: [Array] -> St Array
      go []           = throwError $ DomainError "Reduce empty axis"
      go [x]          = return x
      go (a : b : xs) = do
        x <- callDyad f a b
        go $ x : xs
  go cells
17:57
scan working as well!
i'll upload a test build so you can play around with it
uploaded here, as before use wasmtime to run
oh, of course my code doesn't work! -/⍳5 is wrong because the execution order is wrong
i'll think of a way to fix that
18:29
hmm, because scan takes elements from the left, but then reduces from the right, is there a way to implement it without having to recalculate all the reductions for each prefix?
(not that i care about performance, of course, but i'm curious)
18:48
@RubenVerg only for known operands like + - × ÷ , etc.
If you're fixing stuff, I think it's best to make all the reductions run from left to right (K does this). For flat array programming, - is the only affected function that gets used much, and it's not all that common.
19:07
@Marshall hmm, it feels weird not to have rtl reductions, maybe i could just add both?
but then of course I'd need to add two scans as well.
glyph ideas?
/ ⌿ \ ⍀
heh. what for replicate then?
Oh, were you using for replicate?
(and maybe expand, but i don't know how much sense it makes without prototypes)
@Adám yeah
Maybe and indicating the reduction direction?
19:09
ah, those are nice but they can't extend to scans
unless i make scans ltr and make rtl scans be implemented in userland
(wouldn't be much of an issue if i make Prefixes, anyway)
I think it'd be maybe a little weird for / not to be a version of reduce
Well, reductions could be ↗↙ and scans ↖↘, but that's geometrically confusing.
maybe / and / \ and ?
Reversing scan order is easy enough, it's Fn⍨\⍢⌽. And Fn⍨/⌽ for reduction.
@Marshall ooh, these also look nice
i have idea but no space to write
19:14
@Marshall ah. maybe that's enough to include just one?
Aren't there 4 scans?
@Marshall these seem easy enough to learn as patterns. they go both ways (ltr → rtl and rtl → ltr), right?
@Adám including suffix scans?
Like half of reductions are +/ anyway, so ordered reductions are definitely a less-common case.
@RubenVerg Yes, since and are both self-inverses in a sense.
@Adám these of the proposed ones are the most appealing to me, because / and \ still retain their meaning, and to a certain extent ⌿ and ⍀ do too. but then i need glyph ideas for replicate and expand (:
kap does / for replicate/expand, right?
no actually I think kap only has replicate and only exists in the keyboard but is given no meaning
anyways, i'll put reduce & scan development on pause and work on array notation while we discuss the best behavior and syntax.
i've read through the wiki and it actually doesn't seem all that bad
I think the only thing to watch for in the implementation (after dodging the parsing concerns) is evaluation order. To keep consistent, it'd go left to right, so ⟨a←1⋄a+2⟩ is allowed but not ⟨a+2⋄a←1⟩.
K goes the other way for consistency with function calls, like (a+2;a:1) versus *[a+2;a:1] versus (a+2)*a:1, but without that intermediate form [] that concern isn't nearly as strong in APL.
19:31
@RubenVerg ↦ ⤅ ↤ ⬶ — meanings should be obvious.
@Marshall (Yes, this was a little exaggerated. Looks like you need +∧∨ to get to half in my code)
Those could even all be last-axis, with first-axis equivalents being ⤈ ⇟ ⤉ ⇞
(oops, I'm not being entirely consistent, but all the variations seem to exist, so you can choose doubled heads or doubled strokes.)
@Adám these are beautiful. i guess the meanings are first and third reduces and second and fourth scans?
@Adám ah, even more beautiful!
Yeah, pretty intuitive, right?
feels bad to abandon / but maybe it's the right choice!
19:40
Why, use / for replicate!
right, and now / and ⌿ are both free so i can keep both first and last axis versions for all of them!
Exactly.
time to update the planning.
any other beautiful glyph ideas like this ones?
⤈ Reduce down
⇟ Scan down
⤉ Reduce up
⇞ Scan up
⇸ Reduce right
⇻ Scan right
⇷ Reduce left
⇺ Scan left
⌿ Replicate vertically
⍀ Replicate vertically
/ Replicate horizontally
\ Expand horizontally
wouldn't imply that it's doing scan on the suffixes though? this might be a bit confusing
(or maybe you want it to mean scan on the suffixes?)
19:46
@RubenVerg Yes, hence the new complete scheme in the message above.
ah. what if i want to do one of the other two scans though?
Suffixes scan?
well, Scan in normal apl (prefixes, but right to left) doesn't appear in the list
and neither does suffixes, but left to right
@RubenVerg That's
I wasn't intending to include suffix scan.
ah, we misunderstood each other.
@RubenVerg this then applies
19:50
@RubenVerg Well, both are options. Understanding the up/left as suffixes would fit nicely with making monadic and be suffixes and prefixes.
The J strategy was to have a separate prefixes operator that just calls the function on each (non-empty) prefix. So then you could combine that with reduction in either direction, and it would recognize and combine a linear-time scan. Except J doesn't have left-to-right reduction so that's only possible in one direction...
But then you need last-axis suffixes and prefixes too, which would naturally be and
@Marshall Yeah, probably a better idea than having 8 scan operators.
Well, personally I'd just define scan as "reduction, but save the intermediate results" like K does and not have this cross-direction scan concept at all.
My actual (practical) idea was to let dyadic f⍀ and f\ have a selector left argument choose behaviour.
If you want to define all possibilities then there's also the exclusive scan, which comes up a fair amount. Array shape to strides is a right-to-left exclusive scan for one.
19:55
@Marshall Also .
Nice! Are you going to support ⟨a⋄b⋄c⟩←⍳3?
@RubenVerg Are arbitrary APL expressions allowed inside those arrays?
@Marshall hmm. i wasn't considering it but might consider it. i also don't have modified assignment, now that i think about it
I think parsing those assign-to-array expression might make the parse step a bit more ugly, though. i'll think about it
@Adám yes!
@Marshall right, this seems like the most sensible choice
is stuff like `-\` common?
Not at all, in my experience.
Modified assignment parsing is a complicated rule, happens when has a function to the left and an array to the right (and then requires a target to the further left). At least with a name convention it's resolvable statically.
20:05
I pushed an executable with array notation. it also has reduce and scan but i can't remember what state i left them in. i think reduce is rtl but scan is ltr.
Doesn't matter much for classic APL stuff. Like parenthesis depth is {+\('('=⍵)-')'=⍵}'ab(c(d)efg)'.
+\⊃-/'()'=⊂'ab(c(d)efg)' should work, but doesn't seem to be doing anything?
yes, right now only gets the first element of an array, it doesn't disclose it

« first day (2603 days earlier)      last day (331 days later) »