aboutsummaryrefslogtreecommitdiff
path: root/docs/doc/indices.html
diff options
context:
space:
mode:
authorMarshall Lochbaum <mwlochbaum@gmail.com>2021-07-15 08:35:30 -0400
committerMarshall Lochbaum <mwlochbaum@gmail.com>2021-07-15 08:35:30 -0400
commit85878912035fd3fb3582db60ef1fc06b459fe67a (patch)
treeebc9984a9d7446184131c3042281c683966f250d /docs/doc/indices.html
parent8d58eafa341b5a65bed1a267bc34653e46bbc6e8 (diff)
Rename self-comparison to self-search
Diffstat (limited to 'docs/doc/indices.html')
-rw-r--r--docs/doc/indices.html2
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/doc/indices.html b/docs/doc/indices.html
index 42938172..7f342cca 100644
--- a/docs/doc/indices.html
+++ b/docs/doc/indices.html
@@ -92,7 +92,7 @@
<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 list 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 atomic indices (so it's a numeric list); if passed a list, it uses list 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>, list indices are chosen because <a href="select.html">Select</a> (<code><span class='Function'>⊏</span></code>) handles atomic indices well already. When selecting multiple elements from a list, they would typically have to be placed in an array, which is equivalent to <code><span class='Function'>⊏</span></code> with a numeric list <code><span class='Value'>𝕨</span></code>. An atom <code><span class='Value'>𝕨</span></code> in Pick is converted to a list, 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 <code><span class='Value'>𝕨</span></code> 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 (invalid index errors are of course still possible). Atoms also cannot be used in this context, as it would create ambiguity: is a one-element list an index, or does it contain an index?</p>
<h2 id="major-cell-indices">Major cell indices</h2>
<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 list indices. The model introduces <a href="https://aplwiki.com/wiki/Cell">cells</a>, where a cell index is a list 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. Such an index can also be considered to select along the first axis, since an index along any axis is a single number.</p>
-<p><a href="order.html">Ordering</a> functions <code><span class='Function'>⍋⍒</span></code> and <a href="search.html">search</a>/<a href="selfcmp.html">self-comparison</a> functions <code><span class='Function'>⊐⊒</span></code> that depend on cell ordering only really make sense with major cell indices: while other indices have an ordering, it's not very natural. 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 cell in <code><span class='Value'>𝕩</span></code> 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><a href="order.html">Ordering</a> functions <code><span class='Function'>⍋⍒</span></code> and <a href="search.html">search</a>/<a href="selfcmp.html">self-search</a> functions <code><span class='Function'>⊐⊒</span></code> that depend on cell ordering only really make sense with major cell indices: while other indices have an ordering, it's not very natural. 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 cell in <code><span class='Value'>𝕩</span></code> 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: <a href="select.html">Select</a> (<code><span class='Function'>⊏</span></code>). Select <a href="leading.html#multiple-axes">allows</a> either a simple first-axis case where <code><span class='Value'>𝕨</span></code> has depth 1 or less (a depth-0 argument is automatically enclosed), and a multi-axis case where it is a list of depth-1 elements. In each case the depth-1 arrays index along a single axis.</p>
<h2 id="general-cell-indices">General cell indices</h2>
<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>