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

Benjamin Root ben.root@ou....
Mon Feb 13 23:25:52 CST 2012

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

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120213/40a957bb/attachment.html 

More information about the NumPy-Discussion mailing list