My 2pc: I personally hardly ever use matrix, even in linear algebra dense code. It can be nice though, to use matrix semantics within a restricted scope. When I first came to numpy, the ability to choose linear algebra versus array semantics seemed like a really neat thing to me; though in practice the array semantics are so much more useful you really don't mind having to write the occasional np.dot.
There seems to be some resistance form the developer side in having to maintain this architecture, which I cannot comment on, but from a user perspective, I am perfectly fine with the way things are. On Tue, Feb 11, 2014 at 11:16 AM, Todd <toddr...@gmail.com> wrote: > > On Feb 11, 2014 3:23 AM, "Alan G Isaac" <alan.is...@gmail.com> wrote: > > > > On 2/10/2014 7:39 PM, Pauli Virtanen wrote: > > > The issue here is semantics for basic linear algebra operations, such > as > > > matrix multiplication, that work for different matrix objects, > including > > > ndarrays. > > > > > > I'll see if I can restate my suggestion in another way, > > because I do not feel you are responding to it. > > (I might be wrong.) > > > > What is a duck? If you ask it to quack, it quacks. > > OK, but what is it to quack? > > > > Here, quacking is behaving like an ndarray (in your view, > > as I understand it) when asked. But how do we ask? > > Your view (if I understand) is we ask via the operations > > supported by ndarrays. But maybe that is the wrong way > > for the library to ask this question. > > > > If so, then scipy libraries could ask an object > > to behave like an an ndarray by calling, e.g., > > __asarray__ on it. It becomes the responsibility > > of the object to return something appropriate > > when __asarray__ is called. Objects that know how to do > > this will provide __asarray__ and respond > > appropriately. Other types can be coerced if > > that is the documented behavior (e.g., lists). > > The libraries will then be written for a single > > type of behavior. What it means to "quack" is > > pretty easily documented, and a matrix object > > already knows how (e.g., m.A). Presumably in > > this scenario __asarray__ would return an object > > that behaves like an ndarray and a converter for > > turning the final result into the desired object > > type (e.g., into a `matrix` if necessary). > > > > Hope that clearer, even if it proves a terrible idea. > > > > Alan Isaac > > I don't currently use the matrix class, but having taken many linear > algebra classes I can see the appeal, and if I end up teaching the subject > I think I would appreciate having it available. > > On the other hand, I certainly can see the possibility for confusion, and > I don't think it is something that should be used unless someone has a > really good reason. > > So I come out somewhere in the middle here. So, although this may end up > being a terrible idea, I would like to purpose what I think is a > compromise: instead of just removing matrix, split it out into a scikit. > That way, it it's still available for those who need it, but will be less > likely to be used accidentally, and won't be interfering with the rest of > numpy and scipy development. > > Specifically, I would split matrix into a scikit, while in the same > release deprecate np.matrix. They can then exist in parallel for a few > releases to allow code to be ported away from it. > > However, I would suggest that before the split, all linear algebra > routines should be available as functions or methods in numpy proper. > > _______________________________________________ > 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
