I'm convinced that the scmutils code used to implement the ideas in "Functional Differential Geometry" doesn't have the final say on the best API for differential geometry. I'm going to leave notes throughout the namespace suggesting ways that we might make it better; please take these as challenges and erase the notes as you make improvements!
Big TODO items:
manifold
and patch
should be protocols, so that manifolds, patches and coordinate systems can report their manifold, and patches and coordinate systems can report their patch. point
can report its manifold too. Once this change is made, transfer-point
should use the manifold
protocol to simplify its implementation. (NOTE that manifold
now works on coordsys and manifolds, but not yet on patches.)
patch
, manifold
and point
should be defrecords, so that they can implement the protocols above in different ways. We can also implement dimension
correctly.
make-patch
should return a patch template; only when you specialize the manifold, or retrieve the patch FROM the specialized manifold with get-patch
should you actually build the defrecord.
the original codebase assigns a UUID to each manifold specialized off a family. Is this a good idea?
coordinate systems now use a UUID in the protocol; this feels like a code smell. This exists so that coordinate prototypes can live in metadata, and can be changed without affecting equality of coordinate systems. BUT reconsider this design!
coordinate systems have many more functions like access-chains
, dual-chains
, coordinate-basis
and friends. These are missing, and SHOULD go into coordinate.cljc.
Basically caching functions that can do these transformations for a coordinate system should live in one spot.
it feels like ICoordinateSystem
WANTS to live in coordinate.cljc
... but maybe not. I have a sense that we're a bit tangled.
keeping caches inside the points feels wrong. Can we just cache the function itself?
There is a huge amount of repetition between the different coordinate system definitions! There is clearly a smaller protocol that would work, like point->coords
and coords->point
, plus maybe the validator. my-manifold-point?
does all the work for point checking, and we can compose with a coordinate system defrecord to return manifold
, patch
and prototype.
If we do this it'll make it easier to memoize just these smaller functions, and keep an outer point->coords
that can memoize the internal thing.
TODO: document all of the coordinate systems at the bottom of the page!
TODO: more tests of all of the new accessor functions. See Codecov for what
to do here.
Okay, on to the business.
Manifolds like R1, R2, S1, S2 etc are specialized versions of "manifold templates" like Rn and Sn. We call these "manifold families", while scmutils calls these "manifold types".
NOTE: rather than taking a name-format
string, make-manifold-family
should take a function of the single dimension argument.
NOTE: the original scmutils codebase keeps a :distinguished-points
list inside the manifold family. This isn't used anywhere in the book or codebase. Keep an eye out and either implement or delete this note.
Coordinate systems are added to coordinate patches. A coordinate system is an invertible map from the space to R^n (or C^n or H^n, depending on the field over which the manifold's defined!)
This section defines constructors and accessors for non-coordinate-constrained points on some manifold.
This section defines many instances of [[ICoordinateSystem]].
This section binds many common manifold families and coordinate systems for use. Enjoy!
The surface of a sphere, specialized to two dimensions. See [[S2p]] for the 2 dimensional specialization of S(n).
The :tilted
patch rotates the north pole 90 degrees toward the positive y axis.
TODO is south pole right??
Points are represented by 3x3 (down (up ...) ...)
There is only one instance of an SOn manifold defined, SO3. As a consequence the name is not SOn but rather SO3-type.