[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?
Charles R Harris
Mon Feb 13 23:31:17 CST 2012
On Mon, Feb 13, 2012 at 10:25 PM, Benjamin Root <email@example.com> wrote:
> On Monday, February 13, 2012, Travis Oliphant <firstname.lastname@example.org> wrote:
> > On Feb 13, 2012, at 10:14 PM, Charles R Harris wrote:
> > On Mon, Feb 13, 2012 at 9:04 PM, Travis Oliphant <email@example.com>
> >> 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
> >> 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
> > 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?
I think we just leave it as is. If it was a big problem we would have heard
screams of complaint long ago. The post that started this off wasn't even a
complaint, more of a "see this". Spending time reverting or whatever would
be a waste of resources, IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion