Ragged Vectors and Orix

[CSSFrancis]

@hakonanes @argerlt @tinabe I'm curious on your thoughts on some (larger) changes to the underlying strucuture of data stored in orix.

The (big) problem is that a lot of the operations and data in orix would be widely useful in different packages like pyxem, diffsims, py4dstem etc but all of those packages require a ragged data strucuture or more truely n dimensional objects.

For example consider in diffsims where we have a ReciprocalLatticeVector. For a simulation of different orientations we return a list of ReciprocalLatticeVector objects but we could just as easily return a ragged array with a shape (num_simulations, ragged (num vectors per sim), 3).

For something like pyxem, when we find diffraction peaks these diffraction peaks are essentially two dimensional slices in the full 3D reciporical space and it would be nice to be able to efficiently rotate them using orix. Same with orientation mapping, it would be nice to be able to have the pyxem results for orientation mapping to be a crystal map where you could do something like restrict the results to only return orientations close to some zone axis etc.

I was thinking about implementing something like https://docs.pytorch.org/docs/stable/nested.html where data is stored like:

This would be a lightweight package that Hyperspy, orix, pyxem could depend on and could easily be replaced with the pytorch version if people want to do more intensive ML.