Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rotation matrices in dataframes #21

Open
alisterburt opened this issue Oct 26, 2022 · 4 comments
Open

Rotation matrices in dataframes #21

alisterburt opened this issue Oct 26, 2022 · 4 comments

Comments

@alisterburt
Copy link
Member

Came up in discussion of #20 with @brisvag

I like the pattern used there of providing a utility function for generating the projection matrices rather than attempting to store them on the dataframe itself where they don't fit naturally

What do you think about using a similar pattern of using a utility function for generating the Rotation representation from a standard rep in the dataframe?

We should still have the constructor take in a Rotation object and deal with unstacking, this would get rid of the need for people to understand quite so much about the Rotation API and more easily follow its docs which don't deal with 'how to shove this thing into a dataframe' at all

@brisvag
Copy link
Contributor

brisvag commented Oct 26, 2022

We should still have the constructor take in a Rotation object and deal with unstacking

I'm not sure I follow; do you want to allow passing in both a Rotation and a specific euler angle convention, but then store it internally with euler angles? Or do you mean something else with standard rep?

What I meant was more that we should keep the Rotation internally (since it's the more convenient to pass around, as it's a single column, and it has the least amount of conventions to keep track of (except for matrices, which are however a pain to keep around) - but that we should have a function that takes that column of single rotations and spits out a matrix, for those who prefer to do calculations more manually rather than relying on the Rotation.__mul__ and similar.

@alisterburt
Copy link
Member Author

Okay so two main points:

  • I think that it's unclear what the Rotation objects operate on (coordinate order) (depends on how they are constructed)
  • constructing/using a compatible DF is annoying because of the stacking/unstacking

Together this makes the overhead a little higher than I would like for understanding/working with the data structure

I'm suggesting:

  • we move to storing some Euler angles in a specific convention on the dataframe, mainly for familiarity
  • we maintain the ability to construct the df via Rotation objects
  • we add the ability to construct the df via rotation matrices
  • we provide a utility function which generates a Rotation object from the df, document its use
  • we provide a utility function which generates rotation matrices from the df, document its use

@brisvag
Copy link
Contributor

brisvag commented Nov 2, 2022

I'm not a big fan of Yet Another Euler Angles Convention to deal with, but I see your points. I love working with Rotations, but originally I thought that getting them in or out of dataframes would be less tedious, and it's not... So yeah, I think I'm ok with the change!

@alisterburt
Copy link
Member Author

sweet! will leave this open and update the spec when I can, cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants