[Numpy-discussion] Uncomfortable with matrix change
Fri May 9 10:27:51 CDT 2008
Charles R Harris wrote:
> On Fri, May 9, 2008 at 8:51 AM, Bruce Southey <firstname.lastname@example.org
> <mailto: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>
> > <mailto: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 in
> > possibly hard-to-track down ways. Also, Nathan has been a
> > contributor to the Sparse matrix in scipy and so I value his
> > 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
> > 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
> > 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
> > half the problem.
> > Chuck
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpyfirstname.lastname@example.org <mailto:Numpyemail@example.com>
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> The prime reason is not whether or not it is a bad/good idea but
> the actual change was introduced so late in the development of
> process. A lesser reason is that gives people like Nathan time to
> their code to match the pending release. Unfortunately the other
> 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
Sure all the related threads ended abruptly perhaps related to the fact
that Travis suggested the change :-)
More information about the Numpy-discussion