[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?
Tue Feb 14 01:02:57 CST 2012
On Mon, Feb 13, 2012 at 10:48 PM, Mark Wiebe <email@example.com> wrote:
> On Mon, Feb 13, 2012 at 10:38 PM, Charles R Harris <
> firstname.lastname@example.org> wrote:
>> 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
> like this:
> where it says that 566 people have starred the issue.
Here's how this feature looks in YouTrack:
>> 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