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