StudioInfinity/dyna3
2
0
Fork 1
Code Issues 56 Pull requests 1 Projects 3 Releases 4 Wiki Activity Actions

Dispatch normalization routines correctly #87

Merged
glen merged 4 commits from Vectornaut/dyna3:dispatch-normalization into main 2025-06-04 21:01:14 +00:00
Conversation 9 Commits 4 Files changed 3 +14 -13
2 changed files with 14 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit f332f755e0 - Show all commits

19
app-proto/src/assembly.rs
View file

@ -18,9 +18,9 @@ use crate::{
Q, Q,
change_half_curvature, change_half_curvature,
local_unif_to_std, local_unif_to_std,
normalize_mut_point,
normalize_mut_sphere,
point, point,
project_point_to_normalized,
project_sphere_to_normalized,
realize_gram, realize_gram,
sphere, sphere,
ConfigSubspace, ConfigSubspace,
@ -108,8 +108,9 @@ pub trait Element: Serial + ProblemPoser + DisplayItem {
// element is responsible for keeping this set up to date // element is responsible for keeping this set up to date
fn regulators(&self) -> Signal<BTreeSet<Rc<dyn Regulator>>>; fn regulators(&self) -> Signal<BTreeSet<Rc<dyn Regulator>>>;
glen marked this conversation as resolved Outdated
glen commented 2025-05-30 00:26:00 +00:00
Outdated
Copy link

Do you like the word "normalize" or "canonicalize"? I feel like the latter more explicitly means "choose the favored representative of an equivalence class" (which I think is mainly what's going on here) and the former can have broader meanings in which the entity is actually changed, like when you find a unit vector in the same direction -- I think that's sometimes called normalization. Only make a change if you feel like "canonicalize" would be a better/clearer choice.

Do you like the word "normalize" or "canonicalize"? I feel like the latter more explicitly means "choose the favored representative of an equivalence class" (which I think is mainly what's going on here) and the former can have broader meanings in which the entity is actually changed, like when you find a unit vector in the same direction -- I think that's sometimes called normalization. Only make a change if you feel like "canonicalize" would be a better/clearer choice.
Vectornaut commented 2025-05-30 00:46:35 +00:00
Outdated
Copy link

In my mind, an element is represented by a line through the origin in \mathbb{R}^{4,1}, so choosing a favored representative is equivalent to choosing a particular scaling. That's why I used the word "normalization." However, the implementation of normalize_rep_mut for spheres actually changes the equivalence class. That's because the only thing we use normalize_rep_mut for right now is to keep elements normalized during nudging, and normalizing in a way that preserves the equivalence class makes nudging less stable. If both "normalize" and "canonicalize" imply staying within an equivalence class for you, then maybe we need another term entirely.

In my mind, an element is represented by a line through the origin in $\mathbb{R}^{4,1}$, so choosing a favored representative is equivalent to choosing a particular scaling. That's why I used the word "normalization." However, the implementation of `normalize_rep_mut` for spheres actually changes the equivalence class. That's because the only thing we use `normalize_rep_mut` for right now is to keep elements normalized during nudging, and normalizing in a way that preserves the equivalence class makes nudging less stable. If both "normalize" and "canonicalize" imply staying within an equivalence class for you, then maybe we need another term entirely.
glen commented 2025-05-30 20:47:03 +00:00
Outdated
Copy link

Ah, hmm, I hadn't appreciated that the result of normalize_rep_mut might be in a different equivalence class. "Normalize" does not by itself connote "stay in the same equivalence class, but "normalize representation" does seem to imply strongly that we are just choosing a different representation of the same entity. So I would agree the name needs to change -- but just "normalize" without the "representation" would be OK, since we're not just picking a different representation of the same geometric entity. If you don't like that, perhaps "stabilize" or "standardize" or "choose_canonical" or "nearby_canonical" or something?

Ah, hmm, I hadn't appreciated that the result of normalize_rep_mut might be in a different equivalence class. "Normalize" does not by itself connote "stay in the same equivalence class, but "normalize representation" does seem to imply strongly that we are just choosing a different representation of the same entity. So I would agree the name needs to change -- but just "normalize" without the "representation" would be OK, since we're not just picking a different representation of the same geometric entity. If you don't like that, perhaps "stabilize" or "standardize" or "choose_canonical" or "nearby_canonical" or something?
Vectornaut commented 2025-05-30 21:19:52 +00:00
Outdated
Copy link

How about something like proj_to_normalized, to communicate that we're projecting the given representation vector to the normalized configuration variety for the given element type?

So I would agree the name needs to change -- but just "normalize" without the "representation" would be OK, since we're not just picking a different representation of the same geometric entity.

The rep isn't working as intended in the name normalize_rep_mut anyway. I added it to emphasize that this method acts on the representation vector provided as an argument, not the vector representing the element the method is called from. This makes it different from the normalize_mut methods for nalgebra matrices.

(Using an associated function instead of a method would be the best way to clarify this, but I don't think it's possible to call associated functions from trait objects. This complaint about the limitation and this unsuccessful attempt to lift the limitation seem to demonstrate that it exists, or at least used to exist. If you want, though, I can try again to use an associated function and look at exactly what compiler error it produced.)

How about something like `proj_to_normalized`, to communicate that we're projecting the given representation vector to the normalized configuration variety for the given element type? > So I would agree the name needs to change -- but just "normalize" without the "representation" would be OK, since we're not just picking a different representation of the same geometric entity. The `rep` isn't working as intended in the name `normalize_rep_mut` anyway. I added it to emphasize that this method acts on the representation vector provided as an argument, not the vector representing the element the method is called from. This makes it different from the [`normalize_mut`](https://docs.rs/nalgebra/latest/nalgebra/base/type.DMatrix.html#method.normalize_mut) methods for nalgebra matrices. (Using an associated function instead of a method would be the best way to clarify this, but I don't think it's possible to call associated functions from trait objects. [This complaint](https://users.rust-lang.org/t/trait-object-safety-still-confuses-me/39699/4) about the limitation and [this unsuccessful attempt](https://github.com/rust-lang/rfcs/pull/2886) to lift the limitation seem to demonstrate that it exists, or at least used to exist. If you want, though, I can try again to use an associated function and look at exactly what compiler error it produced.)
glen commented 2025-06-01 02:50:17 +00:00
Outdated
Copy link

Sure, any of project_to_canonical or project_to_normal or project_to_normalized or canonical_projection or normal_projection would be fine, whatever seems simplest/clearest to you. I'd suggest that with a name that's already this long, there's no point in abbreviating with proj -- just use whatever full word proj would be an abbreviation for. Using a method is fine, don't worry about the associated function thing.

Sure, any of `project_to_canonical` or `project_to_normal` or `project_to_normalized` or `canonical_projection` or `normal_projection` would be fine, whatever seems simplest/clearest to you. I'd suggest that with a name that's already this long, there's no point in abbreviating with `proj` -- just use whatever full word `proj` would be an abbreviation for. Using a method is fine, don't worry about the associated function thing.
Vectornaut commented 2025-06-01 17:52:21 +00:00
Outdated
Copy link

I just pushed a commit with better names (54b34e0582). My look-over before pushing was a bit cursory; I'll look at it harder later today.

I just pushed a commit with better names (`54b34e0582`). My look-over before pushing was a bit cursory; I'll look at it harder later today.
Vectornaut commented 2025-06-01 23:11:04 +00:00
Outdated
Copy link

I've looked at the renaming commit again and I still think it's fine, so let me know what you think!

I've looked at the renaming commit again and I still think it's fine, so let me know what you think!
// normalize a representation vector for this kind of element // project a representation vector for this kind of element onto its
fn normalize_mut_rep(&self, rep: &mut DVector<f64>); // normalization variety
fn project_to_normalized(&self, rep: &mut DVector<f64>);
// the configuration matrix column index that was assigned to the element // the configuration matrix column index that was assigned to the element
// last time the assembly was realized, or `None` if the element has never // last time the assembly was realized, or `None` if the element has never
@ -225,8 +226,8 @@ impl Element for Sphere {
self.regulators self.regulators
} }
fn normalize_mut_rep(&self, rep: &mut DVector<f64>) { fn project_to_normalized(&self, rep: &mut DVector<f64>) {
normalize_mut_sphere(rep); project_sphere_to_normalized(rep);
} }
fn column_index(&self) -> Option<usize> { fn column_index(&self) -> Option<usize> {
@ -321,8 +322,8 @@ impl Element for Point {
self.regulators self.regulators
} }
fn normalize_mut_rep(&self, rep: &mut DVector<f64>) { fn project_to_normalized(&self, rep: &mut DVector<f64>) {
normalize_mut_point(rep); project_point_to_normalized(rep);
} }
fn column_index(&self) -> Option<usize> { fn column_index(&self) -> Option<usize> {
@ -789,7 +790,7 @@ impl Assembly {
// step the element along the deformation and then // step the element along the deformation and then
// restore its normalization // restore its normalization
*rep += motion_proj.column(column_index); *rep += motion_proj.column(column_index);
elt.normalize_mut_rep(rep); elt.project_to_normalized(rep);
}, },
None => { None => {
console_log!("No velocity to unpack for fresh element \"{}\"", elt.id()) console_log!("No velocity to unpack for fresh element \"{}\"", elt.id())

8
app-proto/src/engine.rs
View file

@ -35,9 +35,9 @@ pub fn sphere_with_offset(dir_x: f64, dir_y: f64, dir_z: f64, off: f64, curv: f6
]) ])
} }
// normalize a sphere's representation vector by contracting toward the last // project a sphere's representation vector to the normalization variety by
// coordinate axis // contracting toward the last coordinate axis
pub fn normalize_mut_sphere(rep: &mut DVector<f64>) { pub fn project_sphere_to_normalized(rep: &mut DVector<f64>) {
let q_sp = rep.fixed_rows::<3>(0).norm_squared(); let q_sp = rep.fixed_rows::<3>(0).norm_squared();
let half_q_lt = -2.0 * rep[3] * rep[4]; let half_q_lt = -2.0 * rep[3] * rep[4];
let half_q_lt_sq = half_q_lt * half_q_lt; let half_q_lt_sq = half_q_lt * half_q_lt;
@ -46,7 +46,7 @@ pub fn normalize_mut_sphere(rep: &mut DVector<f64>) {
} }
// normalize a point's representation vector by scaling // normalize a point's representation vector by scaling
pub fn normalize_mut_point(rep: &mut DVector<f64>) { pub fn project_point_to_normalized(rep: &mut DVector<f64>) {
rep.scale_mut(0.5 / rep[3]); rep.scale_mut(0.5 / rep[3]);
} }