On Mon, Feb 13, 2012 at 10:38 PM, Charles R Harris < charlesr.har...@gmail.com> wrote:
> > > On Mon, Feb 13, 2012 at 11:07 PM, Travis Oliphant <tra...@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
