chore: remove trailing whitespace outside of app-proto/src as well

chore: remove trailing whitespace, add CR at end of file
chore: Hopefully final formatting items from review
2025-10-14 12:42:51 -07:00 · 2025-10-13 16:25:27 -07:00 · 2025-10-13 16:25:27 -07:00 · 2025-10-13 16:25:25 -07:00 · 2025-10-13 16:24:38 -07:00 · 2025-10-13 16:22:39 -07:00
20 changed files with 337 additions and 341 deletions
--- a/app-proto/src/assembly.rs
+++ b/app-proto/src/assembly.rs
@ -518,7 +518,6 @@ impl ProblemPoser for HalfCurvatureRegulator {
 #[derive(Clone, Copy, Sequence)]
 pub enum Axis { X = 0, Y = 1, Z = 2 }
 impl Axis {
    fn name(&self) -> &'static str {
        match self { Axis::X => "X", Axis::Y => "Y", Axis::Z => "Z" }
--- 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.
@ -42,5 +43,3 @@ CindyJS uses very concrete basic objects: 2D points are represented via projecti
 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?
--- a/src/index.html
+++ b/src/index.html
@ -7,5 +7,3 @@
  <body><script type="module" src="dyna3.js"></script>
  </body>
 </html>
Author	SHA1	Message	Date
Glen Whitney	b89fa02f52	chore: remove trailing whitespace outside of app-proto/src as well All checks were successful / test (pull_request) Successful in 3m41s Details	2025-10-14 12:42:51 -07:00
Glen Whitney	3635abc562	chore: remove trailing whitespace, add CR at end of file All checks were successful / test (pull_request) Successful in 3m41s Details	2025-10-13 16:25:27 -07:00
Glen Whitney	a4b355d943	chore: Hopefully final formatting items from review	2025-10-13 16:25:27 -07:00
Glen Whitney	d68f0d2b15	chore: revert 80-character limit, reorder and rename index message helper	2025-10-13 16:25:25 -07:00
Glen Whitney	040b080d2b	chore: uniformize error messages, 80-char lines, import fmt::Display	2025-10-13 16:24:38 -07:00
Aaron Fenyes	1f604eb29a	Revert "Spruce up formatting and error messages" This reverts commit `adc60ac5c1`. We decided that it would be better for me to request formatting changes one by one.	2025-10-13 16:22:39 -07:00
Aaron Fenyes	5ee24aa91d	Spruce up formatting and error messages Make the new code's formatting and error messages more consistent with the previous code. I don't necessarily have a strong preference for the previous conventions, but I do like stuff to be consistent.	2025-10-13 16:21:56 -07:00
Aaron Fenyes	6ad3ed1176	Streamline axis naming This makes it simpler, from the programmer's perspective, to get the name of an axis as a string slice and to format an axis name into a string. To me, the matching method `Axis::name` seems more direct than the explicit lookup table that it replaces, and I'm hoping that it will be about as easy for the compiler to inline, or even easier. Implementing `Display` enables us to hand an `Axis` to a string formatter without any explicit conversion. It adds extra code in the short run, but I'd expect it to simplify our code in the long run by fitting into the conventions set by the Rust standard library.	2025-10-13 16:21:11 -07:00
Glen Whitney	a614098b22	chore: typographical improvements per review	2025-10-13 16:19:53 -07:00
Glen Whitney	af6c40817f	feat: Point coordinate regulators Implements regulators for the Euclidean coordinates of Point entities, automatically creating all three of them for each added point entity. When such a regulator is set, it freezes the corresponding representation coordinate to the set point. In addition, if all three coordinates of a given Point are set, the coradius coordinate (which holds the norm of the point) is frozen as well. Note that a PointCoordinateRegulator must be created with a Point as the subject. This commit modifies HalfCurvatureRegulator analogously, so that it can only be created with a Sphere. A couple of prospective issues that should be filed in association with this commit: * The new coordinate regulators create redundant display information with the raw representation coordinates of a point that are already shown in the outline view. * The optimization status of these regulators together with HalfCurvature regulators (i.e., the ones implemented by freezing coordinates) is different from InversiveDistance regulators when an Assembly is unrealizable: the frozen-coordinate constraints will be "hard" in that they will be forced to precisely equal their set point, whereas the distance regulators are "soft" in that they can be relaxed from their set points in an effort to minimize the loss function of the configuration as compared to the values of the constraints. Perhaps at some point we should/will have a mechanism to specify the softness/hardness of constraints, but in the meantime, there should not be two different categories of constraints. Suppose we decide that by default that all constraints are soft. Then the optimizer should be able to search changing, for example, the radius of a curvature-constrained sphere, so as to minimize the loss function (for a loss that would therefore presumably have a term akin to the square of the difference between the specified and actual half-curvature of the sphere). For example, suppose you specify that the half-curvature of a sphere is 1 (so it has radius 1/2) but that its distance to a point is -1. These constraints cannot be satisfied, so the optimization fails, presumably with the point at the sphere center, and the sphere with radius 1/2. So all of the loss is concentrated in the difference between the actual point-sphere distance being -1/2, not -1. It would be more appropriate (in the all-soft constraint regime) to end up at something like a sphere of half-curvature 1/√2 with the point at the center, so that the loss is split between both the half-curvature and the distance to the sphere being off by 1 - 1/√2. (At a guess, that would minimize the sum of the squares of the two differences.)	2025-10-13 16:18:29 -07:00