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

> In doc/neps/return-of-revenge-of-matmul-pep.rst:
>
> > +much larger than both projects put together (stdlib: 411575 SLOC,
> > +scikit-learn: 50924 SLOC, nipy: 37078 SLOC). [#sloc-details]
> > +
> > +The **dot** row (marked ``******``) counts how common matrix multiply
> > +operations are in each codebase.
> > +
> > +::
> > +
> > +    ====  ======  ============  ====  ========
> > +      op  stdlib  scikit-learn  nipy  combined
> > +    ====  ======  ============  ====  ========
> > +       =    2969          5536  4932      3376 / 10,000 SLOC
> > +       -     218           444   496       261
> > +       +     224           201   348       231
> > +      ==     177           248   334       196
> > +       *     156           284   465       192
>
> On 11-Apr-2014 11:45 AM, argriffing wrote: In
> doc/neps/return-of-revenge-of-matmul-pep.rst: I'm kind of reluctant to join
> this thread, but regarding scikit-learn and np.matrix I thought I'd just
> add some relevant links. Here's the scikit-learn history page
> http://scikit-learn.org/stable/about.html, here's a 2011 scikit-learn
> thread about what to do about np.matrix
> http://osdir.com/ml/python-scikit-learn/2011-10/msg00212.html and here's
> a related sklearn github issue scikit-learn/scikit-learn#392<https://github.com/scikit-learn/scikit-learn/issues/392>.
> I haven't read these links in detail and I'm not trying to use them to make
> any argument regarding the PEP. -- Reply to this email directly or view it
> on GitHub. Thanks, this is helpful:The issue is: many modules currently
> fail when handed an np.matrix. We can resolve this by either: CONVERTING to
> np.ndarray * matrices are obviously array-like * matrices may come about
> inadvertently, because some NumPy/SciPy routines/methods happen to return
> them * we loosely use the term "matrix" throughout the docs, so it would be
> strange to require a matrix not to be an np.matrix * we are (or should be)
> doing input validation anyway, with utils.{safe_asanyarray, as_float_array,
> atleast2d_or_csr} * we already need to handle the matrix API in all modules
> that accept sparse input * backwards compatibility or REJECTING np.matrix
> by throwing a TypeError * mathematical operators may have different
> meanings than on array (* means dot product on matrix, Hadamard product on
> arrays) * matrices are always 2-d, so ravel, flatten and reshape don't
> behave as expected * converting to array is easy enough for the user: just
> call .A on every matrix * explicit is better than implicit * we'd need to
> test every routine against matrices (but then, we should be testing input
> validation anyway)   Three votes were in favour of Rejecting and six were
> in favour of  Converting. No consideration was given to addressing various
> problems raised in the discussion, including improved testing routines. One
> of the examples above: matrices may come about inadvertently, because some
> NumPy/SciPy routines/methods happen to return them The documentation should
> make it clear what type(s) each function is expected to return.  It is then
> up to the calling process to deal with the returned object appropriately.
> Colin W.
>

But Colin, we are trying to make writing code easier, not more difficult ;)

Chuck