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