aboutsummaryrefslogtreecommitdiff
path: root/docs/indices.html
diff options
context:
space:
mode:
authorMarshall Lochbaum <mwlochbaum@gmail.com>2020-07-17 12:04:34 -0400
committerMarshall Lochbaum <mwlochbaum@gmail.com>2020-07-17 12:26:59 -0400
commiteb01eb415a5304d98c55f844188bb0defac90c67 (patch)
treee36497edff6a231b8e0b6f4290c7e37748771284 /docs/indices.html
parent7051529b8ceefabbc8a64a3a74491a87a9651801 (diff)
Character entity escaping for "&<>
Diffstat (limited to 'docs/indices.html')
-rw-r--r--docs/indices.html6
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/indices.html b/docs/indices.html
index 02cc1d92..86af51be 100644
--- a/docs/indices.html
+++ b/docs/indices.html
@@ -87,13 +87,13 @@
<p>Unlike <code><span class='Function'>/</span></code> and <code><span class='Function'>⊔</span></code>, <code><span class='Function'>↕</span></code> and <code><span class='Function'>⊑</span></code> do use vector element indices. For <code><span class='Function'>↕</span></code> this is because the output format can be controlled by the argument format: if passed a single number, the result uses single-number indices (so it's a numeric vector); if passed a vector, it uses vector indices and the result has depth 2 (the result depth is always one greater than the argument depth). For <code><span class='Function'>⊑</span></code>, vector indices are chosen because <code><span class='Function'>⊏</span></code> handles scalar indices well already. When selecting multiple elements from a vector, they would typically have to be placed in an array, which is equivalent to <code><span class='Function'>⊏</span></code> with a numeric vector left argument. A single scalar index to <code><span class='Function'>⊑</span></code> is converted to a vector, so it can be used to select a single element if only one is wanted. To select multiple elements, <code><span class='Function'>⊑</span></code> uses each depth-1 array in the left argument as an index and replaces it with that element from the right argument. Because this uses elements as elements (not cells), it is impossible to have conformability errors where elements do not fit together. Ill-formed index errors are of course still possible, and the requirements on indices are quite strict. They must exactly match the structure of the right argument's shape, with no scalars or higher-rank arrays allowed. Single numbers also cannot be used in this context, as it would create ambiguity: is a one-element vector an index, or does it contain an index?</p>
<h1 id="major-cell-indices">Major cell indices</h1>
<p>One of the successes of the <a href="https://aplwiki.com/wiki/Leading_axis_theory">leading axis model</a> is to introduce a kind of index for multidimensional arrays that is easier to work with than vector indices. The model introduces <a href="https://aplwiki.com/wiki/Cell">cells</a>, where a cell index is a vector of any length up to the containing array's rank. General cell indices are discussed in the next section; first we introduce a special case, indices into major cells or ¯1-cells. These cells naturally form a list, so the index of a major cell is a single number. These indices can also be considered indices along the first axis, since an index along any axis is a single number.</p>
-<p>Ordering-based functions <code><span class='Function'>⍋</span></code>, <code><span class='Function'>⍒</span></code>, <code><span class='Function'>⊐</span></code>, and <code><span class='Function'>⊒</span></code> only really make sense with major cell indices: while it's possible to order other indices as ravel indices, this probably isn't useful from a programming standpoint. Note that <code><span class='Function'>⊐</span></code> only uses the ordering in an incidental way, because it's defined to return the <em>first</em> index where a right argument cell is found. A mathematician would be more interested in a "pre-image" function that returns the set of all indices where a particular value appears. However, programming usefulness and consistency with the other search functions makes searching for the first index a reasonable choice.</p>
+<p>Ordering-based functions <code><span class='Function'>⍋</span></code>, <code><span class='Function'>⍒</span></code>, <code><span class='Function'>⊐</span></code>, and <code><span class='Function'>⊒</span></code> only really make sense with major cell indices: while it's possible to order other indices as ravel indices, this probably isn't useful from a programming standpoint. Note that <code><span class='Function'>⊐</span></code> only uses the ordering in an incidental way, because it's defined to return the <em>first</em> index where a right argument cell is found. A mathematician would be more interested in a &quot;pre-image&quot; function that returns the set of all indices where a particular value appears. However, programming usefulness and consistency with the other search functions makes searching for the first index a reasonable choice.</p>
<p>Only one other function—but an important one!—deals with cells rather than elements: <code><span class='Function'>⊏</span></code>, cell selection. Like dyadic <code><span class='Function'>↑↓↕⌽⍉</span></code> (depth 0) and <code><span class='Function'>/⊔</span></code> (depth 1), Select allows either a simple first-axis case where the left argument has depth 1 or less (a depth-0 argument is automatically enclosed), and a multi-axis case where it is a vector of depth-1 elements. In each case the depth-1 arrays index into a single axis.</p>
<h1 id="general-cell-indices">General cell indices</h1>
<p>BQN does not use general cell indices directly, but it is useful to consider how they might work, and how a programmer might implement functions that use them in BQN if needed. The functions <code><span class='Function'>/</span></code>, <code><span class='Function'>⊔</span></code>, and <code><span class='Function'>⊏</span></code> are the ones that can work with indices for multidimensional arrays but don't already. Here we will examine how multidimensional versions would work.</p>
-<p>A cell index into an array of rank <code><span class='Value'>r</span></code> is a numeric vector of length <code><span class='Value'>l</span><span class='Function'>≤</span><span class='Value'>r</span></code>, which then refers to a cell of rank <code><span class='Value'>r</span><span class='Function'>-</span><span class='Value'>l</span></code>. In BQN, the cell at index <code><span class='Value'>i</span></code> of array <code><span class='Value'>a</span></code> is <code><span class='Value'>i</span><span class='Function'><</span><span class='Modifier'>¨</span><span class='Composition'>⊸</span><span class='Function'>⊏</span><span class='Value'>a</span></code>.</p>
+<p>A cell index into an array of rank <code><span class='Value'>r</span></code> is a numeric vector of length <code><span class='Value'>l</span><span class='Function'>≤</span><span class='Value'>r</span></code>, which then refers to a cell of rank <code><span class='Value'>r</span><span class='Function'>-</span><span class='Value'>l</span></code>. In BQN, the cell at index <code><span class='Value'>i</span></code> of array <code><span class='Value'>a</span></code> is <code><span class='Value'>i</span><span class='Function'>&lt;</span><span class='Modifier'>¨</span><span class='Composition'>⊸</span><span class='Function'>⊏</span><span class='Value'>a</span></code>.</p>
<p>Because the shape of a cell index relates to the shape of the indexed array, it makes sense not to enclose cell indices, instead treating them as rows of an index array. A definition for <code><span class='Function'>⊏</span></code> for depth-1 left arguments of rank at least 1 follows: replace each row of the left argument with the indexed cell of the right, yielding a result with the same depth as the right argument and shape <code><span class='Value'>𝕨</span><span class='Paren'>((</span><span class='Number'>¯1</span><span class='Function'>↓⊣</span><span class='Paren'>)</span><span class='Function'>∾</span><span class='Paren'>(</span><span class='Number'>¯1</span><span class='Function'>↑⊣</span><span class='Paren'>)</span><span class='Composition'>⊸</span><span class='Function'>↓</span><span class='Paren'>)</span><span class='Composition'>○</span><span class='Function'>≢</span><span class='Value'>𝕩</span></code>.</p>
-<p>To match this format, Range (<code><span class='Function'>↕</span></code>) could be changed to return a flat array when given a shape—what is now <code><span class='Function'>>↕</span></code>. Following this pattern, Indices (<code><span class='Function'>/</span></code>) would also return a flat array, where the indices are rows: using the modified Range, <code><span class='Function'>⥊/↕</span><span class='Composition'>∘</span><span class='Function'>≢</span></code>. Here the result cannot retain the argument's array structure; it is always a rank-2 list of rows.</p>
+<p>To match this format, Range (<code><span class='Function'>↕</span></code>) could be changed to return a flat array when given a shape—what is now <code><span class='Function'>&gt;↕</span></code>. Following this pattern, Indices (<code><span class='Function'>/</span></code>) would also return a flat array, where the indices are rows: using the modified Range, <code><span class='Function'>⥊/↕</span><span class='Composition'>∘</span><span class='Function'>≢</span></code>. Here the result cannot retain the argument's array structure; it is always a rank-2 list of rows.</p>
<p>The most interesting feature would be that <code><span class='Function'>⊏</span></code> could still allow a nested left argument. In this case each element of the left argument would be an array with row indices as before. However, each row can now index along multiple axes, allowing some adjacent axes to be dependent while others remain independent. This nicely unifies scatter-point and per-axis selection, and allows a mix of the two. However, it doesn't allow total freedom, as non-adjacent axes can't be combined except by also mixing in all axes in between.</p>
<p>Group (<code><span class='Function'>⊔</span></code>) could accept the same index format for its index argument. Each depth-1 array in the left argument would correspond to multiple axes in the outer result array, but only a single axis in the argument and inner arrays. Because the ravel ordering of indices must be used to order cells of inner arrays, this modification is not quite as clean as the change to Select. It's also not so clearly useful, as the same results can be obtained by using numeric indices and reshaping the result.</p>
<p>Overall it seems to me that the main use of cell indices of the type discussed here is for the Select primitive, and the other cases are somewhat contrived an awkward. So I've chosen not to support it in BQN at all.</p>