On Mon, Feb 10, 2014 at 6:29 PM, Pauli Virtanen <p...@iki.fi> wrote: > 11.02.2014 00:31, Alan G Isaac kirjoitti: > > On 2/10/2014 5:11 PM, Pauli Virtanen wrote: > >> The existence of np.matrix messes up the general agreement on ndarray > >> semantics in Python. The meaning of very basic code such as > >> > >> A * B > >> A.sum(0) > >> A[0] > >> > >> where A and B are NxN matrices of some sort now depends on the types > >> of A and B. This makes writing duck typed code impossible when both > >> semantics are in play. > > > > I'm just missing the point here; sorry. > > Why isn't the right approach to require that > > any object that wants to work with scipy > > can be called by `asarray` to guarantee > > the core semantics? (And the matrix > > object passes this test.) For some objects > > we can agree that `asarray` will coerce them. > > (E.g., lists.) > > > > I just do not see why scipy should care about > > the semantics an object uses for interacting > > with other objects of the same type. > > I have a couple of points: > > (A) > > asarray() coerces the input to a dense array. This you do not want to do > to sparse matrices or matrix-free linear operators, as many linear > algebra algorithms don't need to know the matrix entries. > > (B) > > Coercing input types is something that is seldom done in Python code, > since it breaks duck typing. > > Usually, the interface is specified by assumed semantics of the input > objects. The user is then free to pass in mock objects that fulfill the > necessary subsection of the assumed interface. >
Almost all the code in scipy.stats and statsmodels starts with np.asarray. The numpy doc standard has the term `array_like` to indicate things that can be converted to a usable object by ndasarray. ducktyping could be restricted to a very narrow category of ducks. What about masked arrays and structured dtypes? Because we cannot usefully convert them by asarray, we have to tell users that they don't work with a function. Our ducks that quack in the wrong way. ? How do you handle list and other array_likes in sparse? Josef > > (C) > > This is not only about Scipy, but also a language design question: > > Suppose someone, who is not a Python expert, wants to implement a > linear algebra algorithm in Python. > > Will they write it using matrix or ndarray? (Note: np.matrix is not > uncommon on stackoverflow.) > > Will someone who reads the code easily understand what it does (does * > stand for elementwise or matrix product etc)? > > Can they easily make it work both with sparse and dense matrices? > Matrix-free operators? Does it work both for ndarray and np.matrix inputs? > > (D) > > The presence of np.matrix invites people to write code using the > np.matrix semantics. This can further lead to the code spitting out > dense results as np.matrix, and then it becomes difficult to follow > what sort of an object you have. > > (E) > > Some examples of the above semantics diaspora on scipy.sparse: > > * Implementation of GMRES et al in Scipy. The implementation reinvents > yet another set of semantics that it uses internally. > > * scipy.sparse has mostly matrix semantics, but not completely, and the > return values vary between matrix and ndarray > > > -- > Pauli Virtanen > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
