@Cowsquack Single character screen-full updates can be done on text-based screens using, I think, the []SM functionality. However, I'm not sure the Dyalog folks are terribly excited about continuing to support that functionality. Using the Windows or HTMLRenderer stuff is more likely to garner their support. ;-)
@nathanrogers Regarding Each and Outer Product, I should clarify that Each is really the one I have problems with. Outer Product is less inherently troublesome than Each. However, using Outer Product with a complex, non-primitive operand over large arrays can be as troublesome as each.
Using Outer Product with primitives over large arrays is not likely to be as troublesome, but you have to be careful about the asymptotic complexity of your code at that point, and make sure that you aren't turning a linear algorithm into a quadratic one unnecessarily.
So doing something like 3 5∘.|⍳20 isn't an inherently bad thing at all, and it's not really a performance problem.
@nathanrogers Hrm, while I don't think an outer product solution is bad here, if I want to be really cheeky I can. :-) Here's a solution that uses only two incidental nested arrays, but otherwise works entirely over simple, flat, non-nested arrays.
With the exception of a small bit of text rendering, it also uses almost entirely vectorized primitives.
There's zero "element at a time" working here, and this method could be trivially expressed on a large SIMD vector machine such as a GPU efficiently:
That means that there are no sync barriers to keep a GPU from executing everything on the right of the enclose as a single, ultra-fast kernel in one go.
The critical path complexity of the above expression is almost entirely constant time.
That means that the above expression is so embarrassingly parallel that it will scale almost perfectly.
The way it's expressed right now it is limited to counting up to 99999999.
However, for any given size of machine integer for the above, if you have enough SIMD threads, and your memory can keep up, that computation would theoretically take constant time to compute.
On a modern GPU, you should see constant time performance up to about 2048 or 4096 elements, at which point you could expect the system to scale in accordance with the memory bandwidth/throughput of your GPU.
Incidentally, this method can be scaled to an arbitrary number of "FizzBuzz" elements up to about the first 48 primes in current implementations of APL.
Here's a generalized fizzbuzz that works for a large number of factors (up to about 48), and only uses nested arrays and that sort of thing for the "high level" control, and does everything using vectorized primitives under the hood, with meaty operations the whole way though, avoiding "element at a time" computation, and working mostly over simple arrays.
@dzaima you should expose a plotting api, like ike, add keyboard hooks too, and then it will be possible to write games and your impl will become famous :P
@Cowsquack ¨ calls (think of it as a jump/goto to) + for each element, while just + alone can be, at the very worst, implemented as a single loop (though it should be using SIMD for even more performance)
@dzaima adding on to ngn, yeah an apl interface to processing would be really cool, nowadays when I get a graphical idea I want to implement in processing, I quickly get discouraged because I don't have apl's power, like the gravity thing I mentioned not long ago
@Cowsquack I'll think about it, but currently some of the modifications have made my APL jar not work for android :|
it's saying Cause: default or static interface method used without --min-sdk-version >= 24 but I neither use default/static interfaces nor have min SDK < 24 ಠ_ಠ
my workflow for PDE is have the same project for PC & android and switch between the two by changing a //* to /* or vice versa (aka primitive macros :p)
@dzaima apl385 is in the public domain. dejavu "incorporates the Bitstream Vera license, an extended MIT License which restricts naming of modified distributions and prohibits individual sale of the typefaces, although they may be embedded within a larger commercial software package" wikipedia
@ngn that far I got, but the APL385 font has Copyright 2013, Adrian Smith, Brook House, Gilling, YORK, UK in the copyright field, and DejaVu - Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved., and I have no idea where the licenses shall be included
@dzaima I don't think you need to do anything special to use the fonts as they are. The only catch with DejaVu is that if you modify the font, you must rename it.
@ngn yeah I've renamed it, the thing is the base font of the merge was APL365 so nothing beyond glyphs of dejavu was present, which is why I'm wondering about what to do
@Adám yeah, there's a boolean option in the charmap JSON to scale the display text down. I'm not a font expert, I barely merged the fonts together at all :p
@dzaima Oh ⍨ I feel your pain. I don't know anything either. Tried merging Noto Symbols into Noto Sans Mono so it would cover APL — turned out horrible.
@nathanrogers Right, I understand what you're asking. Even if I can't get a hold of Tomas by mail (I'll try, though), it is very likely that I'll see him next week. I'll ask him to pop in here so you can ask yourself.
@nathanrogers You may be able to glean something from his SE presence:
