pyxem
Purpose for neo_eulerian classes
General new-to-orix question, while thinking about code simplification:
What is the purpose of the neo_eulerian classes in vector/neo_euler.py? All of Orix's math, by design, is done with quaternions. As such, it seems their only purpose would be for to/from statements, or to make plotting/visualization easier.
However, @hakonanes already wrote all the to/froms in quaternion/_conversions.py, so adding all the to/from statements directly to Quaternions would be incredibly easy. Similarly, any axis/angle plots could do the conversions when they are needed, instead of requiring a Homochoric or 'Rodriquez` class object.
Bonus from a simplicity standpoint: Doing this eliminates 4 class objects, 143 lines of code, and (maybe most importantly?) makes sure all the to/from functions use the same conversion code from _conversions.py. Would also eliminate the use case of "can we provide support for Homochoric to/from Rodrigues in the Homochoric and Rodrigues classes" and similar such problems, since Quaternion will just always be the de-facto in between.
I think the agree with almost everything you've said here. It made sense at one point to have these as a number of separate public classes, but at this point hiding that functionality away within the plotting code seems sensible.
wrote all the to/froms in quaternion/_conversions.py
The conversions taken from Rowenhorst et al. (2015) were added to get cubochoric sampling of orientations (taken from Singh and De Graef [2016]) in orix, which we needed in kikuchipy for EBSD dictionary indexing. The conversions are private, not ment to be used by a user. However, I would like to make them public in a clean way in the API and without sacrificing speed.
adding all the to/from statements directly to
Quaternions
How would you implement this? We can either go via the quaternion, as in Quaternion.from_axes_angles(ax).to_homochoric() requiring two steps, or Quaternion.axes_angles_to_homochoric(ax) in one step (how to name the methods can be discussed elsewhere). I don't see a drawback in supporting both.
We can either go via the quaternion, as in Quaternion.from_axes_angles(ax).to_homochoric()
I planned on doing it this way, but only because that's how scipy.spatial.transform.Rotations does it, so it's the way I am used to thinking of calling the functions. Bonus though, this way it's only 10 functions, as opposed to the (I believe?) 42 you would need to do all the conversions from Rowenhorst et al. (2015) Table 2.
I also planned on the from functions being class methods, and the to functions returning numpy arrays of the data.
Right, 42 is a high number, let's stick to the class methods (👍🏻) and those returning arrays!
Coming back to this after a break. As part of this and as a precursor to #345, and #254, best path forward seems to be to add the following jit-accelerated "aa2bb" functions from the 2015 rowenhorst paper.
- qu2eu
- qu2om
- qu2ax
- qu2ro
- qu2ho
- om2qu
- ro2qu
This will allow for all the to_quat/from_quat functions for all 7 representations. I'm going to start this but if anyone has contradicting feedback, feel free to chime in.
Sounds good to me!
I think we should only implement the conversions we need, though. By "need" I mean those conversions that we actually find ourselves (!) wanting when doing every day work. Not those that would be nice to have for completeness. For example, the existing conversions in orix/quaternion/_conversions.py are all used in the cubochoric sampling which we needed for dictionary indexing in kikuchipy. This is why not all conversions were implemented.
Any new conversions should be placed alongside the existing ones in orix/quaternion/_conversions.py.