<br><br>On Tuesday, February 14, 2012, Travis Oliphant &lt;<a href="mailto:travis@continuum.io">travis@continuum.io</a>&gt; wrote:<br>&gt;&gt; &gt; As you can see there were changes in each release.   Most of these were minor prior to the change from 1.5.1 to 1.6.1. I am still reviewing the changes from 1.5.1 to 1.6.1.    At first blush, it looks like there are a lot of changes to swallow that are not necessarily minor.    I really would like to just say all is well, and it&#39;s no big deal.   I hope that users really don&#39;t care and nobody&#39;s code is really relying on array-scalar combination conversions.<br>
&gt;&gt; &gt;<br>&gt;&gt; &gt; -Travis<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt;<br>&gt;&gt; Would it make sense to adapt this code to go into the test suite?<br>&gt;<br>&gt; Possibly.   I&#39;m not sure.  I guess it depends on how much we want to hard-code the current behavior now.    Mark?  How confident do you feel in solidifying the casting rules?   We would need to add cases for overflow that are currently handled differently than originally specified.<br>
&gt;<br>&gt; -Travis<br>&gt;<br><br>I don&#39;t think it is so much a question about whether or not to solidify these casting rules as much it is about being aware of changes in the table.  This prevents accidental changes and forces us to make purposeful changes to the agreed test results.<br>
<br>This would also make it very easy to diagnose cross-platform differences.<br><br>Of course, the question is, what do we consider to be the &quot;truth&quot; data?<br><br>Ben Root