How about just introducing a slightly different syntax which tells numpy to handle the array like a matrix:<br><br>Some thing along the lines of this:<br> <br>A = array[[..]]<br>B = array[[..]]<br><br>elementwise multipication (as it currently is):<br>
<br>C = A * B<br><br>matrix multiplication:<br><br>C = {A} * {B} <br><br>or<br><br>C = [A] * [B]<br><br>or any other brace we decide on<br><br>Essentially, the brace tells numpy to handle the array objects like matrices, but with no need for a specific matrix type. <br>
<br><br>Since textbook math typical has some kind of bracket around matrix variable, I think this would jive well<br><br><br>just my .02<br><br>Chris<br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 5:14 PM, Alan G Isaac <span dir="ltr"><<a href="mailto:aisaac@american.edu">aisaac@american.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On 6/5/2009 3:49 PM Stéfan van der Walt apparently wrote:<br>
> If the Matrix class is to remain, we need to take the steps<br>
> necessary to integrate it into NumPy properly.<br>
<br>
</div>I think this requires a list of current problems.<br>
Many of the problems for NumPy have been addressed over time.<br>
I believe the remaining problems center more on SciPy rather than NumPy.<br>
This requires that users report difficulties.<br>
<br>
For example, Jason Rennie says he ran into problems with<br>
scipy.optimize.fmin_cg, although I do not recall him reporting<br>
these (I do recall an optimization problem he reported using<br>
ndarrays).  Has he filed a bug report detailing his problem?<br>
<div class="im"><br>
<br>
> To get going we'll need a list of changes required (i.e. "in an ideal<br>
> world, how would matrices work?").<br>
<br>
</div>The key anomaly concerning matrices comes with indexing.<br>
See the introduction here: <a href="http://www.scipy.org/MatrixIndexing" target="_blank">http://www.scipy.org/MatrixIndexing</a><br>
<br>
However changing this for the current matrix object was rejected<br>
in the last (exhausting) go round.<br>
<div class="im"><br>
<br>
> There should be a set protocol for<br>
> all numpy functions that guarantees compatibility with ndarrays,<br>
> matrices and other derived classes.<br>
<br>
</div>My impression was that this was resolved as follows:<br>
handle all ndarray based objects as arrays (using asarray)<br>
in any NumPy function, but return the subclass when possible.<br>
(E.g., using asmatrix, return a matrix output for a matrix input.)<br>
This seems fine to me.<br>
<div class="im"><br>
<br>
> Being one of the most vocal proponents of the Matrix class, would you<br>
> be prepared to develop your Matrix Proposal at<br>
> <a href="http://scipy.org/NewMatrixSpec" target="_blank">http://scipy.org/NewMatrixSpec</a> further?<br>
<br>
</div>I consider my proposal to have the following status: rejected.<br>
I consider the core reason to be: creates a backwards incompatibility.<br>
That was a very long and exhausting discussion that was productive<br>
in laying out the issues, but I do not think we can progress in that<br>
direction.<br>
<br>
The existing matrix object is very usable.<br>
It's primary problem is some indexing anomalies,<br>
<a href="http://www.scipy.org/MatrixIndexing" target="_blank">http://www.scipy.org/MatrixIndexing</a><br>
and not everyone saw those as problems.<br>
In terms of NumPy functions, I think the asarray/asmatrix<br>
protocol fits the bill.  (Altho perhaps I am overlooking<br>
something as a user that is obvious to a developer.)<br>
<br>
Cheers,<br>
<font color="#888888">Alan<br>
</font><div><div></div><div class="h5"><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>