From 8ddad454b30cdafc9bbdc0cbd51c653bee8a87e5 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Fri, 30 Dec 2022 20:57:20 -0500 Subject: Rebuild with CBQN's new number formatting (ryu) --- docs/doc/arithmetic.html | 2 +- docs/doc/fold.html | 2 +- docs/doc/under.html | 2 +- docs/help/exponential_power.html | 4 ++-- docs/help/squareroot_root.html | 6 +++--- docs/implementation/kclaims.html | 12 ++++++------ docs/tutorial/combinator.html | 6 +++--- docs/tutorial/expression.html | 4 ++-- 8 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/doc/arithmetic.html b/docs/doc/arithmetic.html index 918bd9c5..7c8a900a 100644 --- a/docs/doc/arithmetic.html +++ b/docs/doc/arithmetic.html @@ -94,7 +94,7 @@ ⟨ 1 2.718281828459045 7.38905609893065 ⟩ √ 0‿1‿2‿4 -⟨ 0 1 1.414213562373095 2 ⟩ +⟨ 0 1 1.4142135623730951 2 ⟩

Take note of the difference between the function -, and the "high minus" character ¯, which is a part of numeric notation. Also shown is the number ∞, which BQN supports along with ¯∞ (but depending on implementation BQN may or may not keep track of ¯0. Integer optimization loses the distinction so it's best not to rely on it).

The logarithm is written with Undo: ⋆⁼. As with Power, the default base is e, giving a natural logarithm.

diff --git a/docs/doc/fold.html b/docs/doc/fold.html index d59caf97..4d73e8c0 100644 --- a/docs/doc/fold.html +++ b/docs/doc/fold.html @@ -151,7 +151,7 @@

And the operand +⟜÷ is a quick way to compute a continued fraction's value from a list of numbers. Here are a few terms from the continued fraction for e.

↗️
    +⟜÷´ 2‿1‿2‿1‿1‿4‿1‿1
-2.71830985915493
+2.7183098591549295

Initial element

When 𝔽 isn't just an arithmetic primitive, folding with no initial element can be dangerous. Even if you know 𝕩 isn't empty, saving you from an "Identity not found" error, the case with only one element can easily violate expectations. Here's a somewhat silly example of a function meant to merge elements of the argument into a single list (∾⥊¨ is a much better way to do this):

diff --git a/docs/doc/under.html b/docs/doc/under.html index 4ec761a8..df79f48c 100644 --- a/docs/doc/under.html +++ b/docs/doc/under.html @@ -82,7 +82,7 @@

Computational Under

Computational Under is based on Undo (⁼), and applies whenever structural Under doesn't. It's still limited, because Undo doesn't work on many or even most functions. One common use is with the square function ט, for computations such as finding the magnitude of a vector, or a root-mean-square average like the one below.

↗️
    (+´÷≠)⌾(ט) 2‿3‿4‿5
-3.674234614174767
+3.6742346141747673

This average is the square root of the average of the squares of the arguments, and ⌾ lets us combine the two square-y steps. Here there are two possible solutions because ¯3.67… has the same square as the positive result; BQN of course uses the principal root. Similarly, ⌾÷ can be used for a harmonic sum or mean (you might notice that computational Under is a lot more mathy than the structural one).

Under is the idiomatic way to do a round-to-nearest function:

diff --git a/docs/help/exponential_power.html b/docs/help/exponential_power.html index c21f9479..f3477fa6 100644 --- a/docs/help/exponential_power.html +++ b/docs/help/exponential_power.html @@ -10,7 +10,7 @@

e (Euler's constant) to the power of 𝕩.

Pervasive.

↗️
    ⋆ 0‿1‿2‿3
-⟨ 1 2.718281828459045 7.38905609893065 20.08553692318767 ⟩
+⟨ 1 2.718281828459045 7.38905609893065 20.085536923187668 ⟩

𝕨 ⋆ 𝕩: Power

→full documentation

@@ -23,5 +23,5 @@ ⟨ 64 25 81 ⟩ 2‿3 ⋆ 3‿¯4 -⟨ 8 0.01234567901234568 ⟩ +⟨ 8 0.012345679012345678 ⟩ diff --git a/docs/help/squareroot_root.html b/docs/help/squareroot_root.html index 21c88b38..43ed980d 100644 --- a/docs/help/squareroot_root.html +++ b/docs/help/squareroot_root.html @@ -9,15 +9,15 @@

→full documentation

Pervasive.

↗️
    √ 2
-1.414213562373095
+1.4142135623730951

𝕨 √ 𝕩: Root

→full documentation

𝕨th root of 𝕩.

Pervasive.

↗️
    2 √ 2
-1.414213562373095
+1.4142135623730951
 
     1‿2‿3‿4 √ 4
-⟨ 4 2 1.587401051968199 1.414213562373095 ⟩
+⟨ 4 2 1.5874010519681994 1.4142135623730951 ⟩
diff --git a/docs/implementation/kclaims.html b/docs/implementation/kclaims.html index d11de34a..83876814 100644 --- a/docs/implementation/kclaims.html +++ b/docs/implementation/kclaims.html @@ -86,12 +86,12 @@

Dividing the stall number by total cycles gives us percentage of program time that can be attributed to L1 instruction misses.

↗️
    l ← "J"‿"BQN"‿"BQN"‿"Python"
     l ≍˘ 100 × 56‿4.5‿494‿25 ÷ 1_457‿232‿5_633‿499
-┌─                            
-╵ "J"      3.843514070006863  
-  "BQN"    1.939655172413793  
-  "BQN"    8.76974968933073   
-  "Python" 5.01002004008016   
-                             ┘
+┌─                             
+╵ "J"      3.8435140700068633  
+  "BQN"    1.9396551724137931  
+  "BQN"    8.76974968933073    
+  "Python" 5.01002004008016    
+                              ┘

So, roughly 4%, 2 to 9%, and 5%. The cache miss counts are also broadly in line with these numbers. Note that full cache misses are pretty rare, so that most misses just hit L2 or L3 and don't suffer a large penalty. Also note that instruction cache misses are mostly lower than data misses, as expected.

Don't get me wrong, I'd love to improve performance even by 2%. But it's not exactly world domination, is it? The perf results are an upper bound for how much these programs could be sped up with better treatment of the instruction cache. If K is faster by more than that, it's because of other optimizations.

diff --git a/docs/tutorial/combinator.html b/docs/tutorial/combinator.html index baddaa83..cba64b16 100644 --- a/docs/tutorial/combinator.html +++ b/docs/tutorial/combinator.html @@ -546,7 +546,7 @@ ↗️
    ↕⊸÷ 8
 ⟨ 0 0.125 0.25 0.375 0.5 0.625 0.75 0.875 ⟩
     (↕8) ÷ 7
-⟨ 0 0.1428571428571428 0.2857142857142857 0.4285714285714285 0.5714285714285714 0.7142857142857143 0.8571428571428571 1 ⟩
+⟨ 0 0.14285714285714285 0.2857142857142857 0.42857142857142855 0.5714285714285714 0.7142857142857143 0.8571428571428571 1 ⟩

What function turns 8 into 7? We can bind 1 to - on the left:

↗️
    -⟜1 8
@@ -554,11 +554,11 @@

Now we need to apply ↕ and this function to 8, dividing the results. It turns out we can do this using both Before and After. On one side we'll have ↕8, and on the other -⟜1 8.

↗️
    ↕⊸÷⟜(-⟜1) 8
-⟨ 0 0.1428571428571428 0.2857142857142857 0.4285714285714285 0.5714285714285714 0.7142857142857143 0.8571428571428571 1 ⟩
+⟨ 0 0.14285714285714285 0.2857142857142857 0.42857142857142855 0.5714285714285714 0.7142857142857143 0.8571428571428571 1 ⟩

This structure—Before on the left, After on the right—is also useful with two arguments: I call it "split compose", and it applies one function to the left argument and another to the right before passing them both to the middle function (if the functions on both sides are the same, that would be Over!). Although it turns out it's not needed in the one-argument case. You'll get the same result just by jamming the functions together. This is called a "train" and we should probably leave it for another tutorial before going too far off the rails.

↗️
    (↕÷-⟜1) 8
-⟨ 0 0.1428571428571428 0.2857142857142857 0.4285714285714285 0.5714285714285714 0.7142857142857143 0.8571428571428571 1 ⟩
+⟨ 0 0.14285714285714285 0.2857142857142857 0.42857142857142855 0.5714285714285714 0.7142857142857143 0.8571428571428571 1 ⟩

Base decoding continued

We're speeding up a bit now, so in the examples below it might take some time for you to break down what I did and why. Remember that you can open any expression in the REPL in order to change parts of it or view the syntax. And don't get discouraged just because of how long it takes to understand a line of code! First, you'll surely get faster in fitting the pieces together. Second, a line of BQN often has more code in it than a line in other languages, because primitives have such short names. Think about how much functionality you can read and understand rather than how few lines you get through.

diff --git a/docs/tutorial/expression.html b/docs/tutorial/expression.html index 6c654cd7..52de145d 100644 --- a/docs/tutorial/expression.html +++ b/docs/tutorial/expression.html @@ -97,7 +97,7 @@

You could use Power to take square roots and n-th roots, but BQN has a primitive √ for this purpose. If no left argument is provided, then it's the Square Root function; with a left argument it's called Root, and raises the right argument to the power of one divided by the left argument.

↗️
    √ 2
-1.414213562373095
+1.4142135623730951
     3 √ 27
 3
@@ -117,7 +117,7 @@

I bet if you try hard you'll remember how much you hated learning to do exponentiation before multiplication and division before addition and subtraction. Didn't I tell you Earth was a confusing place? BQN treats all functions—not only primitives, but also the ones you define—the same way. They're evaluated from right to left, and parentheses form subexpressions that are evaluated entirely before they can be used.

For a longer example, here's an expression for the volume of a sphere with radius 2.

↗️
    (4÷3) × π × 2⋆3
-33.51032163829112
+33.510321638291124

The evaluation order is diagrammed below, with the function ⋆ at the highest level evaluated first, then × below it, and so on. The effect of the parentheses is that ÷ is evaluated before the leftmost ×.

-- cgit v1.2.3