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

Mark Wiebe mwwiebe@gmail....
Tue Feb 14 01:02:57 CST 2012


On Mon, Feb 13, 2012 at 10:48 PM, Mark Wiebe <mwwiebe@gmail.com> wrote:

> 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.
>

Here's how this feature looks in YouTrack:

http://youtrack.jetbrains.net/issues?q=sort+by%3Avotes

-Mark


>
> -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/41f24e59/attachment-0001.html 


More information about the NumPy-Discussion mailing list