@cannadayr No, it just means that when calling a block the program has to remember where it was in the bytecode so it can go back there once the block finishes. You're saving the program counter. You probably want to use the alternative method mentioned, where a function/block call in BQN is also a function call in Erlang. In that case the saving just happens automatically.
@elliptic00 There's a pretty good reason for this. In C and other languages that use multiple brackets like a[3][6], an array is just a list of lists, and the only way to interact with the inner lists is to pick one, for example a[3]. So the second axis "belongs to" the first, sort of. In APL, the axes are seen as more equal, and you can work on the second one directly. For example, you can just select from the second axis using a[;6] to get column 6 of the array.
It makes more sense for APL to do one operation with multiple axes like a[3;6] than multiple operations: a[3][6] is the same as (a[3])[6].
@elliptic00 OK, but sometimes you have to put the pieces together, so you'd search for how to change a matrix to a vector and how to change numbers to a string.
I can't figure out how to take a matrix and count the amount of the alphanumerical values for each row. I will only be taking in matrices with the values I'm counting.
For example, if I got:
ABA455
7L9O36G
DZLFPEI
I would get something like A:2 B:1 4:1 5:2 for the first row and each row would be ...
(finally) pushed my namespace stuff. this is my dc.bqn: https://dzaima.github.io/paste/#0ZVLNThNRGN3PU3yUBW34YBSiC4MsBDcm/saFS@/M3AkT5s@ZabEgCSYG20IVFNJKIFV@4hBdGjVRICnLvsV9Ah7BM9OSkLg4d3LvPed8557M8BDp5TjSDcfXpV8hy3jha9owWYvC8YR@5/EDMtzAnKc5KSwZxSQiSYJcJ0lcSZZj2zKSfkJ2FHiUzEmqgOQEPpVjacHH8fPTe6IiYjNywoQcL3SlB41IwLsFzhg9rYayb23rnm5BFSeYR4FN1/Tr@kROuhIJ5jFVROQIAyl84WF7RWMGZT@JqWiUE1qQ5Il5maWACw3I5ZCEX10QVSb50pSIZQcRxaE0HeH2OaVxTTMDL3QwQa1ukFrZv/ssW0ORzKnaaSGOTN0cR18FLYwcL85Zxf9o1mIk7UJp6WJv62SZCqqTakSjPMbnLT7/xWptlVVth9V6A6jxK@5@x8FXIOUpnmZV/8y3sR4CR8AXYJ9V4wDA9wiy2inOmqxWN4GPwDZ3v3H3DwxPWDXr…
APL (Dyalog Unicode), 104 bytes
⎕←' !"#$%&''()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~'
Try it online!
Most APL interpreters would not require the ⎕←, and would thus require only 98 bytes; a quoted string evaluates to itself. The requirement for ⎕← i...
@dzaima So •Import with no left argument merges everything into the current scope? I think the merging should be a separate system function and •Import should always return the result of the file.
@dzaima I was thinking •Import and other system functions that take filenames should expand relative ones with •path (from the file containing •Import) rather than using the shell's current directory. Possibly •path itself could be replaced with such a function that does the expansion, but then just returns the result. If you really want to know the cd, ask the shell. Any downsides to this I'm missing?
@Marshall no, i just never considered doing anything about path management due to •EX itself being a pretty temporary thing. being relative to current file is a good idea, but would make projects with non-flat source directories a bit weird
<phantomics> This kind of transformation of an entire matrix at once is something that should be fairly fast with simd instructions, at least I think, haven't tried yet. Would this be a better approach than iteratively changing each set of coordinates in order to do a rotate or other array transformation?
about the question, ⌽ is pretty much a bunch of moving of data, and that's definitely doable much more efficiently than needing multiple executions of | per item
<phantomics> It would consume a good deal more memory since you need to have an array size x array rank matrix of all coordinates, but it seems like it could be faster
Yes, Dyalog uses SSSE3 for these when available. pshufb is the instruction you want, although you have to do the arithmetic to get 1-dimensional indices.
<phantomics> So they use this coordinate matrix transform approach? My approach for most array transform functions has been to iterate over the array with a function that takes the element and the coordinates, performs a transformation of the coordinates according to the function, then assigns the element to the new coordinate position in the output array
The strategy I used in Dyalog was to make a general method to select columns of a matrix. It works when input and output rows both fit in a vector register. Rather than computing all the indices at once, it just works with a row index and applies it repeatedly.
<phantomics> By 1-dimensional indices do you mean row-major references? So for a 3 x 3 matrix, (1 0) becomes 4 since it's the 4th element counted row-major?
Assuming you store matrices in row-major order, yes. The idea is just that pshufb is vector indexing, not array indexing.
If the input or output rows are too large, then using shuffle instructions won't be possible in general because you can only select from a single register at a time (or in AVX512, up to two of them).
<phantomics> Got it. The row to vector register mapping in this situation is subject to the same constraints you discussed in your talk on the reduce operator
@dzaima I guess if you want to make imports look the same across files the programmer would have to compute or propagate a base filename, and use it for loads. Finding the base automatically would pretty much require putting some kind of project file in that directory, and that's more structure than I want to add. I guess •path could be reassignable as a convenience, but that probably has a bunch of effects to consider.
APL (Dyalog Unicode), 104 bytes
⎕←' !"#$%&''()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~'
Try it online!
Most APL interpreters would not require the ⎕←, and would thus require only 98 bytes; a quoted string evaluates to itself. The requirement for ⎕← i...
