<br><br><div class="gmail_quote">On Tue, May 27, 2008 at 3:28 PM, Charles R Harris &lt;<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="Wj3C7c">On Tue, May 27, 2008 at 2:40 PM, Travis E. Oliphant &lt;<a href="mailto:oliphant@enthought.com" target="_blank">oliphant@enthought.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Charles R Harris wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Tue, May 27, 2008 at 2:10 PM, Travis E. Oliphant<br>
</div><div><div></div><div>&gt; &lt;<a href="mailto:oliphant@enthought.com" target="_blank">oliphant@enthought.com</a> &lt;mailto:<a href="mailto:oliphant@enthought.com" target="_blank">oliphant@enthought.com</a>&gt;&gt; wrote:<br>

&gt;<br>
&gt; &nbsp; &nbsp; Stéfan van der Walt wrote:<br>
&gt; &nbsp; &nbsp; &gt; Did this change recently?<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; In [33]: np.__version__<br>
&gt; &nbsp; &nbsp; &gt; Out[33]: &#39;1.1.0.dev5211&#39;<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; In [34]: np.minimum(np.uint8(164), np.uint64(12807)).dtype<br>
&gt; &nbsp; &nbsp; &gt; Out[34]: dtype(&#39;uint64&#39;)<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; &gt; But yes, that looks like it should return a uint8.<br>
&gt; &nbsp; &nbsp; &gt;<br>
&gt; &nbsp; &nbsp; This discussion is really moot unless a proposal for how to handle<br>
&gt; &nbsp; &nbsp; different casting rules for different ufuncs is proposed. &nbsp; Right now,<br>
&gt; &nbsp; &nbsp; the type-promotion rules are generic and do not depend on the<br>
&gt; &nbsp; &nbsp; ufunc only<br>
&gt; &nbsp; &nbsp; on coercion rules for the mixed types.<br>
&gt;<br>
&gt; &nbsp; &nbsp; One problem with a casting-rules-per-ufunc approach is that it<br>
&gt; &nbsp; &nbsp; makes it<br>
&gt; &nbsp; &nbsp; harder to add new types and have them fit in to the casting structure<br>
&gt; &nbsp; &nbsp; (which is currently possible now). &nbsp; Some mechanism for allowing the<br>
&gt; &nbsp; &nbsp; types to plug-in to the per-ufunc rules would be needed.<br>
&gt;<br>
&gt; &nbsp; &nbsp; These are not impossible things, just a bit of work and not on my<br>
&gt; &nbsp; &nbsp; personal priority list.<br>
&gt;<br>
&gt;<br>
&gt; Not everything follows those rules, however. So I have put these<br>
&gt; things up for review so that we can agree on what the are. Of<br>
&gt; particular concern in my mind are the bitwise and shift operators<br>
&gt; which currently work in a counter intuitive manner.<br>
<br>
</div></div>Right now, the only complete description of the rules is the code that<br>
implements them. &nbsp;So, from that perspective, yes everything follows<br>
those rules ;-)<br>
<div><div></div><div></div></div></blockquote></div></div><div><br><div class="Ih2E3d">So the segfaults are defined behavior? ;) It&#39;s like pulling teeth without anesthesia to get these things defined and everyone is going to think I&#39;m an a-hole. It&#39;s a dirty job, but someone has got to do it.<br>

<br>What about abs(-128) returning a negative number for int8? Might it not be better to return the corresponding unsigned type? Can&#39;t check that at the moment, as I&#39;m trying to get 64 bit Ubuntu installed on a software raid1 partition for further checks, and Ubuntu overwrote my MBR without asking. It&#39;s a traditional Ubuntu thing.<br>

</div></div></div></blockquote><div><br>Yep, abs fails:<br><br>In [1]: abs(array([-128,-128], dtype=int8))<br>Out[1]: array([-128, -128], dtype=int8)<br><br>Chuck <br></div><br></div><br>