Paddy Harrison

Thanks both for your inputs and advice! I am wondering then whether there is a strong feeling to sticking towards the MTEX behaviour (may be useful for onboarding) or NumPy...

This is a very good idea!

Copying this [comment](https://github.com/pyxem/orix/pull/340#issuecomment-1128775422) here for clarity in the discussion: > Related to https://github.com/pyxem/orix/issues/338, __annotations__ within the future package was only introduced in Python 3.7, hence the CI Python 3.6 build...

> Given that Python 3.6 is deprecated we should probably stop testing for it? This could be an option. We could bump the minimum version to Python 3.7, which is...

Sounds like a good plan to me!

@maclariz could you provide the original orientation data before calling `map_into_reduced_symmetry_zone()`? Also the `symmetry`?

So if I run: ```python o = Orientation([[ 0.5101, -0.0107, 0.0421, -0.859 ], [ 0.5114, -0.0107, 0.0421, -0.8582], [ 0.2451, -0.0222, 0.0373, -0.9685], [ 0.2455, -0.016 , 0.0368, -0.9686], [...

> And yeah, as a general FYI, we are trying to recreate a very specific piece of software that exists in MTEX but not in python, and Orix was agreed...

I agree with adding Dask for these demanding tasks, certainly functions that involve `outer` products. Do you think we should also do the same for `dot()`? I was thinking about...

> I agree when the user is an end user. When the user is another package, like kikuchipy, diffsims or pyxem, where, say, we wanted to get dot products or...