On Monday, February 13, 2012, Travis Oliphant <tra...@continuum.io> wrote: > > On Feb 13, 2012, at 10:14 PM, Charles R Harris wrote: > > > On Mon, Feb 13, 2012 at 9:04 PM, Travis Oliphant <tra...@continuum.io> wrote: >> >> I disagree with your assessment of the subscript operator, but I'm sure we will have plenty of time to discuss that. I don't think it's correct to compare the corner cases of the fancy indexing and regular indexing to the corner cases of type coercion system. If you recall, I was quite nervous about all the changes you made to the coercion rules because I didn't believe you fully understood what had been done before and I knew there was not complete test coverage. >> It is true that both systems have emerged from a long history and could definitely use fresh perspectives which we all appreciate you and others bringing. It is also true that few are aware of the details of how things are actually implemented and that there are corner cases that are basically defined by the algorithm used (this is more true of the type-coercion system than fancy-indexing, however). >> I think it would have been wise to write those extensive tests prior to writing new code. I'm curious if what you were expecting for the output was derived from what earlier versions of NumPy produced. NumPy has never been in a state where you could just re-factor at will and assume that tests will catch all intended use cases. Numeric before it was not in that state either. This is a good goal, and we always welcome new tests. It just takes a lot of time and a lot of tedious work that the volunteer labor to this point have not had the time to do. >> Very few of us have ever been paid to work on NumPy directly and have often been trying to fit in improvements to the code base between other jobs we are supposed to be doing. Of course, you and I are hoping to change that this year and look forward to the code quality improving commensurately. >> Thanks for all you are doing. I also agree that Rolf and Charles have-been and are invaluable in the maintenance and progress of NumPy and SciPy. They deserve as much praise and kudos as anyone can give them. > > Well, the typecasting wasn't perfect and, as Mark points out, it wasn't commutative. The addition of float16 also complicated the picture, and user types is going to do more in that direction. And I don't see how a new developer should be responsible for tests enforcing old traditions, the original developers should be responsible for those. But history is history, it didn't happen that way, and here we are. > > That said, I think we need to show a little flexibility in the corner cases. And going forward I think that typecasting is going to need a rethink. > > > No argument on any of this. It's just that this needs to happen at NumPy 2.0, not in the NumPy 1.X series. I think requiring a re-compile is far-less onerous than changing the type-coercion subtly in a 1.5 to 1.6 release. That's my major point, and I'm surprised others are more cavalier about this.
I thought the whole datetime debacle was the impetus for binary compatibility? Also, I disagree with your "cavalier" charge here. When we looked at the rationale for the changes Mark made, the old behavior was not documented, broke commutibility, and was unexpected. So, if it walks like a duck... Now we are in an odd situation. We have undocumented old behavior, and documented new behavior. What do we do? I understand the drive to revert, but I hate the idea of putting back what I see as buggy, especially when new software may fail with old behavior. Maybe a Boolean switch defaulting to new behavior? Anybody having issues with old software could just flip the switch? Ben Root
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
