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

Mark Wiebe mwwiebe@gmail....
Tue Feb 14 00:48:44 CST 2012


On Mon, Feb 13, 2012 at 10:38 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:

>
>
> On Mon, Feb 13, 2012 at 11:07 PM, Travis Oliphant <travis@continuum.io>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.
>>
>> Chuck
>>
>>
>> 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
like this:

http://code.google.com/p/googleappengine/issues/detail?id=190

where it says that 566 people have starred the issue.

-Mark


>
> 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.
>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120213/50418997/attachment.html 


More information about the NumPy-Discussion mailing list