[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?
Tue Feb 14 00:48:44 CST 2012
On Mon, Feb 13, 2012 at 10:38 PM, Charles R Harris <
> On Mon, Feb 13, 2012 at 11:07 PM, Travis Oliphant <email@example.com>wrote:
>>> > 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.
>> You might be right, Chuck. I would like to investigate more, however.
>> What I fear is that there are *a lot* of users still on NumPy 1.3 and
>> NumPy 1.5. The fact that we haven't heard any complaints, yet, does not
>> mean to me that we aren't creating headache for people later who have just
>> not had time to try things.
>> However, I can believe that the specifics of "minor" casting rules are
>> probably not relied upon by a lot of codes out there. Still, as Robert
>> Kern often reminds us well --- our intuitions about this are usually not
>> worth much.
>> I may be making more of this then it's worth, I realize. I was just
>> sensitive to it at the time things were changing (even though I didn't have
>> time to be vocal), and now hearing this users experience, it confirms my
>> bias... Believe me, I do not want to "revert" if at all possible. There
>> is plenty of more work to do, and I'm very much in favor of the spirit of
>> the work Mark was and is doing.
> I think writing tests would be more productive. The current coverage is
> skimpy in that we typically don't cover *all* the combinations. Sometimes
> we don't cover any of them ;) I know you are sensitive to the typecasting,
> it was one of your babies. Nevertheless, I don't think it is that big an
> issue at the moment. If you can think of ways to *improve* it I think
> everyone will be interested in that.
> The lack of commutativity wasn't in precision, it was in the typecodes,
> and was there from the beginning. That caused confusion. A current cause of
> confusion is the many to one relation of, say, int32 and long, longlong
> which varies platform to platform. I think that confusion is a more
> significant problem. Having some types derived from Python types, a
> correspondence that also varies platform to platform is another source of
> inconsistent behavior that can be confusing. So there are still plenty of
> issues to deal with.
This reminds me of something that it would be really nice for the bug
tracker to have - user votes. This might be a particularly good way to draw
in some more of the users who don't want to stick their neck out with
emails and comments, put are comfortable adding a vote to a bug. Something
where it says that 566 people have starred the issue.
> I'd like to point out that the addition of float16 necessitated a certain
> amount of rewriting, as well as the addition of datetime. It was only
> through Mark's work that we were able to include the latter in the 1.*
> series at all. Before, we always had to remove datetime before a release, a
> royal PITA, while waiting on the ever receding 2.0. So there were very good
> reasons to deal with the type system.
> That isn't to say that typecasting can't use some tweaks here and there, I
> think we are all open to discussion along those lines. But it should about
> specific cases.
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion