@rak1507 Actually, the docs are all over the place, including the completely wrong, but etymologically intriguing, Diaresis. Anyway, logged as issue 18852.
@dzaima I guess if you know the exact code you were testing you could see if removing the first two bodies makes a difference, since those are the ones that share variables with it. Probably not worth tracking down though.
@dzaima ah wait, it was compiling all bodies for the last bodies variables, so the i_/o_ variables weren't available at compilation so it fell back to VAR_
About 60x slower than native C now, which is not awful.
About half as fast as J for the entire script. 3.5s where 1s is writing the file; J takes about 0.2s to write. Serializing ints in software is only going to be so fast.
The first case can be written 1↓ (×⟜o0+i0⊸×)` 0∾𝕩, which is much faster. Only affects 1-pole low-pass filters, but for the file I'm testing it cuts about 0.5s.
And that's a reminder that I should probably add dyadic scan so it would be 0 (×⟜o0+i0⊸×)` 𝕩 instead.
@dzaima I think I'll change BQN's Replicate and Rotate to automatically enclose an atom right argument on the grounds that this is pretty silly. Any objections?
Also looking at adding a left argument to Scan. I could extend 𝕨 to the shape of ⊏𝕩 by prefix agreement, but I think I'll be conservative and just require it to match exactly. I think this makes it so dyadic 𝔽`⁼ is »𝔽⁼¨⊢, which is very elegant.
@dzaima Was just going to bring up ⍉0. That one I'm a little conflicted about. ⌽0 is an error per the spec.
⍉ is interesting since it's the only monad that manipulates multiple axes: the others all change, add, or remove exactly one, except ⥊ and ⊑ which don't care about axes at all.
Eh, regardless of whether @≡⍉@ makes sense on its own, it would be better to align it with other primitives.
Making Transpose enclose atoms means it's no longer invertible for all arguments. Still worth it, I think.
@dzaima Spec, tests, and runtime have been updated. Dyadic scan needs to be provided by the runtime, so test/dz_comp -rt prim will fail until dzaima/BQN adds support.
@Marshall I think the article uses the term "open source" to mean "free open source", but Richard Stallman argues the obvious meaning of term "open source" is that the source code is public/accessible for inspection, without necessarily any other rights granted. The source code for APL\360 is potentially interesting. Should it be on the list despite being non-free open source?
@code_report Going through source code. In this case to see if there are test cases, but you might also want to look at how a primitive is implemented or something like that.
@Adám I think someone who wants to check the APL\360 source will end up on its page instead of the list, so on a purely pragmatic basis it's better not to have it. But there are some projects that would be more relevant to a modern implementation like @ktye's that I didn't add because they don't have a license indicating permission to copy the source.
@Adám Most people are probably looking for code they can actually use, but I guess you could argue that it's easy to just avoid things with "none" under the license.
@Adám If it's a commercial APL then often the company will be the author for legal purposes and not the person who wrote it, so I'm not sure this really works.
@Adám Well, while the violation of copyright law on the part of an individual would surely show poor moral fiber, linking to material with unclear copyright has some extra problems because it's more visible. There's some danger that a company would go after the APL Wiki, but it could also draw unwanted attention to the Computer History Museum. I guess you weren't really suggesting linking to those but just pointing out that with the APL Wiki we should be extra careful.
@Marshall I love how you go out of the way to assume good intentions on my behalf. Thank you. (I've on occasion had to deal with people that did the opposite.)
