[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

[Charles R Harris]

On Mon, Feb 13, 2012 at 10:25 PM, Benjamin Root <ben.root at ou.edu> wrote:

>
>
> On Monday, February 13, 2012, Travis Oliphant <travis at 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 <travis at 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?
>
>
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.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120213/74f0f678/attachment.html>