<div class="gmail_quote">On Mon, Apr 11, 2011 at 12:37 PM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Apr 11, 2011 at 13:54, Skipper Seabold <<a href="mailto:jsseabold@gmail.com">jsseabold@gmail.com</a>> wrote:<br>
> All,<br>
><br>
> We noticed some failing tests for statsmodels between numpy 1.5.1 and<br>
> numpy >= 1.6.0. These are the versions where I noticed the change. It<br>
> seems that when you divide a float array and multiply by a boolean<br>
> array the answers are different (unless the others are also off by<br>
> some floating point). Can anyone replicate the following using this<br>
> script or point out what I'm missing?<br>
><br>
> import numpy as np<br>
> print np.__version__<br>
> np.random.seed(12345)<br>
><br>
> test = np.random.randint(0,2,size=10).astype(bool)<br>
> t = 1.345<br>
> arr = np.random.random(size=10)<br>
><br>
> arr # okay<br>
> t/arr # okay<br>
> (1-test)*arr # okay<br>
> (1-test)*t/arr # huh?<br>
<br>
</div>[~]<br>
|12> 1-test<br>
array([1, 0, 0, 0, 1, 0, 1, 1, 0, 1], dtype=int8)<br>
<br>
[~]<br>
|13> (1-test)*t<br>
array([ 1.34472656,  0.        ,  0.        ,  0.        ,<br>
1.34472656,  0.        ,<br>
        1.34472656,  1.34472656,  0.        ,  1.34472656], dtype=float16)<br>
<br>
Some of the recent ufunc changes or the introduction of the float16<br>
type must have changed the way the dtype is chosen for the<br>
"int8-array*float64-scalar" case. Previously, the result was a float64<br>
array, as expected.<br>
<br>
Mark, I expect this is a result of one of your changes. Can you take a<br>
look at this?<br></blockquote><div><br></div><div>It's the type promotion rules change that is causing this, and it's definitely a 1.6.0 release blocker. Good catch!</div><div><br></div><div>I can think of an easy, reasonable way to fix it in the result_type function, but since the ufuncs themselves use a poor method of resolving the types, it will take some thought to apply the same idea there. Maybe detecting that the ufunc is a binary op at its creation time, setting a flag, and using the result_type function in that case. This would have the added bonus of being faster, too.</div>
<div><br></div><div>Going back to the 1.5 code isn't an option, since adding the new data types while maintaining ABI compatibility required major surgery to this part of the system.</div><div><br></div><div>-Mark</div>
</div>