From df6d6a0fa85c07c67eaa40a097953e3290f5d356 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Wed, 7 Jul 2021 19:59:57 -0400 Subject: Continued editing and links --- docs/doc/match.html | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'docs/doc/match.html') diff --git a/docs/doc/match.html b/docs/doc/match.html index 41c2a45e..03da6ad6 100644 --- a/docs/doc/match.html +++ b/docs/doc/match.html @@ -11,7 +11,7 @@ 4 ≢ <4 1 -

Match always gives the same result as Equals (=) when both arguments are atoms, but the two functions are extended to arrays differently: while Equals maps over array arguments to return an array of results, Match compares them in totality and always returns one boolean (it never gives an error). Match is the basis for BQN's search and self-comparison functions.

+

Match always gives the same result as Equals (=) when both arguments are atoms, but the two functions are extended to arrays differently: while the pervasive Equals maps over array arguments to return an array of results, Match compares them in totality and always returns one boolean (it never gives an error). Match is the basis for BQN's search and self-comparison functions.

↗️
    "abc" = "acc"
 ⟨ 1 0 1 ⟩
     "abc" ≡ "acc"
@@ -22,7 +22,7 @@
     "abc" ≡ "ab"
 0
-

Match compares arrays based on their fundamental properties—shape and elements—and not the fill element, which is an inferred property. Since it can be computed differently in different implementations, using the fill element in Match could lead to some confusing results. Even if the implementation doesn't define a fill for 'a'‿'b'‿'c', it should still be considered to match "abc".

+

Match compares arrays based on their fundamental properties—shape and elements—and not the fill element, which is an inferred property. Since it can be computed differently in different implementations, using the fill element in Match could lead to some confusing results. Even if the implementation doesn't define a fill for 'a'‿'b'‿'c', it should still be considered to match "abc".

To give a precise definition, two arrays are considered to match if they have the same shape and all corresponding elements from the two arrays match. Every array has a finite depth so this recursive definition always ends up comparing non-arrays, or atoms. An array never matches an atom, so the result if only one argument is an atom is 0. The interesting case is when both arguments are atoms, discussed below.

Atomic equality

Atoms in BQN have six possible types: number, character, function, 1-modifier, 2-modifier, and namespace. Equality is not allowed to fail for any two arguments, so it needs to be defined on all of these types.

@@ -31,8 +31,9 @@ ⟨ 0 0 0 ⟩

Two characters are equal when they have the same code point. Numeric equality depends on the number system in use, but probably works about how you expect. If you're coming from APL, note that current BQN implementations don't employ comparison tolerance. To see if two floats are roughly equal you'll need to write a tolerant comparison yourself, but how often do you really need to do this?

-↗️
    'x' = "wxyz"
+↗️
    'x' = "wxyz"
 ⟨ 0 1 0 0 ⟩
+
     1.25 = 1 + 0.25
 1
 

@@ -43,18 +44,21 @@
 
  • Block instances or namespaces are equal if they are the same instance.
    • 
 
 
    The first two are fairly similar to how numbers and arrays work. Primitives and compounds like trains, or modifiers with bound operands, are immutable, so they are defined purely by what components they contain.
    
-↗️
        ⟨+,-,×⟩ = ⟨+,-,÷⟩
+↗️
        ⟨+,-,×⟩ = ⟨+,-,÷⟩
 ⟨ 1 1 0 ⟩
+
     ⟨+ - ×⟩ = ⟨+ - ÷⟩  # Compare two three-trains component-wise
 ⟨ 0 ⟩
+
     ⟨+ - ÷⟩ = ⟨+ - ÷⟩
 ⟨ 1 ⟩
 
    
 
    This approach can't tell you whether two functions are mathematically different—that is, whether they ever return different results given the same arguments (this is an undecidable problem, and also gets confusing since "different" is included in its own definition). However, if two functions compare equal, then they will always return the same results.
    
 
    Block equality
    
 
    The final point above about block instances is subtler. An instance of a block function or modifier is mutable, meaning that its behavior can change over the course of a program. Consider the following two functions:
    
-↗️
        F‿G ← { a←10 ⋄ {a+𝕩}‿{a↩𝕩} }
+↗️
        F‿G ← { a←10 ⋄ {a+𝕩}‿{a↩𝕩} }
 ⟨ *function* *function* ⟩
+
     F 5   # One result
 15
     G 8
@@ -63,9 +67,10 @@
 13
 
    
 
    (A side note is that BQN restricts what can cause these side effects: they can only happen by calling a block function or modifier, and never a primitive or purely tacit operation). Now suppose we share the value of F with another variable. When we apply G, the result of F might change, but so does F1! This effect is called aliasing.
    
-↗️
        F1 ← F
+↗️
        F1 ← F
     {𝕏 6}¨ F‿F1
 ⟨ 14 14 ⟩
+
     G 3
 3
     {𝕏 6}¨ F‿F1
-- 
cgit v1.2.3