You should hopefully notice that this is literally equivalent to the mapping of linear indices of a vector into the row-major indices of an array of a given shape.
This is not number theory.
This is middle school math.
It's simply two different ways to write a number.
Or, put another way, two different ways to Encode a number.
And we're dealing with MAC addresses, which are just numbers anyways.
To see the mapping from Encoding to Iota (Indices), see this:
But you should already have seen that, right, because you tried out the Encode expression already, right? :-)
Put another way, the enumeration of sequential MAC addresses to the display formats you described is literally and most directly rephrased as saying the mapping/encoding of a set of numbers on a range [X,Y) to their base 16 representations using a fixed integer size of 6 octets with either : or - as place separators at widths 8 and 16 bits, respectively.
The above expression literally does just that with 5 random numbers.
@nathanrogers If you examine the asymptotic and constant factor complexities between the examples I gave and the code snippet you gave, you should see where the performance penalties are.
In particular, remember that each array value other than a simple array value requires its own array header, and that catenation without optimized, idiomatic forms requires linear time to compute.
so understanding how 8.318241542E13 ≡ 4 11 10 7 6 10 5 2 9 11 13 3 in some way
that's where my confusion lies, but again, that isn't to say I don't understand the behavior, but that I don't understand how one could arrive at that solution
So, that breaks the problem down into 1) how to generate a set of numbers; and, 2) how to display a number in the MAC address standard formatting styles.
Generating a set of numbers is basically trivial, or a single primitive in APL.
The MAC address format takes a number and encodes it in HEX.
Encoding a number into its digits of a given base and for a given size is literally the definition of encode with a repeating element left argument.
And mapping a digit to a specific string representation is literally just an indexing problem, which is bracketing.
From there, the only question is where to put the placeholders : and -.
Notice the transpose that I have in all of my other examples?
That switches it so that each MAC address has its own row.
There is absolutely no reason in this case why you would want to store your MAC addresses as strings, but even much less, to store them as a nested vector of strings.
There are a ton of classic C.S. books that would be good, but if you're leaning towards APL, then seeing how APL solves a lot of problems would be great.
The great thing about APL is that allows you to serendipitously leverage prior domain knowledge to solve a wide range of problems. However, if you don't have that prior domain knowledge, then solving problems without understanding their underlying structure can be difficult.
The Encode, function, for instance, manifests the generalized functionality found across various domains, such as time, polynomials, number systems, permutations, SAT solving, and so forth, but you have to understand those domains before that can become clear.
Oh, you can read some of the publications, particularly the "Key to a …" paper, which shows trees using depth vectors, and then cmp/e.cd which is the updated version of the compiler using parent-sibling vectors instead of depth vectors for tree manipulation.
If you also want to learn more about tree traversal instead of tree manipulation, you can read up on the original APL book as well as "Graph Algorithms in the Language of Linear Algebra."
I took a course in linear algebra in college, but I'm not sure I can recommend the book.
However, just about any book will probably be fine. However, I think most people would assert that you don't need a lot of linear algebra experience to use APL.
However, having a Linear Algebra textbook is probably a nice thing to have.
However, things like rank, shape, row-major order, the relationship between elements and their indices, and the core APL primitives are all something you should know and feel comfortable with.
Depth is probably also an important concept, as is "cell" from J, which modern APL also uses.
Simply going through the APL Idiom list is probably a good way to explore the primitives and what you can do with them.
@pierre thanks. for reference, here's a link to attila's answer too
@pierre in theory, the valence of +' could be determined at parse time, and + could have the same valence, but i understand the desire to have consistency
it's a similar situation with compositions, eg (*|)0 1 - theoretically the parser could determine that (*|) is applied monadicly, so the rightmost verb in it (|) is monadic and the result should be 1, not *|[0 1]
@pierre ok, here's another line of thought (i hope i'm not being too annoying): in a%*+b it's clear that % is dyadic, and * and + are monadic. in f:+ the + is assumed to be dyadic. the parser could do the same for a%'*'+'b and f:+' at no extra runtime cost
@pierre (*|)[0 1;2 3] would be clearly "dyadic" (if that's the right term for [ ] syntax). (*|) . args would be unclear.
@dzaima CTO says the documentation is overly zealous, and that certain dfns are invertible, but only if they are Dyalog idioms. We can fix the named-vs-unnamed issue.
