Dear all,
At https://github.com/scikit-learn/scikit-learn/issues/392 there's
been some discussion on whether to accept data of type np.matrix or
not. I'd like to take that discussion here and resolve it with a quick
vote, if possible.
The issue is: many modules currently fail when handed an np.matrix. We
can resolve this by...
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
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)
Please voice your opinions. I'm willing to write up some docs
describing whichever option we choose.
TIA,
--
Lars Buitinck
Scientific programmer, ILPS
University of Amsterdam
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Scikit-learn-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
