From b89fa02f528a26c58e32ba332074b6f73197ee26 Mon Sep 17 00:00:00 2001
From: Glen Whitney <glen@studioinfinity.org>
Date: Tue, 14 Oct 2025 12:42:51 -0700
Subject: [PATCH] chore: remove trailing whitespace outside of app-proto/src as
 well

---
 .forgejo/setup-trunk/action.yaml               | 2 +-
 .forgejo/workflows/continuous-integration.yaml | 4 ++--
 README.md                                      | 6 +++---
 app-proto/examples/irisawa-hexlet.rs           | 4 ++--
 app-proto/examples/kaleidocycle.rs             | 4 ++--
 app-proto/index.html                           | 2 +-
 notes/inversive.md                             | 4 ++--
 notes/theory.md                                | 9 ++++-----
 src/index.html                                 | 2 --
 9 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/.forgejo/setup-trunk/action.yaml b/.forgejo/setup-trunk/action.yaml
index 6007527..85e8a31 100644
--- a/.forgejo/setup-trunk/action.yaml
+++ b/.forgejo/setup-trunk/action.yaml
@@ -10,7 +10,7 @@ runs:
   using: "composite"
   steps:
     - run: rustup target add wasm32-unknown-unknown
-    
+
     # install the Trunk binary to `ci-bin` within the workspace directory, which
     # is determined by the `github.workspace` label and reflected in the
     # `GITHUB_WORKSPACE` environment variable. then, make the `trunk` command
diff --git a/.forgejo/workflows/continuous-integration.yaml b/.forgejo/workflows/continuous-integration.yaml
index f3b0130..6b53b3a 100644
--- a/.forgejo/workflows/continuous-integration.yaml
+++ b/.forgejo/workflows/continuous-integration.yaml
@@ -24,6 +24,6 @@ jobs:
       # workspace directory (action variable `github.workspace`, environment
       # variable `$GITHUB_WORKSPACE`):
       - uses: https://code.forgejo.org/actions/checkout@v4
-      
+
       - uses: ./.forgejo/setup-trunk
-      - run: RUSTFLAGS='-D warnings' cargo test
\ No newline at end of file
+      - run: RUSTFLAGS='-D warnings' cargo test
diff --git a/README.md b/README.md
index ac2771b..16b0d35 100644
--- a/README.md
+++ b/README.md
@@ -52,20 +52,20 @@ The latest prototype is in the folder `app-proto`. It includes both a user inter
 1. Use `sh` to run the script `tools/run-examples.sh`.
    - The script is location-independent, so you can do this from anywhere in the dyna3 repository.
    - The call from the top level of the repository is:
-     
+
      ```bash
      sh tools/run-examples.sh
      ```
    - For each example problem, the engine will print the value of the loss function at each optimization step.
    - The first example that prints is the same as the Irisawa hexlet example from the Julia version of the engine prototype. If you go into `engine-proto/gram-test`, launch Julia, and then execute
-     
+
      ```julia
      include("irisawa-hexlet.jl")
      for (step, scaled_loss) in enumerate(history_alt.scaled_loss)
        println(rpad(step-1, 4), " | ", scaled_loss)
      end
      ```
-     
+
      you should see that it prints basically the same loss history until the last few steps, when the lower default precision of the Rust engine really starts to show.
 
 ### Run the automated tests
diff --git a/app-proto/examples/irisawa-hexlet.rs b/app-proto/examples/irisawa-hexlet.rs
index 0d710ff..d7dd5fc 100644
--- a/app-proto/examples/irisawa-hexlet.rs
+++ b/app-proto/examples/irisawa-hexlet.rs
@@ -15,9 +15,9 @@ fn main() {
         for k in 4..9 {
             println!("  {} sun", 1.0 / config[(3, k)]);
         }
-        
+
         // print the completed Gram matrix
         print::gram_matrix(&config);
     }
     print::loss_history(&realization.history);
-}
\ No newline at end of file
+}
diff --git a/app-proto/examples/kaleidocycle.rs b/app-proto/examples/kaleidocycle.rs
index ae4eb07..4a9ad7e 100644
--- a/app-proto/examples/kaleidocycle.rs
+++ b/app-proto/examples/kaleidocycle.rs
@@ -14,7 +14,7 @@ fn main() {
         // print the completed Gram matrix and the realized configuration
         print::gram_matrix(&config);
         print::config(&config);
-        
+
         // find the kaleidocycle's twist motion by projecting onto the tangent
         // space
         const N_POINTS: usize = 12;
@@ -29,4 +29,4 @@ fn main() {
         let normalization = 5.0 / twist_motion[(2, 0)];
         println!("\nTwist motion:{}", (normalization * twist_motion).to_string().trim_end());
     }
-}
\ No newline at end of file
+}
diff --git a/app-proto/index.html b/app-proto/index.html
index 4fbe52f..c312b51 100644
--- a/app-proto/index.html
+++ b/app-proto/index.html
@@ -6,7 +6,7 @@
     <link data-trunk rel="css" href="main.css"/>
     <link href="https://fonts.bunny.net/css?family=fira-sans:ital,wght@0,400;1,400&display=swap" rel="stylesheet">
     <link href="https://fonts.bunny.net/css?family=noto-emoji:wght@400&text=%f0%9f%94%97%e2%9a%a0&display=swap" rel="stylesheet">
-    
+
     <!--
       the Charming visualization crate, which we use to show engine diagnostics,
       depends the ECharts JavaScript package
diff --git a/notes/inversive.md b/notes/inversive.md
index 933eb35..1d35e15 100644
--- a/notes/inversive.md
+++ b/notes/inversive.md
@@ -33,7 +33,7 @@ The unification of spheres/planes is indeed attractive for a project like Dyna3.
 Discussed coordinates with Alex Kontorovich. He was suggesting "inversive coordinates" -- for a sphere, that's 1/coradius, 1/radius, center/radius (where coradius is radius of sphere inverted in the unit sphere.) The advantage is tangent to and perpendicular to are linear in these coordinates (in the sense that if one is known, the condition of being tangent to or perpendicular to that one are linear). Planes have 1/radius = 0, and in fact, you can take the coordinates to be (2s, 0, x, y, z) where s is the distance to the origin and x,y,z are the normal direction. (Note the normal direction is only determined up to a scalar multiple. So could always scale so that the first non-zero coordinate is 1, or if you like only allow x, y to vary and let z be determined as sqrt(1-x^2^-y^2^). ) Points can be given by (r^2,1,x,y,z) where x,y,z are the coordinates and r is the distance to the origin. Quadratic form that tells you if something is a sphere/plane, or in the boundary, or up in the hyperbolic plane above. There are some details, but not quite explicit for modeling R^3, at http://sites.math.rutgers.edu/~alexk/files/LetterToDuke.pdf -- all this emphasize need to be agnostic with respect to geometric model so that we can experiment. Not really sure exactly how this relates or not to conformal geometric algebra, and whether it can be combined with geometric algebra. As formulated, there are clear-ish reps for planes/spheres and for points, but not as clear for lines. Have to see how to compute distance and/or specify a given distance. To combine inversive coordinates and geometric algebra, maybe think dually; there should be a lift from a normal vector and distance from origin to the five-vector; bivectors would rep circles/lines; trivectors would rep point pairs/points. What is the signature of this algebra, i.e. how many coordinates square to +1, -1, or 0? But it doesn't seem worth it for three dimensions, because there is a natural representation of points, as follows:
 
 The signature of Q will be (1,4), and in fact Q(I1,I2) = 1/2(ab+ba) - E1\dot E2, where a is the "first" or "coradius" coordinate, "b" is the "second" or "radius" coordinate, and E is the Euclidean part (x,y,z). Then the inversive coordinates of a sphere with center (x,y,z) and radius r will be I = (1/\hat{r},1/r,x/r,y/r,z/r) where \hat{r} = r/(|E|^2 -r^2). These coordinates satisfy Q(I,I) = -1. For this to make sense, of course r > 0, but we get planes by letting the radius of a tangent sphere to the plane go to infinity, and we get I = (2s, 0, x0, y0, z0) where (x0,y0,z0) is the unit normal to the plane and s is the perpendicular distance from the plane to the origin. Still Q(I,I) = -1.
-Since r>0, we can't represent individual points this way. Instead we will use some coordinates J for which Q(J,J) = 0. In particular, if you take for the Euclidean point E = (u,v,w) the coordinates J = (`|E|`^2,1,u,v,w) then Q(J,J) = 0 and moreover it comes out that Q(I,J) = 0 
+Since r>0, we can't represent individual points this way. Instead we will use some coordinates J for which Q(J,J) = 0. In particular, if you take for the Euclidean point E = (u,v,w) the coordinates J = (`|E|`^2,1,u,v,w) then Q(J,J) = 0 and moreover it comes out that Q(I,J) = 0
 whenever E lies on the sphere or plane described by some I with Q(I,I) = -1.
 The condition that two spheres I1 and I2 are tangent seems to be that Q(I1,I2) = 1. So given a fixed sphere, the condition that another sphere be tangent to it is linear in the coordinates of that other sphere.
 This system does seem promising for encoding points, spheres, and planes, and doing basic computations with them. I guess I would just encode a circle as the intersection of the concentric sphere and the containing plane, and a line as either a pair of points or a pair of planes (modulo some equivalence relation, since I can't see any canonical choice of either two planes or two points). Or actually as described below, there is a more canonical choice.
@@ -62,4 +62,4 @@ In the engine's coordinate conventions, a sphere with radius $r > 0$ centered on
 $$I'_s = \left(\frac{P_x}{r}, \frac{P_y}{r}, \frac{P_z}{r}, \frac1{2r}, \frac{\|P\|^2 - r^2}{2r}\right),$$
 which has the normalization $Q'(I'_s, I'_s) = 1$. The point $P$ is represented by the vector
 $$I'_P = \left(P_x, P_y, P_z, \frac{1}{2}, \frac{\|P\|^2}{2}\right).$$
-In the `engine` module, these formulas are encoded in the `sphere` and `point` functions.
\ No newline at end of file
+In the `engine` module, these formulas are encoded in the `sphere` and `point` functions.
diff --git a/notes/theory.md b/notes/theory.md
index 12190f1..77346b7 100644
--- a/notes/theory.md
+++ b/notes/theory.md
@@ -22,9 +22,10 @@ Jürgen also emphasized the need for an intuitive user interface. Notes on that
 His final mathematical advice was reasonably encouraging, however:
 
 "But still I would consider it all more or less doable. One should very precisely think about a doable scope.
-I think three things are essential for the math no matter what you exactly plan.
+I think three things are essential for the math no matter what you exactly
+plan.
 
-1. Think projectively, 
+1. Think projectively.
    Use Projective Geometry, Homogeneous Coordinates (or to a certain extent Quaternions, and Clifford Algebras, which are more or less an elegant way to merge Complex numbers with projective concepts.)
 2. Consider ambient complex spaces.
    The true nature of the objects can only be understood if embedded into a complex ambient space.
@@ -37,10 +38,8 @@ I think three things are essential for the math no matter what you exactly plan.
 
 It would be nice to see how Jürgen handled some of these issues in a 2D system that he designed. Unfortunately, Cinderella was and remains closed-source; it was distributed for profit for some stretch of time. However, (a part of?) it was reimplemented in JavaScript as CindyJS, which is open source. I took a relatively quick look at that source code at one point, and these were my observations:
 
-CindyJS uses very concrete basic objects: 2D points are represented via projective geometry as a list of three floating-point numbers, and everything is done numerically.  There are no symbolic representations or exact algebraic numbers. (Not sure how a point on a circle or line is handled, that would take further investigation.) 
+CindyJS uses very concrete basic objects: 2D points are represented via projective geometry as a list of three floating-point numbers, and everything is done numerically.  There are no symbolic representations or exact algebraic numbers. (Not sure how a point on a circle or line is handled, that would take further investigation.)
 
 Lines are given by explicit coordinates as well (not sure of the internal details/exact coordinatization, or of how a "LineThrough" is represented).
 
 Was unclear to me how the complex parametrization for preserving continuity was handled in the code, even though Jürgen harps on complex ambient spaces; where are the complex numbers? Perhaps that part of Cinderella was never re-implemented?
-
-
diff --git a/src/index.html b/src/index.html
index 0a5fa60..d4b529f 100644
--- a/src/index.html
+++ b/src/index.html
@@ -7,5 +7,3 @@
   <body><script type="module" src="dyna3.js"></script>
   </body>
 </html>
-
-