<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 6:29 PM, Pauli Virtanen <span dir="ltr"><<a href="mailto:pav@iki.fi" target="_blank">pav@iki.fi</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
11.02.2014 00:31, Alan G Isaac kirjoitti:<br>
<div>> On 2/10/2014 5:11 PM, Pauli Virtanen wrote:<br>
>> The existence of np.matrix messes up the general agreement on ndarray<br>
>> semantics in Python. The meaning of very basic code such as<br>
>><br>
>>      A * B<br>
>>      A.sum(0)<br>
>>      A[0]<br>
>><br>
>> where A and B are NxN matrices of some sort now depends on the types<br>
>> of A and B. This makes writing duck typed code impossible when both<br>
>> semantics are in play.<br>
><br>
> I'm just missing the point here; sorry.<br>
> Why isn't the right approach to require that<br>
> any object that wants to work with scipy<br>
> can be called  by `asarray` to guarantee<br>
> the core semantics? (And the matrix<br>
> object passes this test.)  For some objects<br>
> we can agree that `asarray` will coerce them.<br>
> (E.g., lists.)<br>
><br>
> I just do not see why scipy should care about<br>
> the semantics an object uses for interacting<br>
> with other objects of the same type.<br>
<br>
</div>I have a couple of points:<br>
<br>
(A)<br>
<br>
asarray() coerces the input to a dense array. This you do not want to do<br>
to sparse matrices or matrix-free linear operators, as many linear<br>
algebra algorithms don't need to know the matrix entries.<br>
<br>
(B)<br>
<br>
Coercing input types is something that is seldom done in Python code,<br>
since it breaks duck typing.<br>
<br>
Usually, the interface is specified by assumed semantics of the input<br>
objects. The user is then free to pass in mock objects that fulfill the<br>
necessary subsection of the assumed interface.<br></blockquote><div> </div><div>Almost all the code in scipy.stats and statsmodels starts with np.asarray.</div><div>The numpy doc standard has the term `array_like` to indicate things that can be converted to a usable object by ndasarray.</div>
<div> </div><div>ducktyping could be restricted to a very narrow category of ducks.</div><div> </div><div>What about masked arrays and structured dtypes? </div><div>Because we cannot usefully convert them by asarray, we have to tell users that they don't work with a function.</div>
<div>Our ducks that quack in the wrong way. ?</div><div> </div><div>How do you handle list and other array_likes in sparse?</div><div> </div><div>Josef</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">

<br>
(C)<br>
<br>
This is not only about Scipy, but also a language design question:<br>
<br>
Suppose someone, who is not a Python expert, wants to implement a<br>
linear algebra algorithm in Python.<br>
<br>
Will they write it using matrix or ndarray? (Note: np.matrix is not<br>
uncommon on stackoverflow.)<br>
<br>
Will someone who reads the code easily understand what it does (does *<br>
stand for elementwise or matrix product etc)?<br>
<br>
Can they easily make it work both with sparse and dense matrices?<br>
Matrix-free operators? Does it work both for ndarray and np.matrix inputs?<br>
<br>
(D)<br>
<br>
The presence of np.matrix invites people to write code using the<br>
np.matrix semantics. This can further lead to the code spitting out<br>
dense results as np.matrix, and then it becomes difficult to follow<br>
what sort of an object you have.<br>
<br>
(E)<br>
<br>
Some examples of the above semantics diaspora on scipy.sparse:<br>
<br>
* Implementation of GMRES et al in Scipy. The implementation reinvents<br>
  yet another set of semantics that it uses internally.<br>
<br>
* scipy.sparse has mostly matrix semantics, but not completely, and the<br>
  return values vary between matrix and ndarray<br>
<span><font color="#888888"><br>
<br>
--<br>
Pauli Virtanen<br>
</font></span><div><div class="h5"><br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>