Template talk:APL built-ins

Grouping primitives
Putting my thoughts here in the hopes that we'll eventually come to a better solution. There's no urgency to this, however, and I don't really have any idea what to do yet. Our current system is based on Dyalog's, which I find unintelligible: why is Drop selection but Rotate structural? Would Sort by (like ) be selection or selector? Since it doesn't seem to me that Dyalog's system reflects usage either across APLs or in the community, I think it's better to make one of our own based on goals that make sense for an encyclopedic wiki.

Relatively recently, I added the category system, so that primitives can be placed in subcategories of Category:APL primitives (and other built-ins in Category:APL built-ins). Categories allow us to have overlapping groupings for primitives, so that for example Membership can be both a search function and a set function. However, they should be limited to groupings that are widely used and whose members are mostly agreed upon. No one's interested in a "Computational primitive functions according to Dyalog APL" category, and no one would ever agree on what to put in a "Computational primitive functions" category. But having a category system means we don't have to try to convey these kinds of essential categories in the navbox, unless they help with navigating the primitives.

As a navbox, I think the main goal for this template should not be to convey any information about how the APL community regards various primitives, but instead to make it easiest for APL users to find the primitive they are thinking about, and for new APLers to learn about the sorts of primitives they are interested in at the moment. I can think of a few criteria that would help us reach this goal. The navbox should: Oddly enough, finding some sort of "consensus" grouping might actually be harder than just finding something that makes sense. Some existing groupings that could be used as motivation are SAX's and A+'s, which I'll just paste below because their online docs navigation doesn't really work. --Marshall (talk) 14:24, 28 May 2020 (UTC)
 * Adhere to the APL community's expectations: when there are groupings or orderings with a strong tradition like scalar functions, they should be respected (I find this to be surprisingly rare).
 * Make sense: If it is possible to create a category which can be quickly understood from a few examples, with a comprehensible name and intuitive boundaries (I find this too to be surprisingly rare), we should use it.
 * Group related built-ins: if there is a strong connection between operations (Expand and Mesh??), we should prefer to place them closer together.
 * Emphasize more popular built-ins: I like functions like Complex and Raze, but they're not supported by major APLs and should be emphasized less if the other criteria allow it.
 * Otherwise, alphabetize. It doesn't help in understanding, but at least you can find what you're looking for.

A+ grouping
(from ) "Although (except for Beam and Time) they are listed alphabetically in this chapter, for convenient reference, the A+ nonscalar primitive functions can be grouped, among many other ways, in these eight categories:
 * informational functions: Shape, Count, Depth, Type;
 * structural functions: Reshape, Interval, Restructure, Reverse, Rotate, Transpose, Transpose Axes, Ravel, Item Ravel, Enclose, Disclose, Rake, Raze, Partition, Take, Drop, Replicate, Expand, Catenate, Laminate;
 * selection functions: Pick, Choose, Bracket Indexing, Right, Left, Null, Separate Symbols;
 * computational functions: Matrix Inverse, Solve, Deal, Pack, Unpack, Encode, Decode;
 * comparison functions: Match, Member, Find, Bins, Grade up, Grade down, Partition Count;
 * format and representation functions: Format, Default Format, Cast;
 * specificational functions: Assignment, Append, Bracket Indexing Selective Assignment, Replace All, Selective Assignment; Beam;
 * evaluative, display, and control functions: Execute, Execute in Context, Protected Execute, Value, Value in Context, Result, Signal, Print, Stop; Time."

--

Given the flood of primitives, I think we might need a multi-level categorization. Here is a very rough (and kind-of arbitrary) draft for non-scalar functions (IMO, such an organization is also needed for scalar ones). --Bubbler (talk) 07:59, 22 June 2020 (UTC)


 * Identity
 * Identity
 * Structural
 * Query: Shape, Tally, Depth
 * Flat transform: Reshape, Ravel, Table, Catenate, Reverse, Rotate, Transpose
 * Nested transform: Enclose, Nest, Mix, Split, Enlist, Partitioned Enclose, Partition, Pair, Link
 * Selective
 * Indexing: Bracket, First, Pick, Index, Select
 * Take/Drop: Take, Drop
 * Replicate/Expand: Replicate, Expand
 * Set: Unique, Intersection, Union, Without
 * Computational
 * Range: Index Generator
 * Equality: Match, Not Match, Membership, Index Of, Find, Nub Sieve
 * Ordering: Grade, Interval Index
 * Matrix: Matrix Inverse, Matrix Divide
 * Base: Encode, Decode
 * Format/Execute: Format, Execute
 * Random: Deal
 * Miscellaneous: Materialise

A bonus for scalar functions and primitive operators: --Bubbler (talk) 00:33, 26 June 2020 (UTC)

Scalar functions

 * Arithmetic
 * Monadic: Negate, Reciprocal, Magnitude, Exponential, Natural Logarithm, Floor, Ceiling, Square Root
 * Dyadic: Add, Subtract, Times, Divide, Residue, Power, Logarithm, Root
 * Boolean: Not, And, Or, Nand, Nor
 * Comparison: Minimum, Maximum, Comparison functions
 * Complex numbers: Conjugate, Imaginary, Complex
 * Advanced mathematics: GCD, LCM, Factorial, Binomial, Pi Times, Circular
 * Random numbers: Roll
 * Miscellaneous: Type

Operators

 * Spread: Each, Rank, Depth
 * Product: Inner Product, Outer Product
 * Replicate/Expand: Replicate, Expand
 * Reduce/Scan: Reduce, Windowed Reduce, Scan
 * Primitive Modifier: Function axis, Variant
 * Functional: Commute, Constant, Bind, Compositions, Under
 * Other: Power, Key, At, Stencil, Spawn, I-beam