On Mon, Feb 13, 2012 at 10:48 PM, Mark Wiebe <mwwi...@gmail.com> wrote:
> 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. > 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 >> >> >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
