On `Vector3d` multiplication etc.

[harripj]

It appears that default behaviour when using Vector3d.__mul__ etc is inconsistent with NumPy.

For example (from the tests):

>>> from orix.vector import Vector3d

>>> vector, other, expected = [1, 2, 3], (-1, 2), [[-1, -2, -3], [2, 4, 6]]
>>> vector = Vector3d(vector)

>>> vector * other
Vector3d (2,)
[[-1 -2 -3]
 [ 2  4  6]]

This is actually an outer product, and I think it would be more clear if it was calculated using Vector3d.outer(). The calculation is not possible in NumPy:

>>> vector.data * other
ValueError: operands could not be broadcast together with shapes (1,3) (2,) 

By contrast I expected the following to work, but it doesn't in orix:

>>> v =  Vector3d(np.random.randn(10, 3)).unit
>>> other = (-1, 1, -1)
>>> v * other
ValueError: operands could not be broadcast together with shapes (10,3) (3,1)

>>> # works using NumPy broadcasting
>>> v.data * other
array([[-0.75429277,  0.61845104, -0.22036497],
       [ 0.40941557,  0.61780058, -0.67134293],
       [-0.30999649, -0.31005951,  0.89875763],
       [ 0.29270828,  0.30189513, -0.90729333],
       [ 0.80419124, -0.58415542,  0.10972185],
       [ 0.35877186, -0.3378907 , -0.87012219],
       [ 0.90080509, -0.02409169,  0.43355481],
       [ 0.68963364, -0.67320866,  0.26682493],
       [-0.4831369 ,  0.83127793,  0.27487405],
       [-0.14577608,  0.75183165,  0.64303849]])

I am wondering what are the use cases for this design choice, and whether it would be better if this behaviour was consistent with NumPy?

[hakonanes]

Hm, I don't know the reasoning for the design choice, and I'm in favour of changing it to work similar to NumPy broadcasting.

Might be worth keeping the discussion in #140 in mind if we rewrite these operations.

[pc494]

Might also be worth checking how MTEX treats these objects as a lot of the early implementations follow their patterns...

[harripj]

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 behaviour (for users used to Python programming)? My feeling would be the latter as I think people would expect behaviour consistent with NumPy, as orix is a Python library, but realize there may be differing views.

[hakonanes]

I agree that orix should be consistent with NumPy.

[pc494]

numpy seem better to me, I've just found "what would MTEX do?" a good way to understand bits of orix I didn't write.