search

kvark / mint

Math Interoperability Types
MIT License
256 stars 20 forks source link

Bivector and Rotor #33

Open kvark opened 6 years ago

kvark commented 6 years ago

Fixes #32

There is a few issues I'd like us to resolve before we settle on something:

  1. dimensionality: does it make sense to have Bivector3 instead of Bivector here, and similarly for Rotor?
    • there is hardly any use for other dimensions, hence I think we can avoid the number suffixes
  2. notation: is xy/xz/yz the only used notation for bi-vectors? How should rotor fields be called? The current "s" and "b" are just random, basically.
  3. consistency with quaternions: does anything need to be done about the fact that the vector part of a quaternion has the type of Vector3? It isn't really a vector, much closer to bi-vector, in which case people just need to use Rotor anyway. Perhaps, the Quaternion type shouldn't be written in the vector form at all to avoid confusion.
kvark commented 6 years ago

r? @nical @Ralith

Ralith commented 6 years ago

does it make sense to have Bivector3 instead of Bivector here, and similarly for Rotor?

There's definitely a case for a Rotor2: 2D rotations that have singular representations and well-defined precision are nice. nalgebra already has the very similar UnitComplex type for this exact reason.

I'm less sure of the usefulness of a Bivector2. If mint might ever support dimensionalities > 3, consistency wouldn't hurt.

consistency with quaternions

I'm not sure what "much closer to" means. It does seem like it might have been best to define quaternions with s/i/j/k members. Not sure that's worth breaking compatibility.

aloucks commented 4 years ago

Can we put the scalar at the end of Rotor to match the updated Quaternion

Related: https://github.com/kvark/mint/pull/50