Make the data types of element representations opaque to the `assembly` module #90

New issue

Open

opened 2025-06-04 22:47:22 +00:00 by Vectornaut · 0 comments

Vectornaut commented

2025-06-04 22:47:22 +00:00

Member

We'd like to keep engine-specific code within the engine module as much as possible. Up through pull request #87, we've allowed engine-specific details to leak into the assembly module by assuming that each element is represented by a DVector<f64>. Upcoming elements, like lines, will violate this assumption, so now is a good time to redesign the assembly module so that it no longer needs to know which data types we use to represent elements.

A question to keep in mind

When an element has a "compound representation," how do we decide whether that detail is engine-independent enough to use outside the engine module? To see how the decision might depend on how things are implemented, consider the following ways of representing a line segment:

A pair of points (seems pretty engine-independent).
A basis for a 2d subspace of \mathbb{R}^{4,1} (much more engine-specific).

Proposed redesign

In the `engine` module

Introduce a new ElementRepresentation trait, and new SphereRepresentation and PointRepresentation structures that implement it. In the future, we might also want to implement ElementRepresentation for compound representation types, like [PointRepresentation].

In the `assembly` module

Change the Element trait in one of these ways:

Make it generic over a representation type that implements ElementRepresentation.
Change the return type of its representation method to something like Signal<dyn ElementRepresentation>.

Change the type of the representation field to:

Signal<SphereRepresentation> in the Sphere structure.
Signal<PointRepresentation> in the Point structure.

If we can implement ElementRepresentation for compound representation types, as expected, we could also eventually have a field type like Signal<[PointRepresentation; 3]> for a hypothetical Triangle structure. This would make it clear that we don't have perfect redundancy between element and representation structures.

Move the engine-specific parts of the ProblemPoser implementations into the engine module. Some ideas about how:

Implement ProblemPoser for both Sphere and SphereRepresentation, letting Sphere partially or fully forwards calls to pose. Treat other element and representation structures similarly.
Make engine::ElementRepresentation a subtrait of ProblemPoser and call pose on whatever an element's representation method returns.

We'd like to keep engine-specific code within the `engine` module as much as possible. Up through pull request #87, we've allowed engine-specific details to leak into the `assembly` module by assuming that each element is represented by a `DVector<f64>`. Upcoming elements, like lines, will violate this assumption, so now is a good time to redesign the `assembly` module so that it no longer needs to know which data types we use to represent elements. ### A question to keep in mind When an element has a "compound representation," how do we decide whether that detail is engine-independent enough to use outside the `engine` module? To see how the decision might depend on how things are implemented, consider the following ways of representing a line segment: - A pair of points (seems pretty engine-independent). - A basis for a 2d subspace of $\mathbb{R}^{4,1}$ (much more engine-specific). ### Proposed redesign #### In the `engine` module Introduce a new `ElementRepresentation` trait, and new `SphereRepresentation` and `PointRepresentation` structures that implement it. In the future, we might also want to implement `ElementRepresentation` for compound representation types, like `[PointRepresentation]`. #### In the `assembly` module Change the `Element` trait in one of these ways: - Make it generic over a representation type that implements `ElementRepresentation`. - Change the return type of its `representation` method to something like `Signal<dyn ElementRepresentation>`. Change the type of the `representation` field to: - `Signal<SphereRepresentation>` in the `Sphere` structure. - `Signal<PointRepresentation>` in the `Point` structure. If we can implement `ElementRepresentation` for compound representation types, as expected, we could also eventually have a field type like `Signal<[PointRepresentation; 3]>` for a hypothetical `Triangle` structure. This would make it clear that we don't have perfect redundancy between element and representation structures. Move the engine-specific parts of the `ProblemPoser` implementations into the `engine` module. Some ideas about how: - Implement `ProblemPoser` for both `Sphere` and `SphereRepresentation`, letting `Sphere` partially or fully forwards calls to `pose`. Treat other element and representation structures similarly. - Make `engine::ElementRepresentation` a subtrait of `ProblemPoser` and call `pose` on whatever an element's `representation` method returns.