[Numpy-discussion] Uncomfortable with matrix change
Charles R Harris
Fri May 9 09:56:28 CDT 2008
On Fri, May 9, 2008 at 8:51 AM, Bruce Southey <email@example.com> wrote:
> Charles R Harris wrote:
> > On Fri, May 9, 2008 at 7:43 AM, Travis Oliphant <firstname.lastname@example.org
> > <mailto:email@example.com>> wrote:
> > Hi all,
> > I'm having trouble emailing this list from work, so I'm using a
> > different email address.
> > After Nathan Bell's recent complaints, I'm a bit more
> > uncomfortable with
> > the matrix change to scalar indexing. It does and will break code
> > possibly hard-to-track down ways. Also, Nathan has been a *huge*
> > contributor to the Sparse matrix in scipy and so I value his opinion
> > about the NumPy matrix. One of my goals is to have those two objects
> > work together a bit more seamlessly.
> > So, I think we need to:
> > 1) Add a warning to scalar access
> > 2) Back-out the change and fix all the places where NumPy assumes
> > incorrectly that the number of dimensions reduce on
> > PySequence_GetItem.
> > -1.
> > That said, the basic mistake is probably making Matrix a subclass of
> > ndarray, as it fails the "is a" test. There really aren't that many
> > places where inheritance is the right choice and numpy itself wasn't
> > designed as a base class: it lacks a specification of what functions
> > can be "virtual" and is probably too big.
> > I vote that we bring Nathan into the conversation and see how upset he
> > really is. Speaking for myself, I sometimes get angry upfront when
> > specifications change unexpectedly underfoot but then settle down and
> > find that it isn't all that bad. Being caught by surprise is probably
> > half the problem.
> > Chuck
> > ------------------------------------------------------------------------
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpyfirstname.lastname@example.org
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> The prime reason is not whether or not it is a bad/good idea but because
> the actual change was introduced so late in the development of 1.0.5/1.1
> process. A lesser reason is that gives people like Nathan time to change
> their code to match the pending release. Unfortunately the other problem
> with this change is that any user now has to be careful of which NumPy
> version is being used. The result is that backwards compatibility is now
> broken in what was originally going to be a minor release.
Of course, if Nathan has already made the changes we will drive him crazy if
we back them out now ;) I note that the thread on scipy ended pretty
quickly, so I didn't get the impression there was a lot of resistance.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion