<br><br><div class="gmail_quote">On Mon, Feb 13, 2012 at 11:07 PM, Travis Oliphant <span dir="ltr">&lt;<a href="mailto:travis@continuum.io">travis@continuum.io</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>&gt;<br>&gt; No argument on any of this.   It&#39;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&#39;s my major point, and I&#39;m surprised others are more cavalier about this. <br>


<br></div>I thought the whole datetime debacle was the impetus for binary compatibility? Also, I disagree with your &quot;cavalier&quot; 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...<br>


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


<br>Maybe a Boolean switch defaulting to new behavior?  Anybody having issues with old software could just flip the switch?<br><br></blockquote><div><br>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&#39;t even a complaint, more of a &quot;see this&quot;. Spending time reverting or whatever would be a waste of resources, IMHO.<br>

<br>Chuck <br></div></div></blockquote><div><br></div></div>You might be right, Chuck.   I would like to investigate more, however. </div><div><br></div><div>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&#39;t heard any complaints, yet, does not mean to me that we aren&#39;t creating headache for people later who have just not had time to try things.  </div>
<div><br></div><div>However, I can believe that the specifics of &quot;minor&quot; 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. </div>
<div><br></div><div>I may be making more of this then it&#39;s worth, I realize.   I was just sensitive to it at the time things were changing (even though I didn&#39;t have time to be vocal), and now hearing this users experience, it confirms my bias...  Believe me, I do not want to &quot;revert&quot; if at all possible.    There is plenty of more work to do, and I&#39;m very much in favor of the spirit of the work Mark was and is doing. </div>
<div><br></div></div></blockquote><div><br>I think writing tests would be more productive. The current coverage is skimpy in that we typically don&#39;t cover *all* the combinations. Sometimes we don&#39;t cover any of them ;) I know you are sensitive to the typecasting, it was one of your babies. Nevertheless, I don&#39;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.<br>
<br>The lack of commutativity wasn&#39;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.<br>
<br>I&#39;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&#39;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.<br>
<br>That isn&#39;t to say that typecasting can&#39;t use some tweaks here and there, I think we are all open to discussion along those lines. But it should about specific cases.<br><br>Chuck<br><br></div></div>