On Mon, Feb 10, 2014 at 6:39 PM, <josef.p...@gmail.com> wrote: > > > 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. >
I thought once it would be nice to have a flag on the classes that indicate `array_semantic` versus `matrix_semantic` so it would be easy to check the quack instead of the duck. Josef > > 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
