<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 12:14 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</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"><div dir="ltr"><div>On Tue, Feb 11, 2014 at 8:25 AM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><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"><div>> Anyway, I would say that there is a clear use for the matrix class: readability of linear algebra code and hence a lower chance of errors, so higher productivity.<br>



<br>
</div>Yes, but it looks like there are not any developers on this list who<br>
write substantial code with the np.matrix class, so, if there is a<br>
gain in productivity, it is short-lived, soon to be replaced by a<br>
cost.<br></blockquote><div><br></div></div><div>to re-iterate:</div><div><br></div><div>matrix is NOT for newbies, nor is it for higher productivity or fewer errors in production code -- the truth is, the ratio of linear algebra expressions like the above to element-wise, etc. operations that ndarray is well suited to is tiny  in "real" code. Did anyone that used MATLAB for significant problems get not get really really annoyed by all the typing of ".*" ?</div>


<div><br></div><div>What matrix is good for is what someone here described as "domain specific language" -- i.e. that little bit of code that really is doing mostly linera algebra. So it's a nice tool for teaching and experimenting with linear-algebra-based concepts.</div>
</div></div></div></blockquote><div> </div><div><a href="http://www.mathworks.com/matlabcentral/fileexchange/27095-tsls-2sls/content/tsls.m">http://www.mathworks.com/matlabcentral/fileexchange/27095-tsls-2sls/content/tsls.m</a></div>
<div><a href="https://github.com/statsmodels/statsmodels/blob/master/statsmodels/sandbox/regression/gmm.py#L134">https://github.com/statsmodels/statsmodels/blob/master/statsmodels/sandbox/regression/gmm.py#L134</a></div><div>
 </div><div>If I were not strict ndarray coder, I might prefer to wrap an ndarray and use only matrices inside a function and ndarrays outside for the code that is not linear algebra.</div><div> </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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div><br></div><div>To address Alan's question about duck-typing -- one of the things folks like to do with duck-typed functions and method is return the type that is passed in when possible: i.e use asanyarray(), rather than asarray() -- but this is really going to be broken with matrix, as the symantics have changed. So we could say "don't expect that to work with matrix", but that requires one of:</div>


<div><br></div><div>1) folks always use asarray() and return an array, rather than a matrix to the caller -- not too bad, folks that want matrix can use np.matrix to get it back (a bit ugly, though..) however, this means that any other array subclass will get mangled as well...</div>
</div></div></div></blockquote><div> </div><div>scipy.linalg has an arraywrap on input and output. (at least when I looked a few years ago)</div><div>(statsmodels has a pandas wrapper that converts arguments and returns to have ndarrays internally)</div>
<div> </div><div>some packages have helper functions to make a consistent interface to ndarrays and sparce "matrices"</div><div> </div><div>scipy.stats still doesn't protect against masked arrays and nans.</div>
<div> </div><div>IMO: that's life. Removing matrices from numpy doesn't make the problem go away. Although the problem could be pushed to other packages.</div><div>But if nobody uses matrices, then we would have at least **one** problem less.</div>
<div> </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"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">

<div><br></div><div>2) folks use asanyarray(), and it will break, maybe painfully, when a matrix is passed in -- folks using matrixes would need to use .A when calling such functions. This really seems ripe for confusion.</div>
</div></div></div></blockquote><div> </div><div><div>There are many ndarray subclasses out there, and I have no idea how they behave.</div><div>pandas.Series was until recently a ndarray subclass, that didn't quite behave like one.</div>
<div>We had to fix some bugs in statsmodels where we accidentially use asanyarray instead of asarray.</div><div> </div><div>Josef</div><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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div><br></div><div>The truth is that the "right" way to do all this is to have different operators, rather than different objects, but that's been tried and did not fly.</div><span><font color="#888888"><div>
<br></div>

<div>-Chris</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>

<br></div><div><br></div><div> </div></font></span></div><div>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" target="_blank" value="+12065266959">(206) 526-6959</a>   voice<br>
7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" target="_blank" value="+12065266329">(206) 526-6329</a>   fax<br>

Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" target="_blank" value="+12065266317">(206) 526-6317</a>   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>
</div></div></div>
<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>
<br></blockquote></div><br></div></div>