noTrailingWhitespace

glen commented

2025-10-10 17:24:19 +00:00

Owner

This is on top of #118, and so looks crazy until that merges and this is rebased on top of that. This PR consists only of removing trailing whitespace, and inserting the "missing" newlines at the ends of files.

glen added 7 commits 2025-10-10 17:24:19 +00:00

feat: Point coordinate regulators

/ test (pull_request) Successful in 3m35s

Details

ecbbe2068c

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.)

chore: typographical improvements per review

/ test (pull_request) Successful in 3m45s

Details

46ffd6c285

Streamline axis naming 27edbfb010

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.

Spruce up formatting and error messages

/ test (pull_request) Successful in 3m43s

Details

adc60ac5c1

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.

Revert "Spruce up formatting and error messages"

/ test (pull_request) Successful in 3m40s

Details

c081f1a809

This reverts commit adc60ac5c1. We decided
that it would be better for me to request formatting changes one by one.

chore: uniformize error messages, 80-char lines, import fmt::Display

/ test (pull_request) Successful in 3m48s

Details

c0e6ebf3d6

chore: remove trailing whitespace, add CR at end of file

/ test (pull_request) Successful in 3m40s

Details

11a7b75d0f

glen referenced this pull request

2025-10-10 17:32:23 +00:00

feat: Point coordinate regulators #118

glen force-pushed noTrailingWhitespace from 11a7b75d0f to 3405797d14

2025-10-11 01:09:03 +00:00

Compare

glen referenced this pull request

2025-10-11 05:36:13 +00:00

chore: wrap at 80 characters #128

glen force-pushed noTrailingWhitespace from 3405797d14 to a4101ab81c

2025-10-11 05:59:04 +00:00

Compare

Vectornaut commented

2025-10-13 23:05:38 +00:00

Member

My Files changed tab still seems to be showing a diff with pull request #117 (commit 978f70a), even though pull request #118 (commit 2c8c09d) has now been merged into main. Any idea how to correct that?

My *Files changed* tab still seems to be showing a diff with pull request #117 (commit 978f70a), even though pull request #118 (commit 2c8c09d) has now been merged into `main`. Any idea how to correct that?

glen commented

2025-10-13 23:10:18 +00:00

Author

Owner

dunno. I need to rebase this on main. Until I do, I wouldn't trust anything it says. Rebasing and will force-push this pull request momentarily.

👍 1

glen closed this pull request

2025-10-13 23:12:19 +00:00

/ test (pull_request) Successful in 3m38s

Required

Details

Pull request closed

Please reopen this pull request to perform a merge.

Rows
Columns

noTrailingWhitespace #126

Pull request closed