<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 26, 2014 at 1:12 PM, Sebastian Berg <span dir="ltr"><<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Mi, 2014-04-23 at 10:11 -0400, <a href="mailto:josef.pktd@gmail.com">josef.pktd@gmail.com</a> wrote:<br>
> On Wed, Apr 23, 2014 at 5:32 AM, Sebastian Berg<br>
> <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br>
> > On Di, 2014-04-22 at 15:35 -0600, Charles R Harris wrote:<br>
> >> Hi All,<br>
> >><br>
> >><br>
> >> I'd like to branch 1.9.x at the end of the month. There are a couple<br>
> >> of reasons for the timing. First, we have a lot of new stuff in the<br>
> >> development branch. Second, there is work ongoing in masked arrays<br>
> >> that I'd like to keep out of the release so that it has more time to<br>
> >> settle. Third, it's past time ;)<br>
> ><br>
> > Sounds good.<br>
> ><br>
> >> There are currently a number of 1.9.0 blockers, which can be seen<br>
> >> here.<br>
> >><br>
> >> Datetime timezone handling broken in 1.7.x<br>
> >><br>
> >> I don't think there is time to get this done for 1.9.0 and it needs to<br>
> >> be pushed off to 1.10.0.<br>
> >><br>
> >> Return multiple field selection as ro view<br>
> >><br>
> >> I have a branch for this, but because the returned type differs from a<br>
> >> copy by alignment spacing there was a test failure. Merging that<br>
> >> branch might cause some incompatibilities.<br>
> >><br>
> ><br>
> > I am a bit worried here that comparisons might make trouble.<br>
> ><br>
> >> Object array creation new conversion to int<br>
> >><br>
> >><br>
> >> This one needs a decision. Julian, Sebastian, thoughts?<br>
> >><br>
> ><br>
> > Maybe for all to consider this is about what happens for object arrays<br>
> > if you do things like:<br>
> ><br>
> > # Array cast to object array (np.array(arr) would be identical):<br>
> > a = np.arange(10).astype(object)<br>
> > # Array passed into new array creation (not just *one* array):<br>
> > b = np.array([np.arange(10)], dtype=object)<br>
> > # Numerical array is assigned to object array:<br>
> > c = np.empty(10, dtype=object)<br>
> > c[...] = np.arange(10)<br>
> ><br>
> > Before this change, the result was:<br>
> > type(a[0]) is int<br>
> > type(b[0,0]) is np.int_ # Note the numpy type<br>
> > type(c[0]) is int<br>
> ><br>
> > After this change, they are all `int`. Though note that the numpy type<br>
> > is preserved for example for long double. On the one hand preserving the<br>
> > numpy type might be nice, but on the other hand we don't care much about<br>
> > the dtypes of scalars and in practice the python types are probably more<br>
> > often wanted.<br>
><br>
> what if I don't like python?<br>
><br>
<br>
</div></div>Fair point :). I also think it is more consistent if we use the numpy<br>
types (and the user has to cast to the python type explicitly). Could<br>
argue that if someone casts to object, they might like python objects,<br>
but if you don't want them that is tricky, too.<br>
<br>
There is the option that the numerical array -> object array cast always<br>
returns an array of numpy scalars. Making it consistent (opposite to<br>
what is currently in numpy master).<br>
<br>
This would mean that `numerical_arr.astype(object)` would give an array<br>
of numpy scalars always. Getting python scalars would only be possible<br>
using `arr.item()` (or `tolist`). I guess that change is less likely to<br>
cause problems, because the numpy types can do more things normally<br>
though they are slower.<br>
<br>
So a (still a bit unsure) +1 from me for making numeric -> object casts<br>
return arrays of numpy scalars unless we have reason to expect that to<br>
cause problems. Not sure how easy that would be to change, it wasn't a<br>
one line change when I tried, so there is something slightly tricky to<br>
clear out, but probably not too hard either.<br></blockquote><div><br></div><div>More general background question.</div><div><br></div><div>Why is there casting involved in object arrays?</div><div><br></div><div>I thought object arrays will just take and return whatever you put in.</div>
<div>If I use python ints, I might want python ints.</div><div>If I use numpy int_s, I might want numpy ints.</div><div><br></div><div><span style="color:rgb(80,0,80)">b1 = np.array([np.arange(10)], dtype=object)</span><br>
</div><div><span style="color:rgb(80,0,80)">versus</span></div><div><span style="color:rgb(80,0,80)">b2 = np.array([list(range(10))], dtype=object)</span><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"><br>
</span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"><div>>>> b1 = np.array([np.arange(10)], dtype=object)</div><div>>>> type(b1[0,2])</div><div><type 'numpy.int32'></div>
<div>>>> type(b1[0][2])</div><div><type 'numpy.int32'></div><div>>>> </div><div><br></div><div>>>> b2 = np.array([list(range(10))], dtype=object)</div><div><div>>>> type(b2[0,2])</div>
<div><type 'int'></div></div><div>>>> type(b2[0][2])</div><div><type 'int'></div><div><br></div><div>another version</div><div><br></div><div><div>>>> type(np.array(np.arange(10).tolist(), dtype=object)[2])</div>
<div><type 'int'></div><div>>>> type(np.array(list(np.arange(10)), dtype=object)[2])</div><div><type 'numpy.int32'></div></div></span></div><div><span style="color:rgb(80,0,80)"><br></span></div>
<div><span style="color:rgb(80,0,80)">Josef</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
- Sebastian<br>
</font></span><div class=""><div class="h5"><br>
> >>> np.int_(0)**(-1)<br>
> inf<br>
> >>> 0**-1<br>
> Traceback (most recent call last):<br>
> File "<pyshell#28>", line 1, in <module><br>
> 0**-1<br>
> ZeroDivisionError: 0.0 cannot be raised to a negative power<br>
><br>
><br>
> >>> type(np.arange(5)[0])<br>
> <type 'numpy.int32'><br>
> >>> np.arange(5)[0]**-1<br>
> inf<br>
><br>
> >>> type(np.arange(5)[0].item())<br>
> <type 'int'><br>
> >>> np.arange(5)[0].item()**-1<br>
> Traceback (most recent call last):<br>
> File "<pyshell#40>", line 1, in <module><br>
> np.arange(5)[0].item()**-1<br>
> ZeroDivisionError: 0.0 cannot be raised to a negative power<br>
><br>
> >>> np.__version__<br>
> '1.6.1'<br>
><br>
><br>
> I remember struggling through this (avoiding python operations) quite<br>
> a bit in my early bugfixes to scipy.stats.distributions.<br>
><br>
> (IIRC I ended up avoiding most ints.)<br>
><br>
> Josef<br>
><br>
> ><br>
> > Since I just realized that things are safe (float128 does not cast to<br>
> > float after all), I changed my mind and am tempted to keep the new<br>
> > behaviour. That is, if it does not create any problems (there was some<br>
> > issue in scipy, not sure how bad).<br>
> ><br>
> > - Sebastian<br>
> ><br>
> >> Median of np.matrix is broken(<br>
> >><br>
> >><br>
> >> Not sure what the status of this one is.<br>
> >><br>
> >> 1.8 deprecations: Follow-up ticket<br>
> >><br>
> >><br>
> >> Things that might should be removed.<br>
> >><br>
> >> ERROR: test_big_arrays (test_io.TestSavezLoad) on OS X + Python 3.3<br>
> >><br>
> >><br>
> >> I believe this one was fixed. For general problems reading/writing big<br>
> >> files on OS X, I believe they were fixed in Maverick and I'm inclined<br>
> >> to recommend an OS upgrade rather than work to chunk all the io.<br>
> >><br>
> >> Deprecate NPY_CHAR<br>
> >> This one is waiting on a fix from Pearu to make f2py use numpy<br>
> >> strings. I think we will need to do this ourselves if we want to carry<br>
> >> through the deprecation. In any case it probably needs to be pushed<br>
> >> off to 1.10.<br>
> >><br>
> >> 1.7 deprecations: Follow-up ticket<br>
> >> Some of these changes have been made, ro diagonal view for instance,<br>
> >> some still remain.<br>
> >><br>
> >><br>
> >><br>
> >> Additions, updates, and thoughts welcome.<br>
> >><br>
> >><br>
> >> Chuck<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> NumPy-Discussion mailing list<br>
> >> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> >> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > NumPy-Discussion mailing list<br>
> > <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> > <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
><br>
<br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>