From c96289046dbd42678c10d03ceb5734737392bf4c Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Mon, 5 Jul 2021 22:20:19 -0400 Subject: Inter-documentation links and minor editing --- docs/doc/couple.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/doc/couple.html') diff --git a/docs/doc/couple.html b/docs/doc/couple.html index fa9b905a..1e55a233 100644 --- a/docs/doc/couple.html +++ b/docs/doc/couple.html @@ -65,7 +65,7 @@ ∾ ⥊ ⥊¨ a "ABrstABuvwABxyzCDrstCDuvwCDxyz" -

The way this happens, and the constraint that all inner arrays have the same shape, is closely connected to the concept of an array, and like Table ⌜, Merge might be considered a fundamental way to build up multidimensional arrays from lists. In both cases rank-0 or unit arrays are somewhat special. They are the identity element of a function with Table, and can be produced by Merge inverse, >⁼ on a list, which forces either the outer or inner shape to be empty (BQN chooses >⁼ to be <, but only on an array, as > cannot produce non-arrays). Merge has another catch as well: it cannot produce arrays with a 0 in the shape, except at the end, without some sort of prototype system.

+

The way this happens, and the constraint that all inner arrays have the same shape, is closely connected to the concept of an array, and like Table ⌜, Merge might be considered a fundamental way to build up multidimensional arrays from lists. In both cases rank-0 or unit arrays are somewhat special. They are the identity value of a function with Table, and can be produced by Merge inverse, >⁼ on a list, which forces either the outer or inner shape to be empty (BQN chooses >⁼ to be <, but only on an array, as > cannot produce non-arrays). Merge has another catch as well: it cannot produce arrays with a 0 in the shape, except at the end, unless fills can be specified.

↗️
    ⊢ e ← ⟨⟩¨ ↕3
 ⟨ ⟨⟩ ⟨⟩ ⟨⟩ ⟩
     ≢ > e
@@ -75,7 +75,7 @@

Above we start with a list of three empty arrays. After merging once we get a shape 3‿0 array, sure, but what happens next? The shape added by another merge is the shared shape of that array's elements—and there aren't any! If the nested list kept some type information around then we might know, but extra type information is essentially how lists pretend to be arrays. True dynamic lists simply can't represent multidimensional arrays with a 0 in the middle of the shape. In this sense, arrays are a richer model than nested lists.

Coupling units

-

A note on the topic of Solo and Couple applied to units. As always, one axis will be added, so that the result is a list (strangely, J's laminate differs from Couple in this one case, as it will add an axis to get a shape 2‿1 result). For Solo, this is interchangeable with Deshape (⥊), and either primitive might be chosen for stylistic reasons. For Couple, it is equivalent to Join-to (∾), but this is an irregular form of Join-to because it is the only case where Join-to adds an axis to both arguments instead of just one. Couple should be preferred in this case.

+

A note on the topic of Solo and Couple applied to units. As always, one axis will be added, so that the result is a list (strangely, J's laminate differs from Couple in this one case, as it will add an axis to get a shape 2‿1 result). For Solo, this is interchangeable with Deshape (⥊), and either primitive might be chosen for stylistic reasons. For Couple, it is equivalent to Join-to (∾), but this is an irregular form of Join-to because it is the only case where Join-to adds an axis to both arguments instead of just one. Couple should be preferred in this case.

The pair function, which creates a list from its arguments, can be written Pair ← ≍○<, while ≍ in either valence is >∘Pair. As an interesting consequence, ≍ ←→ >∘≍○<, and the same relationship holds for Pair.

↗️
    ⟨2,3⟩ ≍○< "abc"  # Pair two values
 ⟨ ⟨ 2 3 ⟩ "abc" ⟩
-- 
cgit v1.2.3