@mhvk one thing I noticed looking here, is that if core axes are optional, you cannot omit them by passing a shorter axes tuple. I.e. matul(2D, 2D, axes=[(-2, -1)], (-1,), (-1,)]) doesn't work. Just curious if it is intentional, or because it would be complicated to allow?

@seberg - I think I introduced the ability to give axes just before we allowed for optional axes, so I think it is more a question of oversight...

It might actually be quite neat if one could indeed use axes to signal one really wanted matrix-stack @ vector-stack rather than a stack of matrices. Though perhaps (mat @ vec[..., np.newaxis]).squeeze(-1) or just np.einsum(...) ends up being clearer. And the alternative of just implementing matvec and vecmat is perhaps cleanest of all.

p.s. This seems all OK, so fine to merge.

Could these be AxisError instead of ValueError ?

Hmmm, right now we only use AxisError for an out-of-bounds axis I think, not for a different way axis= can be invalid.

So yeah, makes sense, although for myself I am happy to not broaden up AxisError for this (happy to do so I am just ±0 on it).

Something other than ValueError would be helpful in order to properly catch errors in a @= b

Heh, I forgot about that idea... I guess that is a good enough reason here, we might want to do it for more axis/axes related ValueError's I guess.

This is failing. It used to raise TypeError("axes item 2 should be a tuple").

a = np.arange(27.).reshape((3, 3, 3))
b = np.arange(10., 19.).reshape((3, 1, 3))
assert_raises(TypeError, inner1d, a, b, axes=[-1, -1, -1])

Grrr, restored the TypeError where it clearly is correct the long way around... Not pretty, but maybe the practical path?

Thanks Matti, I am not sure we need the note for such a niche change, but it reads well and can't hurt.