On 11-Apr-2014 7:39 AM, Stefan van der Walt wrote:
      In doc/neps/return-of-revenge-of-matmul-pep.rst:
      > +possible to switch between the conventions, because numpy provides two
> +different types with different ``__mul__`` methods.  For
> +``numpy.ndarray`` objects, ``*`` performs elementwise multiplication,
> +and matrix multiplication must use a function call (``numpy.dot``).
> +For ``numpy.matrix`` objects, ``*`` performs matrix multiplication,
> +and elementwise multiplication requires function syntax.  Writing code
> +using ``numpy.ndarray`` works fine.  Writing code using
> +``numpy.matrix`` also works fine.  But trouble begins as soon as we
> +try to integrate these two pieces of code together.  Code that expects
> +an ``ndarray`` and gets a ``matrix``, or vice-versa, may crash or
> +return incorrect results.  Keeping track of which functions expect
> +which types as inputs, and return which types as outputs, and then
> +converting back and forth all the time, is incredibly cumbersome and
> +impossible to get right at any scale.  Functions that defensively try
> +to handle both types as input and DTRT, find themselves floundering
> +into a swamp of ``isinstance`` and ``if`` statements.

      The point is still that libraries have
        to be aware of this double-class
        convention, otherwise only the broken sub-class solutions works
        (or
        doesn't).
    
    
    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?  It's been a long time since I looked at the
    code.
    It would help if some example of the need for "converting back and
    forth" could be given
    Colin W.
      —
        Reply to this email directly or view
          it on GitHub.