On Fri, Apr 11, 2014 at 2:43 PM, Colin J. Williams <notifications@github.com
> wrote:

>  Stefan, Thanks for this clarification.  You say "Code that expects  an
> ``ndarray`` and gets a ``matrix``, or vice-versa, may crash or return
> incorrect results. " I would look at this as an error in the existing
> code.  Would it not be simpler to correct this than construct code for a
> new operator?  Has this been explored?
>

No, it wouldn't be simpler. Fixing every piece of code to handle both types
as inputs and outputs means that every function must have special checks,
which creates a combinatorial explosion in code complexity and is a serious
obstacle to maintainability, testing, etc.

This is why if you look at actual code there are few (possibly zero)
libraries that actually handle mixed ndarray and matrix objects correctly
(even numpy itself doesn't in many cases) -- it's just not doable. Everyone
prefers to use ndarray objects with the cumbersome dot() function call
syntax for matrix multiplication. It's annoying, but it's still better than
checking that every single code path can handle arrays and matrices (and
combinations thereof etc). (In fact, there are some places where
scikit-learn is forced to handle matrix objects because scipy.sparse only
provides a matrix-style API, and even in these cases they don't actually
use '*' for matrix multiplication -- which is the point that started this
whole thread. Instead they have a special safe_sparse_dot() function which
provides a dot()-style API that works for both arrays and matrices.)