On Wed, Apr 23, 2014 at 5:32 AM, Sebastian Berg
<sebast...@sipsolutions.net> wrote:
> On Di, 2014-04-22 at 15:35 -0600, Charles R Harris wrote:
>> Hi All,
>>
>>
>> I'd like to branch 1.9.x at the end of the month. There are a couple
>> of reasons for the timing. First, we have a lot of new stuff in the
>> development branch. Second, there is work ongoing in masked arrays
>> that I'd like to keep out of the release so that it has more time to
>> settle. Third, it's past time ;)
>
> Sounds good.
>
>> There are currently a number of 1.9.0 blockers, which can be seen
>> here.
>>
>> Datetime timezone handling broken in 1.7.x
>>
>> I don't think there is time to get this done for 1.9.0 and it needs to
>> be pushed off to 1.10.0.
>>
>> Return multiple field selection as ro view
>>
>> I have a branch for this, but because the returned type differs from a
>> copy by alignment spacing there was a test failure. Merging that
>> branch might cause some incompatibilities.
>>
>
> I am a bit worried here that comparisons might make trouble.
>
>> Object array creation new conversion to int
>>
>>
>> This one needs a decision. Julian, Sebastian, thoughts?
>>
>
> Maybe for all to consider this is about what happens for object arrays
> if you do things like:
>
> # Array cast to object array (np.array(arr) would be identical):
> a = np.arange(10).astype(object)
> # Array passed into new array creation (not just *one* array):
> b = np.array([np.arange(10)], dtype=object)
> # Numerical array is assigned to object array:
> c = np.empty(10, dtype=object)
> c[...] = np.arange(10)
>
> Before this change, the result was:
> type(a[0]) is int
> type(b[0,0]) is np.int_ # Note the numpy type
> type(c[0]) is int
>
> After this change, they are all `int`. Though note that the numpy type
> is preserved for example for long double. On the one hand preserving the
> numpy type might be nice, but on the other hand we don't care much about
> the dtypes of scalars and in practice the python types are probably more
> often wanted.
what if I don't like python?
>>> np.int_(0)**(-1)
inf
>>> 0**-1
Traceback (most recent call last):
File "<pyshell#28>", line 1, in <module>
0**-1
ZeroDivisionError: 0.0 cannot be raised to a negative power
>>> type(np.arange(5)[0])
<type 'numpy.int32'>
>>> np.arange(5)[0]**-1
inf
>>> type(np.arange(5)[0].item())
<type 'int'>
>>> np.arange(5)[0].item()**-1
Traceback (most recent call last):
File "<pyshell#40>", line 1, in <module>
np.arange(5)[0].item()**-1
ZeroDivisionError: 0.0 cannot be raised to a negative power
>>> np.__version__
'1.6.1'
I remember struggling through this (avoiding python operations) quite
a bit in my early bugfixes to scipy.stats.distributions.
(IIRC I ended up avoiding most ints.)
Josef
>
> Since I just realized that things are safe (float128 does not cast to
> float after all), I changed my mind and am tempted to keep the new
> behaviour. That is, if it does not create any problems (there was some
> issue in scipy, not sure how bad).
>
> - Sebastian
>
>> Median of np.matrix is broken(
>>
>>
>> Not sure what the status of this one is.
>>
>> 1.8 deprecations: Follow-up ticket
>>
>>
>> Things that might should be removed.
>>
>> ERROR: test_big_arrays (test_io.TestSavezLoad) on OS X + Python 3.3
>>
>>
>> I believe this one was fixed. For general problems reading/writing big
>> files on OS X, I believe they were fixed in Maverick and I'm inclined
>> to recommend an OS upgrade rather than work to chunk all the io.
>>
>> Deprecate NPY_CHAR
>> This one is waiting on a fix from Pearu to make f2py use numpy
>> strings. I think we will need to do this ourselves if we want to carry
>> through the deprecation. In any case it probably needs to be pushed
>> off to 1.10.
>>
>> 1.7 deprecations: Follow-up ticket
>> Some of these changes have been made, ro diagonal view for instance,
>> some still remain.
>>
>>
>>
>> Additions, updates, and thoughts welcome.
>>
>>
>> Chuck
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
