Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
A Monday 07 March 2011 15:39:38 Pauli Virtanen escrigué: > Mon, 07 Mar 2011 15:23:10 +0100, Francesc Alted wrote: > [clip] > > > ValueError: numpy.dtype has the wrong size, try recompiling > > > > I don't think I'm wrong here, but I'd appreciate if somebody else > > can reproduce this (either with tables or with another > > Cython-dependent package). > > Ok, seems this needs looking into. I don't immediately see how it can > happen, and agree that it shouldn't (AFAIK, there are no changes in > 1.6 that require additions to the structs). Ups, forget about this. It turns out that I was using a somewhat outdated version of 1.5.x (probably pre-1.5.0). I have updated to 1.5.1, and now the 1.6 binaries are completely backward compatibles: tables suite with 1.5.1: Ran 2981 tests in 37.183s Using 1.6.0.dev-c081ad7 without recompiling tables: Ran 2981 tests in 36.716s Sorry for the false alarm! -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
Mon, 07 Mar 2011 15:23:10 +0100, Francesc Alted wrote: [clip] > ValueError: numpy.dtype has the wrong size, try recompiling > > I don't think I'm wrong here, but I'd appreciate if somebody else can > reproduce this (either with tables or with another Cython-dependent > package). Ok, seems this needs looking into. I don't immediately see how it can happen, and agree that it shouldn't (AFAIK, there are no changes in 1.6 that require additions to the structs). -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
A Monday 07 March 2011 15:17:17 Pauli Virtanen escrigué: > Mon, 07 Mar 2011 14:57:39 +0100, Francesc Alted wrote: > [clip] > > > > However, the size of PyArray_Descr does not seem to have changed > > > between 1.5.1 and the Git master. So I'm not sure why you see > > > this error... > > > > Maybe a Cython problem? > > That would be seriously weird. Maybe the binaries you have were > compiled against Numpy < 1.5? If so, the same errors should come up > with Numpy 1.5.x. > > In any case, it seems to me that since there have been no changes in > the dtype struct contents since 1.5, the Git master should behave > exactly the same as 1.5 in this respect. I've just tried again, and I'm reproducing the problem. Using NumPy 1.5.0: $ PYTHONPATH=.:~/python/numpy/trunk:~/python/numexpr/branches/1.4 python tables/tests/test_all.py -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-= PyTables version: 2.3b1.dev HDF5 version: 1.8.5 NumPy version: 1.5.0.dev Numexpr version: 1.4.3.dev (not using Intel's VML/MKL) [OK] With the same PyTables binaries, but using NumPy 1.6: $ PYTHONPATH=.:~/python/numpy/git/numpy:~/python/numexpr/branches/1.4/ python tables/tests/test_all.py Traceback (most recent call last): File "tables/tests/test_all.py", line 13, in import tables File "/home/faltet/PyTables/pytables/trunk/tables/__init__.py", line 63, in from tables.utilsExtension import getPyTablesVersion, getHDF5Version File "definitions.pxd", line 138, in init tables.utilsExtension (tables/utilsExtension.c:9238) ValueError: numpy.dtype has the wrong size, try recompiling I don't think I'm wrong here, but I'd appreciate if somebody else can reproduce this (either with tables or with another Cython-dependent package). -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
Mon, 07 Mar 2011 14:57:39 +0100, Francesc Alted wrote: [clip] > > However, the size of PyArray_Descr does not seem to have changed > > between 1.5.1 and the Git master. So I'm not sure why you see this > > error... > > Maybe a Cython problem? That would be seriously weird. Maybe the binaries you have were compiled against Numpy < 1.5? If so, the same errors should come up with Numpy 1.5.x. In any case, it seems to me that since there have been no changes in the dtype struct contents since 1.5, the Git master should behave exactly the same as 1.5 in this respect. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
A Monday 07 March 2011 14:49:26 Pauli Virtanen escrigué: > Mon, 07 Mar 2011 13:17:55 +0100, Francesc Alted wrote: > [clip] > > > from tables.utilsExtension import getPyTablesVersion, > > getHDF5Version > > > > File "definitions.pxd", line 138, in init tables.utilsExtension > > > > (tables/utilsExtension.c:9238) > > ValueError: numpy.dtype has the wrong size, try recompiling > > > > I've seen the same issue when NumPy jumped from 1.3.x to 1.4.1, > > forcing all the packages depending on NumPy to be recompiled to > > work with 1.4.1 and higher. Do we really want to repeat the > > experience with 1.5.x --> 1.6.x? > > I got the impression that this unnecessary check was removed in newer > Cython versions? If so, some of the existing code should not have > this problem. Well, I'm using the latest Cython: $ cython -V Cython version 0.14.1 > However, the size of PyArray_Descr does not seem to have changed > between 1.5.1 and the Git master. So I'm not sure why you see this > error... Maybe a Cython problem? -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
Mon, 07 Mar 2011 13:17:55 +0100, Francesc Alted wrote: [clip] > from tables.utilsExtension import getPyTablesVersion, getHDF5Version > File "definitions.pxd", line 138, in init tables.utilsExtension > (tables/utilsExtension.c:9238) > ValueError: numpy.dtype has the wrong size, try recompiling > > I've seen the same issue when NumPy jumped from 1.3.x to 1.4.1, forcing > all the packages depending on NumPy to be recompiled to work with 1.4.1 > and higher. Do we really want to repeat the experience with 1.5.x --> > 1.6.x? I got the impression that this unnecessary check was removed in newer Cython versions? If so, some of the existing code should not have this problem. However, the size of PyArray_Descr does not seem to have changed between 1.5.1 and the Git master. So I'm not sure why you see this error... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Mon, Mar 7, 2011 at 5:17 AM, Francesc Alted wrote: > A Monday 28 February 2011 16:31:59 Ralf Gommers escrigué: > > >> Proposed schedule: > > >> March 15: beta 1 > > >> March 28: rc 1 > > >> April 17: rc 2 (if needed) > > >> April 24: final release > > >> > > >> Let me know what you think. Bonus points for volunteering to fix > > >> some of those tickets:) > > While doing tests on the new NumPy 1.6 code, I'm seeing that the > compiled code with NumPy 1.5 no longer works with 1.6. Here it is the > problem: > > $ PYTHONPATH=. python tables/tests/test_all.py > Traceback (most recent call last): > File "tables/tests/test_all.py", line 13, in >import tables > File "/home/faltet/PyTables/pytables/trunk/tables/__init__.py", line > 63, in >from tables.utilsExtension import getPyTablesVersion, getHDF5Version > File "definitions.pxd", line 138, in init tables.utilsExtension > (tables/utilsExtension.c:9238) > ValueError: numpy.dtype has the wrong size, try recompiling > > I've seen the same issue when NumPy jumped from 1.3.x to 1.4.1, forcing > all the packages depending on NumPy to be recompiled to work with 1.4.1 > and higher. Do we really want to repeat the experience with 1.5.x --> > 1.6.x? > > IIRC, that was a cython problem. I thought they fixed that to issue a warning instead. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
A Sunday 06 March 2011 06:47:34 Mark Wiebe escrigué: > I think it's ok to revert this behavior for backwards compatibility, > but believe it's an inconsistent and unintuitive choice. In > broadcasting, there are two operations, growing a dimension 1 -> n, > and appending a new 1 dimension to the left. The behaviour under > discussion in assignment is different from normal broadcasting in > that only the second one is permitted. It is broadcasting the output > to the input, rather than broadcasting the input to the output. > > Suppose a has shape (20,), b has shape (1,20), and c has shape > (20,1). Then a+b has shape (1,20), a+c has shape (20,20), and b+c > has shape (20,20). > > If we do "b[...] = a", a will be broadcast to match b by adding a 1 > dimension to the left. This is reasonable and consistent with > addition. > > If we do "a[...]=b", under 1.5 rules, a will once again be broadcast > to match b by adding a 1 dimension to the left. > > If we do "a[...]=c", we could broadcast both a and c together to the > shape (20,20). This results in multiple assignments to each element > of a, which is inconsistent. This is not analogous to a+c, but > rather to np.add(c, c, out=a). > > The distinction is subtle, but the inconsistent behavior is harmless > enough for assignment that keeping backwards compatibility seems > reasonable. For what is worth, I also like the behaviour that Mark proposes, and have updated tables test suite to adapt to this. But I'm fine if it is decided to revert to the previous behaviour. -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
A Monday 28 February 2011 16:31:59 Ralf Gommers escrigué: > >> Proposed schedule: > >> March 15: beta 1 > >> March 28: rc 1 > >> April 17: rc 2 (if needed) > >> April 24: final release > >> > >> Let me know what you think. Bonus points for volunteering to fix > >> some of those tickets:) While doing tests on the new NumPy 1.6 code, I'm seeing that the compiled code with NumPy 1.5 no longer works with 1.6. Here it is the problem: $ PYTHONPATH=. python tables/tests/test_all.py Traceback (most recent call last): File "tables/tests/test_all.py", line 13, in import tables File "/home/faltet/PyTables/pytables/trunk/tables/__init__.py", line 63, in from tables.utilsExtension import getPyTablesVersion, getHDF5Version File "definitions.pxd", line 138, in init tables.utilsExtension (tables/utilsExtension.c:9238) ValueError: numpy.dtype has the wrong size, try recompiling I've seen the same issue when NumPy jumped from 1.3.x to 1.4.1, forcing all the packages depending on NumPy to be recompiled to work with 1.4.1 and higher. Do we really want to repeat the experience with 1.5.x --> 1.6.x? -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 11:11 PM, Mark Wiebe wrote:
> On Sat, Mar 5, 2011 at 8:13 PM, Travis Oliphant wrote:
>
>>
>> On Mar 5, 2011, at 5:10 PM, Mark Wiebe wrote:
>>
>> On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers <
>> ralf.gomm...@googlemail.com> wrote:
>>
>>>
>>>
>>
>>
>>> >>> I've had a look at the bug tracker, here's a list of tickets for
>>> 1.6:
>>> >>> #1748 (blocker: regression for astype('str'))
>>> >>> #1619 (issue with dtypes, with patch)
>>> >>> #1749 (distutils, py 3.2)
>>> >>> #1601 (distutils, py 3.2)
>>> >>> #1622 (Solaris segfault, with patch)
>>> >>> #1713 (Solaris segfault)
>>> >>> #1631 (Solaris segfault)
>>>
>>> The distutils tickets are resolved.
>>>
>>> >>> Proposed schedule:
>>> >>> March 15: beta 1
>>> >>> March 28: rc 1
>>> >>> April 17: rc 2 (if needed)
>>> >>> April 24: final release
>>>
>>> Any comments on the schedule or tickets?
>>>
>>
>> That all looks fine to me. There are a few things that I've changed in the
>> core that could stand some discussion before being finalized in 1.6, mostly
>> due to what was required to make things work without depending on the data
>> type enumeration order. The combination of the numpy and scipy tests were
>> pretty effective, but as Travis mentioned my changes are fairly invasive.
>>
>> * When copying array to array, structured types now copy based on field
>> names instead of positions, effectively behaving like a 'dict' instead of a
>> 'labeled tuple'. This behaviour is more intuitive to me, and several fixed
>> bugs such as dtype comparison completely ignoring the structured type data
>> suggest that this changes an area of numpy that has been used in a more
>> limited fashion. It might be worthwhile to introduce a tuple-style flag in a
>> future version which causes data to be copied by position instead of by
>> name, as it is likely useful in some contexts.
>>
>>
>> This is a semantic change that does make me a tiny bit nervous.
>> Structured arrays are actually used quite a bit in the wild, and so this
>> could raise some errors. What I don't know is how often sub-parts of a
>> structured arrays get copied into other structured arrays with a different
>> order to the fields.From what I gather, Mark's changes would allow this
>> case and do an arguably useful thing.Previously, a copy was only allowed
>> if the structured array contained the same fields in the same order. It
>> seems like this is a relaxation of a rule and should not raise any errors
>> (unless extant code was relying on the previous errors for some reason).
>>
>
> Another important factor is that previously the performance was poor,
> because each copy involved converting the array element to a Python tuple,
> then copying the tuple into the destination array. The new code directly
> copies the elements with no Python overhead. I haven't directly benchmarked
> this, but if someone wants to confirm this with some numbers that would be
> great.
>
>> * Array memory layouts are preserved in many cases. This means that if a,
>> b are Fortran ordered, a+b will be as well. It could be made more pervasive,
>> for example ndarray.copy defaults to C-order, and that could be changed to
>> 'K' to preserve the memory layout by default. Any comments about that?
>>
>>
>> I like this change quite a bit, but it has similar potential "expectation"
>> issues. I think the default should be changed to 'K' in NumPy 2.0, but
>> perhaps we should preserve C-order for now to avoid the subtle breakages
>> that might occur based on changed expectations.What are others thoughts?
>>
>
> I suspect defaulting to 'C' might be desirable, but I initially set it to
> 'K' to see how it would work out. Defaulting it to 'C' unfortunately kills
> most of the performance benefits of the new code, so it might be nice to
> leave it as 'K' if no issues arise that are traced back to here.
>
>
I suppose this might cause a problem with lazy/quick c extensions that
expected elements in a certain order, so some breakage could occur. The
strict rule for backward compatibility would be no breakage, and if there
was no performance gain I would opt for that. But in this case there is a
real gain in breaking compatibility in a small way that is unlikely to be
noticed.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 8:13 PM, Travis Oliphant wrote:
>
> On Mar 5, 2011, at 5:10 PM, Mark Wiebe wrote:
>
> On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers > wrote:
>
>>
>>
>
>
>> >>> I've had a look at the bug tracker, here's a list of tickets for 1.6:
>> >>> #1748 (blocker: regression for astype('str'))
>> >>> #1619 (issue with dtypes, with patch)
>> >>> #1749 (distutils, py 3.2)
>> >>> #1601 (distutils, py 3.2)
>> >>> #1622 (Solaris segfault, with patch)
>> >>> #1713 (Solaris segfault)
>> >>> #1631 (Solaris segfault)
>>
>> The distutils tickets are resolved.
>>
>> >>> Proposed schedule:
>> >>> March 15: beta 1
>> >>> March 28: rc 1
>> >>> April 17: rc 2 (if needed)
>> >>> April 24: final release
>>
>> Any comments on the schedule or tickets?
>>
>
> That all looks fine to me. There are a few things that I've changed in the
> core that could stand some discussion before being finalized in 1.6, mostly
> due to what was required to make things work without depending on the data
> type enumeration order. The combination of the numpy and scipy tests were
> pretty effective, but as Travis mentioned my changes are fairly invasive.
>
> * When copying array to array, structured types now copy based on field
> names instead of positions, effectively behaving like a 'dict' instead of a
> 'labeled tuple'. This behaviour is more intuitive to me, and several fixed
> bugs such as dtype comparison completely ignoring the structured type data
> suggest that this changes an area of numpy that has been used in a more
> limited fashion. It might be worthwhile to introduce a tuple-style flag in a
> future version which causes data to be copied by position instead of by
> name, as it is likely useful in some contexts.
>
>
> This is a semantic change that does make me a tiny bit nervous.
> Structured arrays are actually used quite a bit in the wild, and so this
> could raise some errors. What I don't know is how often sub-parts of a
> structured arrays get copied into other structured arrays with a different
> order to the fields.From what I gather, Mark's changes would allow this
> case and do an arguably useful thing.Previously, a copy was only allowed
> if the structured array contained the same fields in the same order. It
> seems like this is a relaxation of a rule and should not raise any errors
> (unless extant code was relying on the previous errors for some reason).
>
Another important factor is that previously the performance was poor,
because each copy involved converting the array element to a Python tuple,
then copying the tuple into the destination array. The new code directly
copies the elements with no Python overhead. I haven't directly benchmarked
this, but if someone wants to confirm this with some numbers that would be
great.
> * Array memory layouts are preserved in many cases. This means that if a, b
> are Fortran ordered, a+b will be as well. It could be made more pervasive,
> for example ndarray.copy defaults to C-order, and that could be changed to
> 'K' to preserve the memory layout by default. Any comments about that?
>
>
> I like this change quite a bit, but it has similar potential "expectation"
> issues. I think the default should be changed to 'K' in NumPy 2.0, but
> perhaps we should preserve C-order for now to avoid the subtle breakages
> that might occur based on changed expectations.What are others thoughts?
>
I suspect defaulting to 'C' might be desirable, but I initially set it to
'K' to see how it would work out. Defaulting it to 'C' unfortunately kills
most of the performance benefits of the new code, so it might be nice to
leave it as 'K' if no issues arise that are traced back to here.
* The ufunc uses a more consistent algorithm for loop selection. The
> previous algorithm was ad hoc and lacked symmetry, while the new algorithm
> is based on a simple minimization definition. This change exposed a bug in
> scipy's ndimage, which did not handle all of the numpy data type enums
> properly, so its possible there is more code out there which will be
> affected similarly.
>
>
> This change has me the most nervous. I'm looking forward to the more
> consistent algorithm. As I said, the algorithm presently used as been there
> since Numeric in 1995 (I modified it only a little bit to handle
> scalar-array casting rules a bit differently).This kind of change will
> have different corner cases and this should be understood before a release.
>
I don't think there is much reason to worry here. The only substantive
difference is that the new algorithm doesn't skip ahead based on the type of
the first operand. This code is also extremely thoroughly exercised, messing
with the ufuncs can even cause numpy startup to fail. The trickiest ad hoc
part of loop selection was how accumulation of logical operations settles on
the boolean loop when the inputs are not boolean, and this still works the
same, but now is coded explicitly instead of appearing to be an accident.
O
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 8:13 PM, Charles R Harris wrote: > > > On Sat, Mar 5, 2011 at 9:00 PM, Travis Oliphant wrote: > >> My point is also that we need to make sure the broadcasting rules are >> consistent for both addition and array copy. >> >> Addition would not create an error if a (1,20) array was added to a (20,) >> array. Therefore, a (1,20) array can also copied into a (20,) array --- as >> can a (1,1,1,1,20) array. Conversely, a (20,1) or a (1,1,20,1,1) array can >> not be copied into a (20,) array. >> > > Well, adding a (1,20) array to a (20,) array gives a (1,20) array. Changing > this for assignment is like english spelling ( 'I' before 'e' except after > 'c', or sounded 'a' as in neighbor and weigh -- with various exceptions) or > having to learn to conjugate irregular verbs. Most illogical. That said, I > suppose we have to support it for backward compatibility. It doesn't seem to > be used that much, however, probably because it isn't obvious. > I think it's ok to revert this behavior for backwards compatibility, but believe it's an inconsistent and unintuitive choice. In broadcasting, there are two operations, growing a dimension 1 -> n, and appending a new 1 dimension to the left. The behaviour under discussion in assignment is different from normal broadcasting in that only the second one is permitted. It is broadcasting the output to the input, rather than broadcasting the input to the output. Suppose a has shape (20,), b has shape (1,20), and c has shape (20,1). Then a+b has shape (1,20), a+c has shape (20,20), and b+c has shape (20,20). If we do "b[...] = a", a will be broadcast to match b by adding a 1 dimension to the left. This is reasonable and consistent with addition. If we do "a[...]=b", under 1.5 rules, a will once again be broadcast to match b by adding a 1 dimension to the left. If we do "a[...]=c", we could broadcast both a and c together to the shape (20,20). This results in multiple assignments to each element of a, which is inconsistent. This is not analogous to a+c, but rather to np.add(c, c, out=a). The distinction is subtle, but the inconsistent behavior is harmless enough for assignment that keeping backwards compatibility seems reasonable. Cheers, Mark ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 9:00 PM, Travis Oliphant wrote: > My point is also that we need to make sure the broadcasting rules are > consistent for both addition and array copy. > > Addition would not create an error if a (1,20) array was added to a (20,) > array. Therefore, a (1,20) array can also copied into a (20,) array --- as > can a (1,1,1,1,20) array. Conversely, a (20,1) or a (1,1,20,1,1) array can > not be copied into a (20,) array. > Well, adding a (1,20) array to a (20,) array gives a (1,20) array. Changing this for assignment is like english spelling ( 'I' before 'e' except after 'c', or sounded 'a' as in neighbor and weigh -- with various exceptions) or having to learn to conjugate irregular verbs. Most illogical. That said, I suppose we have to support it for backward compatibility. It doesn't seem to be used that much, however, probably because it isn't obvious. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Mar 5, 2011, at 5:10 PM, Mark Wiebe wrote:
> On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers
> wrote:
>
>
> >>> I've had a look at the bug tracker, here's a list of tickets for 1.6:
> >>> #1748 (blocker: regression for astype('str'))
> >>> #1619 (issue with dtypes, with patch)
> >>> #1749 (distutils, py 3.2)
> >>> #1601 (distutils, py 3.2)
> >>> #1622 (Solaris segfault, with patch)
> >>> #1713 (Solaris segfault)
> >>> #1631 (Solaris segfault)
>
> The distutils tickets are resolved.
>
> >>> Proposed schedule:
> >>> March 15: beta 1
> >>> March 28: rc 1
> >>> April 17: rc 2 (if needed)
> >>> April 24: final release
>
> Any comments on the schedule or tickets?
>
> That all looks fine to me. There are a few things that I've changed in the
> core that could stand some discussion before being finalized in 1.6, mostly
> due to what was required to make things work without depending on the data
> type enumeration order. The combination of the numpy and scipy tests were
> pretty effective, but as Travis mentioned my changes are fairly invasive.
>
> * When copying array to array, structured types now copy based on field names
> instead of positions, effectively behaving like a 'dict' instead of a
> 'labeled tuple'. This behaviour is more intuitive to me, and several fixed
> bugs such as dtype comparison completely ignoring the structured type data
> suggest that this changes an area of numpy that has been used in a more
> limited fashion. It might be worthwhile to introduce a tuple-style flag in a
> future version which causes data to be copied by position instead of by name,
> as it is likely useful in some contexts.
This is a semantic change that does make me a tiny bit nervous.Structured
arrays are actually used quite a bit in the wild, and so this could raise some
errors. What I don't know is how often sub-parts of a structured arrays get
copied into other structured arrays with a different order to the fields.
From what I gather, Mark's changes would allow this case and do an arguably
useful thing.Previously, a copy was only allowed if the structured array
contained the same fields in the same order. It seems like this is a
relaxation of a rule and should not raise any errors (unless extant code was
relying on the previous errors for some reason).
>
> * Array memory layouts are preserved in many cases. This means that if a, b
> are Fortran ordered, a+b will be as well. It could be made more pervasive,
> for example ndarray.copy defaults to C-order, and that could be changed to
> 'K' to preserve the memory layout by default. Any comments about that?
I like this change quite a bit, but it has similar potential "expectation"
issues. I think the default should be changed to 'K' in NumPy 2.0, but
perhaps we should preserve C-order for now to avoid the subtle breakages that
might occur based on changed expectations.What are others thoughts?
>
> * The ufunc uses a more consistent algorithm for loop selection. The previous
> algorithm was ad hoc and lacked symmetry, while the new algorithm is based on
> a simple minimization definition. This change exposed a bug in scipy's
> ndimage, which did not handle all of the numpy data type enums properly, so
> its possible there is more code out there which will be affected similarly.
This change has me the most nervous. I'm looking forward to the more
consistent algorithm. As I said, the algorithm presently used as been there
since Numeric in 1995 (I modified it only a little bit to handle scalar-array
casting rules a bit differently).This kind of change will have different
corner cases and this should be understood before a release.
I'm also wondering what happened to the optional arguments to ufuncs (are they
still there)? One of these allowed you to choose the loop
yourself and bypass the selection algorithm.
>
> In general, I've used the implementation strategy of substituting my code
> into the core critical paths of numpy to maximize the amount of exercise it
> gets. While this creates more short-term hiccups as we are seeing now, it
> also means the new functionality conforms to the current system better and is
> much more stable since it is getting well tested.
Thanks again for all the good core-algorithm work, Mark. You have being doing
a great job.
-Travis
>
> -Mark
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
Enthought, Inc.
oliph...@enthought.com
1-512-536-1057
http://www.enthought.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
My point is also that we need to make sure the broadcasting rules are consistent for both addition and array copy. Addition would not create an error if a (1,20) array was added to a (20,) array. Therefore, a (1,20) array can also copied into a (20,) array --- as can a (1,1,1,1,20) array. Conversely, a (20,1) or a (1,1,20,1,1) array can not be copied into a (20,) array. For the purposes of assignment, NumPy was designed so that if the rhs and lhs could be broadcast to the same shape, then the assignment could proceed: otherwise, it would fail. This behavior should not change in 1.6. -Travis On Mar 5, 2011, at 8:51 PM, Charles R Harris wrote: > > > On Sat, Mar 5, 2011 at 7:41 PM, Charles R Harris > wrote: > > > On Sat, Mar 5, 2011 at 7:23 PM, Enthought wrote: > This should be changed back so that the former works and the later does not. > It was intentional that the former worked --- it was consistent with > broadcasting rules. > > A (1,20) array can be interpreted as a (20,) array. > > > So should a (1,1,1,1,20) array also be interpreted as a (20,) array? From > what you say, an arbitrary number of 1's can not only be appended on the > left, the usual broadcasting, but an arbitrary number of 1's can also be > removed. Is that so? > > > The point being, that assignment is now a special case that does not follow > the same rules as, say, addition. > > Chuck > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliph...@enthought.com 1-512-536-1057 http://www.enthought.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 7:41 PM, Charles R Harris wrote: > > > On Sat, Mar 5, 2011 at 7:23 PM, Enthought wrote: > >> This should be changed back so that the former works and the later does >> not. It was intentional that the former worked --- it was consistent with >> broadcasting rules. >> >> A (1,20) array can be interpreted as a (20,) array. >> >> > So should a (1,1,1,1,20) array also be interpreted as a (20,) array? From > what you say, an arbitrary number of 1's can not only be appended on the > left, the usual broadcasting, but an arbitrary number of 1's can also be > removed. Is that so? > > The point being, that assignment is now a special case that does not follow the same rules as, say, addition. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 7:23 PM, Enthought wrote: > This should be changed back so that the former works and the later does > not. It was intentional that the former worked --- it was consistent with > broadcasting rules. > > A (1,20) array can be interpreted as a (20,) array. > > So should a (1,1,1,1,20) array also be interpreted as a (20,) array? From what you say, an arbitrary number of 1's can not only be appended on the left, the usual broadcasting, but an arbitrary number of 1's can also be removed. Is that so? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
This should be changed back so that the former works and the later does not. It was intentional that the former worked --- it was consistent with broadcasting rules. A (1,20) array can be interpreted as a (20,) array. Travis (mobile phone of) Travis Oliphant Enthought, Inc. www.enthought.com On Mar 5, 2011, at 6:53 PM, Charles R Harris wrote: > > > On Sat, Mar 5, 2011 at 4:20 PM, Mark Wiebe wrote: > On Sat, Mar 5, 2011 at 2:43 PM, Charles R Harris > wrote: > On Sat, Mar 5, 2011 at 3:28 PM, Benjamin Root wrote: > > > On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen wrote: > On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: > > I recently had to fix an example in matplotlib where there was a 1xN > > array being assigned to a 1-D slice of a numpy array. It used to work, > > but it now doesn't. I don't know if this was intended or not, though. > > Probably not -- please file a bug report. If you can also point to a > Numpy version in which it worked, that would also be nice. > > > I decided to give git bisect a try. In testing this, I tried two things: > > a = np.empty((20,)) > a[:] = np.random.random((1, 20)) > > and > > a[:] = np.random.random((20, 1)) > > These both currently fail with the same exception message. If I check out > and build v1.5.0, the former works, but the latter does not. Going back to > v1.4.0, and the latter still doesn't work. Maybe this really shouldn't be > considered a bug, and rather a more consistent behavior? > > By the way, git bisect says that the winner is: > > d90f19abf18d59be959e04d73b3dbd7ae04b1e89 is the first bad commit > commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89 > Author: Mark Wiebe > Date: Mon Jan 17 18:26:12 2011 -0800 > > ENH: core: Change PyArray_MoveInto to use the new iterator as well > > :04 04 a23fbcff385fca9704a5313e81217a6d80e3512c > 09b684bd8893e44405534fedad165ce85e751019 Mnumpy > > If we agree that this is still a bug and not a feature, I will file a report. > > > I think it is more of a feature. The assignment should probably only work if > the rhs can be broadcast to the lhs. Whatever is decided, we need to make a > test to enforce it. > > +1 for feature. I like stricter checking in most cases. > > > Although I think this accounts for some of the failures in tables. > > 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
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 4:20 PM, Mark Wiebe wrote: > On Sat, Mar 5, 2011 at 2:43 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> On Sat, Mar 5, 2011 at 3:28 PM, Benjamin Root wrote: >> >>> >>> >>> On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen wrote: >>> On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: > I recently had to fix an example in matplotlib where there was a 1xN > array being assigned to a 1-D slice of a numpy array. It used to work, > but it now doesn't. I don't know if this was intended or not, though. Probably not -- please file a bug report. If you can also point to a Numpy version in which it worked, that would also be nice. >>> I decided to give git bisect a try. In testing this, I tried two things: >>> >>> a = np.empty((20,)) >>> a[:] = np.random.random((1, 20)) >>> >>> and >>> >>> a[:] = np.random.random((20, 1)) >>> >>> These both currently fail with the same exception message. If I check >>> out and build v1.5.0, the former works, but the latter does not. Going back >>> to v1.4.0, and the latter still doesn't work. Maybe this really shouldn't >>> be considered a bug, and rather a more consistent behavior? >>> >>> By the way, git bisect says that the winner is: >>> >>> d90f19abf18d59be959e04d73b3dbd7ae04b1e89 is the first bad commit >>> commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89 >>> Author: Mark Wiebe >>> Date: Mon Jan 17 18:26:12 2011 -0800 >>> >>> ENH: core: Change PyArray_MoveInto to use the new iterator as well >>> >>> :04 04 a23fbcff385fca9704a5313e81217a6d80e3512c >>> 09b684bd8893e44405534fedad165ce85e751019 Mnumpy >>> >>> If we agree that this is still a bug and not a feature, I will file a >>> report. >>> >>> >> I think it is more of a feature. The assignment should probably only work >> if the rhs can be broadcast to the lhs. Whatever is decided, we need to make >> a test to enforce it. >> > > +1 for feature. I like stricter checking in most cases. > > Although I think this accounts for some of the failures in tables. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 5:10 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke wrote:
>
>>
>>
>> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>> >
>> >
>> > On 3/3/2011 10:54 PM, Ralf Gommers wrote:
>> >> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
>> >> wrote:
>> >>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
>> >>> wrote:
>> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
>> > Hi,
>> >
>> > On Fri, Jan 28, 2011 at 7:15 AM, Travis
>> > Oliphant wrote:
>> >> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
>> >> would
>> >> seem) have additional work and features that do not need to wait
>> >> for the
>> >> NumPy 2.0 ABI design to finalize in order to get out there.
>> >> If someone is willing to manage the release of NumPy 1.6, then it
>> >> sounds
>> >> like a great idea to me.
>> > This thread ended without a conclusion a month ago. Now I think
>> master
>> > is in a better state than a month ago for a release (py 2.4/2.5/3.x
>> > issues and segfault on OS X fixed, more testing of changes), and I
>> > have a better idea of my free time for March/April. Basically, I
>> have
>> > a good amount of time for the next couple of weeks, and not so much
>> at
>> > the end of March / first half of April due to an inter-continental
>> > move. But I think we can get out a beta by mid-March, and I can
>> manage
>> > the release.
>> >
>> > I've had a look at the bug tracker, here's a list of tickets for
>> 1.6:
>> > #1748 (blocker: regression for astype('str'))
>> > #1619 (issue with dtypes, with patch)
>> > #1749 (distutils, py 3.2)
>> > #1601 (distutils, py 3.2)
>> > #1622 (Solaris segfault, with patch)
>> > #1713 (Solaris segfault)
>> > #1631 (Solaris segfault)
>> >>
>> >> The distutils tickets are resolved.
>> >>
>> > Proposed schedule:
>> > March 15: beta 1
>> > March 28: rc 1
>> > April 17: rc 2 (if needed)
>> > April 24: final release
>> >>
>> >> Any comments on the schedule or tickets?
>> >>
>> >> Before the first beta can be released I think #1748 should be fixed.
>> >> Before the first RC the Solaris segfaults should be investigated, and
>> >> documentation for the new iterator (Python docstrings and C API docs)
>> >> and datetime should be written.
>> >>
>> >> Also, some testing on 64-bit Windows would be great, that usually
>> >> turns up new issues so the sooner the better.
>> >>
>> >> Ralf
>> >
>> > Hi Ralf,
>> >
>> > the numpy master branch on github can not be compiled with Visual
>> > Studio. A patch is attached. I'll test the builds tomorrow.
>> >
>> > Christoph
>> >
>>
>> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
>> There are few test failures (listed below) that look familiar.
>>
>> I also ran tests and/or examples of a few 3rd party packages that were
>> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
>> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
>>
>> Most packages don't have any apparent problems.
>> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
>> failure/error (also listed below).
>>
>> There is a problem with code generated by Cython 0.13: pytables-2.2.1
>> and pandas-0.3.0, which were built with Cython 0.13, report several
>> failures and do crash during the tests. This can probably be fixed by
>> "recythonizing" with Cython 0.14.1.
>>
>>
> The tables segfault is fixed, although other errors remain. Pandas still
> segfaults and I'm guessing that the problem is somewhere in the creation of
> object arrays/subtypes. The short code to reproduce the problem is
>
> >>> import pandas
> >>> import pandas.util.testing as common
> >>> df = common.makeTimeDataFrame()
> >>> objs = [df, df]
> >>> s = Series(objs, index=[0, 1])
>
>
>
Make that
>>> import pandas
>>> import pandas.util.testing as common
>>> df = common.makeTimeDataFrame()
>>> objs = [df, df]
>>> s = pandas.Series(objs, index=[0, 1])
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke wrote:
>
>
> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
> >
> >
> > On 3/3/2011 10:54 PM, Ralf Gommers wrote:
> >> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
> >> wrote:
> >>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
> >>> wrote:
> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
> > Hi,
> >
> > On Fri, Jan 28, 2011 at 7:15 AM, Travis
> > Oliphant wrote:
> >> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
> >> would
> >> seem) have additional work and features that do not need to wait
> >> for the
> >> NumPy 2.0 ABI design to finalize in order to get out there.
> >> If someone is willing to manage the release of NumPy 1.6, then it
> >> sounds
> >> like a great idea to me.
> > This thread ended without a conclusion a month ago. Now I think
> master
> > is in a better state than a month ago for a release (py 2.4/2.5/3.x
> > issues and segfault on OS X fixed, more testing of changes), and I
> > have a better idea of my free time for March/April. Basically, I have
> > a good amount of time for the next couple of weeks, and not so much
> at
> > the end of March / first half of April due to an inter-continental
> > move. But I think we can get out a beta by mid-March, and I can
> manage
> > the release.
> >
> > I've had a look at the bug tracker, here's a list of tickets for 1.6:
> > #1748 (blocker: regression for astype('str'))
> > #1619 (issue with dtypes, with patch)
> > #1749 (distutils, py 3.2)
> > #1601 (distutils, py 3.2)
> > #1622 (Solaris segfault, with patch)
> > #1713 (Solaris segfault)
> > #1631 (Solaris segfault)
> >>
> >> The distutils tickets are resolved.
> >>
> > Proposed schedule:
> > March 15: beta 1
> > March 28: rc 1
> > April 17: rc 2 (if needed)
> > April 24: final release
> >>
> >> Any comments on the schedule or tickets?
> >>
> >> Before the first beta can be released I think #1748 should be fixed.
> >> Before the first RC the Solaris segfaults should be investigated, and
> >> documentation for the new iterator (Python docstrings and C API docs)
> >> and datetime should be written.
> >>
> >> Also, some testing on 64-bit Windows would be great, that usually
> >> turns up new issues so the sooner the better.
> >>
> >> Ralf
> >
> > Hi Ralf,
> >
> > the numpy master branch on github can not be compiled with Visual
> > Studio. A patch is attached. I'll test the builds tomorrow.
> >
> > Christoph
> >
>
> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
> There are few test failures (listed below) that look familiar.
>
> I also ran tests and/or examples of a few 3rd party packages that were
> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
>
> Most packages don't have any apparent problems.
> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
> failure/error (also listed below).
>
> There is a problem with code generated by Cython 0.13: pytables-2.2.1
> and pandas-0.3.0, which were built with Cython 0.13, report several
> failures and do crash during the tests. This can probably be fixed by
> "recythonizing" with Cython 0.14.1.
>
>
The tables segfault is fixed, although other errors remain. Pandas still
segfaults and I'm guessing that the problem is somewhere in the creation of
object arrays/subtypes. The short code to reproduce the problem is
>>> import pandas
>>> import pandas.util.testing as common
>>> df = common.makeTimeDataFrame()
>>> objs = [df, df]
>>> s = Series(objs, index=[0, 1])
ISTR that the behaviour of numpy with respect to the creation of object
arrays might have changed a bit.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 2:43 PM, Charles R Harris wrote: > On Sat, Mar 5, 2011 at 3:28 PM, Benjamin Root wrote: > >> >> >> On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen wrote: >> >>> On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: >>> > I recently had to fix an example in matplotlib where there was a 1xN >>> > array being assigned to a 1-D slice of a numpy array. It used to work, >>> > but it now doesn't. I don't know if this was intended or not, though. >>> >>> Probably not -- please file a bug report. If you can also point to a >>> Numpy version in which it worked, that would also be nice. >>> >>> >> I decided to give git bisect a try. In testing this, I tried two things: >> >> a = np.empty((20,)) >> a[:] = np.random.random((1, 20)) >> >> and >> >> a[:] = np.random.random((20, 1)) >> >> These both currently fail with the same exception message. If I check out >> and build v1.5.0, the former works, but the latter does not. Going back to >> v1.4.0, and the latter still doesn't work. Maybe this really shouldn't be >> considered a bug, and rather a more consistent behavior? >> >> By the way, git bisect says that the winner is: >> >> d90f19abf18d59be959e04d73b3dbd7ae04b1e89 is the first bad commit >> commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89 >> Author: Mark Wiebe >> Date: Mon Jan 17 18:26:12 2011 -0800 >> >> ENH: core: Change PyArray_MoveInto to use the new iterator as well >> >> :04 04 a23fbcff385fca9704a5313e81217a6d80e3512c >> 09b684bd8893e44405534fedad165ce85e751019 Mnumpy >> >> If we agree that this is still a bug and not a feature, I will file a >> report. >> >> > I think it is more of a feature. The assignment should probably only work > if the rhs can be broadcast to the lhs. Whatever is decided, we need to make > a test to enforce it. > +1 for feature. I like stricter checking in most cases. -Mark ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 8:37 PM, Ralf Gommers wrote: > On Fri, Mar 4, 2011 at 5:00 PM, Christoph Gohlke wrote: > > > > > > On 3/3/2011 10:54 PM, Ralf Gommers wrote: > >> Before the first beta can be released I think #1748 should be fixed. > >> Before the first RC the Solaris segfaults should be investigated, and > >> documentation for the new iterator (Python docstrings and C API docs) > >> and datetime should be written. > >> > >> Also, some testing on 64-bit Windows would be great, that usually > >> turns up new issues so the sooner the better. > >> > >> Ralf > > > > Hi Ralf, > > > > the numpy master branch on github can not be compiled with Visual Studio. > A > > patch is attached. I'll test the builds tomorrow. > > That looks fine to me, but I'll leave it to someone more familiar with > that code to commit it. > > I'm also wondering whether the printf debug code should not be removed > completely. Either way, using variadic macros is not a good idea I > think, since that's a C99 feature which seems to not be supported well > by non-gcc compilers. > If the approach to fixing it in the patch works, I'd like to keep the debug prints in. They don't affect run time, and can be useful to figure out where something is first deviating from the expected behavior when dealing with subtle bugs. -Mark ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers
wrote:
>
>
> >>> I've had a look at the bug tracker, here's a list of tickets for 1.6:
> >>> #1748 (blocker: regression for astype('str'))
> >>> #1619 (issue with dtypes, with patch)
> >>> #1749 (distutils, py 3.2)
> >>> #1601 (distutils, py 3.2)
> >>> #1622 (Solaris segfault, with patch)
> >>> #1713 (Solaris segfault)
> >>> #1631 (Solaris segfault)
>
> The distutils tickets are resolved.
>
> >>> Proposed schedule:
> >>> March 15: beta 1
> >>> March 28: rc 1
> >>> April 17: rc 2 (if needed)
> >>> April 24: final release
>
> Any comments on the schedule or tickets?
>
That all looks fine to me. There are a few things that I've changed in the
core that could stand some discussion before being finalized in 1.6, mostly
due to what was required to make things work without depending on the data
type enumeration order. The combination of the numpy and scipy tests were
pretty effective, but as Travis mentioned my changes are fairly invasive.
* When copying array to array, structured types now copy based on field
names instead of positions, effectively behaving like a 'dict' instead of a
'labeled tuple'. This behaviour is more intuitive to me, and several fixed
bugs such as dtype comparison completely ignoring the structured type data
suggest that this changes an area of numpy that has been used in a more
limited fashion. It might be worthwhile to introduce a tuple-style flag in a
future version which causes data to be copied by position instead of by
name, as it is likely useful in some contexts.
* Array memory layouts are preserved in many cases. This means that if a, b
are Fortran ordered, a+b will be as well. It could be made more pervasive,
for example ndarray.copy defaults to C-order, and that could be changed to
'K' to preserve the memory layout by default. Any comments about that?
* The ufunc uses a more consistent algorithm for loop selection. The
previous algorithm was ad hoc and lacked symmetry, while the new algorithm
is based on a simple minimization definition. This change exposed a bug in
scipy's ndimage, which did not handle all of the numpy data type enums
properly, so its possible there is more code out there which will be
affected similarly.
In general, I've used the implementation strategy of substituting my code
into the core critical paths of numpy to maximize the amount of exercise it
gets. While this creates more short-term hiccups as we are seeing now, it
also means the new functionality conforms to the current system better and
is much more stable since it is getting well tested.
-Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 3:28 PM, Benjamin Root wrote: > > > On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen wrote: > >> On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: >> > I recently had to fix an example in matplotlib where there was a 1xN >> > array being assigned to a 1-D slice of a numpy array. It used to work, >> > but it now doesn't. I don't know if this was intended or not, though. >> >> Probably not -- please file a bug report. If you can also point to a >> Numpy version in which it worked, that would also be nice. >> >> > I decided to give git bisect a try. In testing this, I tried two things: > > a = np.empty((20,)) > a[:] = np.random.random((1, 20)) > > and > > a[:] = np.random.random((20, 1)) > > These both currently fail with the same exception message. If I check out > and build v1.5.0, the former works, but the latter does not. Going back to > v1.4.0, and the latter still doesn't work. Maybe this really shouldn't be > considered a bug, and rather a more consistent behavior? > > By the way, git bisect says that the winner is: > > d90f19abf18d59be959e04d73b3dbd7ae04b1e89 is the first bad commit > commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89 > Author: Mark Wiebe > Date: Mon Jan 17 18:26:12 2011 -0800 > > ENH: core: Change PyArray_MoveInto to use the new iterator as well > > :04 04 a23fbcff385fca9704a5313e81217a6d80e3512c > 09b684bd8893e44405534fedad165ce85e751019 Mnumpy > > If we agree that this is still a bug and not a feature, I will file a > report. > > I think it is more of a feature. The assignment should probably only work if the rhs can be broadcast to the lhs. Whatever is decided, we need to make a test to enforce it. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 7:44 AM, Pauli Virtanen wrote: > On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: > > I recently had to fix an example in matplotlib where there was a 1xN > > array being assigned to a 1-D slice of a numpy array. It used to work, > > but it now doesn't. I don't know if this was intended or not, though. > > Probably not -- please file a bug report. If you can also point to a > Numpy version in which it worked, that would also be nice. > > I decided to give git bisect a try. In testing this, I tried two things: a = np.empty((20,)) a[:] = np.random.random((1, 20)) and a[:] = np.random.random((20, 1)) These both currently fail with the same exception message. If I check out and build v1.5.0, the former works, but the latter does not. Going back to v1.4.0, and the latter still doesn't work. Maybe this really shouldn't be considered a bug, and rather a more consistent behavior? By the way, git bisect says that the winner is: d90f19abf18d59be959e04d73b3dbd7ae04b1e89 is the first bad commit commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89 Author: Mark Wiebe Date: Mon Jan 17 18:26:12 2011 -0800 ENH: core: Change PyArray_MoveInto to use the new iterator as well :04 04 a23fbcff385fca9704a5313e81217a6d80e3512c 09b684bd8893e44405534fedad165ce85e751019 Mnumpy If we agree that this is still a bug and not a feature, I will file a report. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 4:15 AM, Francesc Alted wrote: > A Saturday 05 March 2011 02:41:12 Charles R Harris escrigué: > > > There is a problem with code generated by Cython 0.13: > > > pytables-2.2.1 and pandas-0.3.0, which were built with Cython > > > 0.13, report several failures and do crash during the tests. This > > > can probably be fixed by "recythonizing" with Cython 0.14.1. > > > > I see pytables crash on Fedora 14 64 bit also, even with freshly > > built pytables/numexpr. > > I'm in a hurry now, but I isolated one problem in the master branch of > NumPy that is creating segfaults: > > http://projects.scipy.org/numpy/ticket/1756 > > Next week, I'll look into other issues in PyTables test suite w/ NumPy > 1.6. > > The segfault should be fixed in 9eee670, but there remain other errors and failures. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, 04 Mar 2011 22:58:14 -0600, Benjamin Root wrote: > I recently had to fix an example in matplotlib where there was a 1xN > array being assigned to a 1-D slice of a numpy array. It used to work, > but it now doesn't. I don't know if this was intended or not, though. Probably not -- please file a bug report. If you can also point to a Numpy version in which it worked, that would also be nice. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
A Saturday 05 March 2011 02:41:12 Charles R Harris escrigué: > > There is a problem with code generated by Cython 0.13: > > pytables-2.2.1 and pandas-0.3.0, which were built with Cython > > 0.13, report several failures and do crash during the tests. This > > can probably be fixed by "recythonizing" with Cython 0.14.1. > > I see pytables crash on Fedora 14 64 bit also, even with freshly > built pytables/numexpr. I'm in a hurry now, but I isolated one problem in the master branch of NumPy that is creating segfaults: http://projects.scipy.org/numpy/ticket/1756 Next week, I'll look into other issues in PyTables test suite w/ NumPy 1.6. -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 11:11 AM, Charles R Harris wrote: > On Fri, Mar 4, 2011 at 7:49 PM, Charles R Harris > wrote: >> On Fri, Mar 4, 2011 at 6:41 PM, Charles R Harris >> wrote: >>> On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke >>> wrote: Most packages don't have any apparent problems. Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test failure/error (also listed below). There is a problem with code generated by Cython 0.13: pytables-2.2.1 and pandas-0.3.0, which were built with Cython 0.13, report several failures and do crash during the tests. This can probably be fixed by "recythonizing" with Cython 0.14.1. >>> >>> I see pytables crash on Fedora 14 64 bit also, even with freshly built >>> pytables/numexpr. That's actually good news, right? Looks like it's not due to a backwards incompatibility. On a related note, can we do something about this: $ python setup.py build_ext -i Running from numpy source directory.non-existing path in 'numpy/distutils': 'site.cfg' F2PY Version 2 numpy/core/setup_common.py:86: MismatchCAPIWarning: API mismatch detected, the C API version numbers have to be updated. Current C api version is 5, with checksum 941534d1afbc085b996141e8027d1d1e, but recorded checksum for C API version 5 in codegen_dir/cversions.txt is 77e2e846db87f25d7cf99f9d812076f0. If functions were added in the C API, you have to update C_API_VERSION in numpy/core/setup_common.py. MismatchCAPIWarning) Ralf >> Backtrace >> >> #0 0x003e9647a52c in __libc_free (mem=0x16cd1f0) at malloc.c:3724 >> #1 0x7fffefed0988 in array_dealloc (self=0x29617b0) >> at numpy/core/src/multiarray/arrayobject.c:266 >> #2 0x003ea84e8452 in PyEval_EvalFrameEx (f=, >> throwflag=) >> at /usr/src/debug/Python-2.7/Python/ceval.c:2344 >> #3 0x003ea84ea71d in fast_function (f=, >> throwflag=) >> at /usr/src/debug/Python-2.7/Python/ceval.c:4157 >> #4 call_function (f=, throwflag=> out>) >> at /usr/src/debug/Python-2.7/Python/ceval.c:4092 >> >> > > And a test failure before the crash: > > Running MDAtomReopen.test01a_assign > --- > > Error in test:: > > ValueError: value parameter '[[[1 3] > [4 5]]]' cannot be converted into an array object > compliant with CArray: '/test (CArray(1,)) '' > atom := Int32Atom(shape=(2, 2), dflt=array([[0, 0], > [0, 0]], dtype=int32)) > maindim := 0 > flavor := 'numpy' > byteorder := 'little' > chunkshape := (4096,)' The error was: with shape (2,2) doesn't match the broadcast shape (2,2,1)> > > Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 9:11 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 4, 2011 at 7:49 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 4, 2011 at 6:41 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke wrote:
>>>
On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>
>
> On 3/3/2011 10:54 PM, Ralf Gommers wrote:
>> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
>> wrote:
>>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
>>> wrote:
On 02/28/2011 02:00 AM, Ralf Gommers wrote:
> Hi,
>
> On Fri, Jan 28, 2011 at 7:15 AM, Travis
> Oliphant wrote:
>> The reason for a NumPy 1.6 suggestion, is that Mark (and others
it
>> would
>> seem) have additional work and features that do not need to wait
>> for the
>> NumPy 2.0 ABI design to finalize in order to get out there.
>> If someone is willing to manage the release of NumPy 1.6, then it
>> sounds
>> like a great idea to me.
> This thread ended without a conclusion a month ago. Now I think
master
> is in a better state than a month ago for a release (py
2.4/2.5/3.x
> issues and segfault on OS X fixed, more testing of changes), and I
> have a better idea of my free time for March/April. Basically, I
have
> a good amount of time for the next couple of weeks, and not so
much at
> the end of March / first half of April due to an inter-continental
> move. But I think we can get out a beta by mid-March, and I can
manage
> the release.
>
> I've had a look at the bug tracker, here's a list of tickets for
1.6:
> #1748 (blocker: regression for astype('str'))
> #1619 (issue with dtypes, with patch)
> #1749 (distutils, py 3.2)
> #1601 (distutils, py 3.2)
> #1622 (Solaris segfault, with patch)
> #1713 (Solaris segfault)
> #1631 (Solaris segfault)
>>
>> The distutils tickets are resolved.
>>
> Proposed schedule:
> March 15: beta 1
> March 28: rc 1
> April 17: rc 2 (if needed)
> April 24: final release
>>
>> Any comments on the schedule or tickets?
>>
>> Before the first beta can be released I think #1748 should be fixed.
>> Before the first RC the Solaris segfaults should be investigated, and
>> documentation for the new iterator (Python docstrings and C API docs)
>> and datetime should be written.
>>
>> Also, some testing on 64-bit Windows would be great, that usually
>> turns up new issues so the sooner the better.
>>
>> Ralf
>
> Hi Ralf,
>
> the numpy master branch on github can not be compiled with Visual
> Studio. A patch is attached. I'll test the builds tomorrow.
>
> Christoph
>
I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
There are few test failures (listed below) that look familiar.
I also ran tests and/or examples of a few 3rd party packages that were
built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
Most packages don't have any apparent problems.
Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
failure/error (also listed below).
There is a problem with code generated by Cython 0.13: pytables-2.2.1
and pandas-0.3.0, which were built with Cython 0.13, report several
failures and do crash during the tests. This can probably be fixed by
"recythonizing" with Cython 0.14.1.
>>> I see pytables crash on Fedora 14 64 bit also, even with freshly built
>>> pytables/numexpr.
>>>
>>
>> Backtrace
>>
>> #0 0x003e9647a52c in __libc_free (mem=0x16cd1f0) at malloc.c:3724
>> #1 0x7fffefed0988 in array_dealloc (self=0x29617b0)
>> at numpy/core/src/multiarray/arrayobject.c:266
>> #2 0x003ea84e8452 in PyEval_EvalFrameEx (f=,
>> throwflag=)
>> at /usr/src/debug/Python-2.7/Python/ceval.c:2344
>> #3 0x003ea84ea71d in fast_function (f=,
>> throwflag=)
>> at /usr/src/debug/Python-2.7/Python/ceval.c:4157
>> #4 call_function (f=, throwflag=> out>)
>> at /usr/src/debug/Python-2.7/Python/ceval.c:4092
>>
>>
>>
>
> And a test failure before the crash:
>
> Running MDAtomReopen.test01a_assign
> ---
>
> Error in test::
>
> ValueError: value parameter '[[[1 3]
> [4 5]]]' cannot be converted into an array object
> compliant with CArray: '/test (CArray(1,)) ''
> atom := Int32Atom(shape=(2, 2), dflt=array([[0, 0],
>[0, 0]], dtype=int32))
> maindim := 0
> flavor := 'numpy'
> byteorder :=
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Sat, Mar 5, 2011 at 3:54 AM, Christoph Gohlke wrote:
>
>
> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>
> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
> There are few test failures (listed below) that look familiar.
>
> I also ran tests and/or examples of a few 3rd party packages that were
> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
Thanks a lot for all the testing Christoph, that's very helpful!
> Most packages don't have any apparent problems.
> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
> failure/error (also listed below).
>
> There is a problem with code generated by Cython 0.13: pytables-2.2.1
> and pandas-0.3.0, which were built with Cython 0.13, report several
> failures and do crash during the tests. This can probably be fixed by
> "recythonizing" with Cython 0.14.1.
>
> Christoph
>
>
>
>
> numpy-1.6.1.dev-win-amd64-py2.7
>
> ==
> ERROR: Ticket #99
> --
> Traceback (most recent call last):
> File "X:\Python27-x64\lib\site-packages\numpy\testing\decorators.py",
> line 215, in knownfailer
> return f(*args, **kwargs)
> File
> "X:\Python27-x64\lib\site-packages\numpy\core\tests\test_regression.py",
> line 147, in test_intp
> np.intp('0x' + 'f'*i_width,16)
> TypeError: function takes at most 1 argument (2 given)
This was discussed before,
http://thread.gmane.org/gmane.comp.python.numeric.general/40121
It can be marked as knownfail in the 1.6.x branch if no one gets
around to looking at it.
> ==
> FAIL: test_special_values (test_umath_complex.TestClog)
> --
> Traceback (most recent call last):
> File "X:\Python27-x64\lib\site-packages\numpy\testing\decorators.py",
> line 146, in skipper_func
> return f(*args, **kwargs)
> File
> "X:\Python27-x64\lib\site-packages\numpy\core\tests\test_umath_complex.py",
> line 248, in test_special_values
> assert_almost_equal(np.log(x), y)
> File "X:\Python27-x64\lib\site-packages\numpy\testing\utils.py", line
> 443, in assert_almost_equal
> raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 7 decimals
> ACTUAL: array([ nan+2.35619449j])
> DESIRED: (inf+2.356194490192345j)
>
>
>
>
> numpy-1.6.1.dev-win-amd64-py3.2
>
> ==
> FAIL: test_special_values (test_umath_complex.TestClog)
> --
> Traceback (most recent call last):
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 588, in assert_array_compare
> assert_array_equal(xnanid, ynanid)
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 687, in assert_array_equal
> verbose=verbose, header='Arrays are not equal')
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 618, in assert_array_compare
> raise AssertionError(msg)
> AssertionError:
> Arrays are not equal
>
> (mismatch 100.0%)
> x: array([ True], dtype=bool)
> y: array(False, dtype=bool)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 440, in assert_almost_equal
> assert_almost_equal(actualr, desiredr, decimal=decimal)
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 447, in assert_almost_equal
> return assert_array_almost_equal(actual, desired, decimal, err_msg)
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 775, in assert_array_almost_equal
> header=('Arrays are not almost equal to %d decimals' % decimal))
> AssertionError:
> Arrays are not almost equal to 7 decimals
>
> (x and y nan location mismatch [ True], False mismatch)
> x: array([ nan])
> y: array(inf)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "X:\Python32\lib\site-packages\numpy\testing\decorators.py",
> line 147, in skipper_func
> return f(*args, **kwargs)
> File
> "X:\Python32\lib\site-packages\numpy\core\tests\test_umath_complex.py",
> line 248, in test_special_values
> assert_almost_equal(np.log(x), y)
> File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
> 443, in assert_almost_equal
> raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 7 decimals
> ACTUAL: array([ nan+2.35619449j])
> DESIRED: (inf+2.356194490192345j)
Those TestClog are marked as conditional knownfail on Windows
depending on a check for a few corner cases, I'm thinking it should
just be unconditional knownfail on Windows.
>
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 5:00 PM, Christoph Gohlke wrote: > > > On 3/3/2011 10:54 PM, Ralf Gommers wrote: >> Before the first beta can be released I think #1748 should be fixed. >> Before the first RC the Solaris segfaults should be investigated, and >> documentation for the new iterator (Python docstrings and C API docs) >> and datetime should be written. >> >> Also, some testing on 64-bit Windows would be great, that usually >> turns up new issues so the sooner the better. >> >> Ralf > > Hi Ralf, > > the numpy master branch on github can not be compiled with Visual Studio. A > patch is attached. I'll test the builds tomorrow. That looks fine to me, but I'll leave it to someone more familiar with that code to commit it. I'm also wondering whether the printf debug code should not be removed completely. Either way, using variadic macros is not a good idea I think, since that's a C99 feature which seems to not be supported well by non-gcc compilers. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 7:49 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 4, 2011 at 6:41 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke wrote:
>>
>>>
>>>
>>> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>>> >
>>> >
>>> > On 3/3/2011 10:54 PM, Ralf Gommers wrote:
>>> >> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
>>> >> wrote:
>>> >>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
>>> >>> wrote:
>>> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
>>> > Hi,
>>> >
>>> > On Fri, Jan 28, 2011 at 7:15 AM, Travis
>>> > Oliphant wrote:
>>> >> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
>>> >> would
>>> >> seem) have additional work and features that do not need to wait
>>> >> for the
>>> >> NumPy 2.0 ABI design to finalize in order to get out there.
>>> >> If someone is willing to manage the release of NumPy 1.6, then it
>>> >> sounds
>>> >> like a great idea to me.
>>> > This thread ended without a conclusion a month ago. Now I think
>>> master
>>> > is in a better state than a month ago for a release (py 2.4/2.5/3.x
>>> > issues and segfault on OS X fixed, more testing of changes), and I
>>> > have a better idea of my free time for March/April. Basically, I
>>> have
>>> > a good amount of time for the next couple of weeks, and not so much
>>> at
>>> > the end of March / first half of April due to an inter-continental
>>> > move. But I think we can get out a beta by mid-March, and I can
>>> manage
>>> > the release.
>>> >
>>> > I've had a look at the bug tracker, here's a list of tickets for
>>> 1.6:
>>> > #1748 (blocker: regression for astype('str'))
>>> > #1619 (issue with dtypes, with patch)
>>> > #1749 (distutils, py 3.2)
>>> > #1601 (distutils, py 3.2)
>>> > #1622 (Solaris segfault, with patch)
>>> > #1713 (Solaris segfault)
>>> > #1631 (Solaris segfault)
>>> >>
>>> >> The distutils tickets are resolved.
>>> >>
>>> > Proposed schedule:
>>> > March 15: beta 1
>>> > March 28: rc 1
>>> > April 17: rc 2 (if needed)
>>> > April 24: final release
>>> >>
>>> >> Any comments on the schedule or tickets?
>>> >>
>>> >> Before the first beta can be released I think #1748 should be fixed.
>>> >> Before the first RC the Solaris segfaults should be investigated, and
>>> >> documentation for the new iterator (Python docstrings and C API docs)
>>> >> and datetime should be written.
>>> >>
>>> >> Also, some testing on 64-bit Windows would be great, that usually
>>> >> turns up new issues so the sooner the better.
>>> >>
>>> >> Ralf
>>> >
>>> > Hi Ralf,
>>> >
>>> > the numpy master branch on github can not be compiled with Visual
>>> > Studio. A patch is attached. I'll test the builds tomorrow.
>>> >
>>> > Christoph
>>> >
>>>
>>> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
>>> There are few test failures (listed below) that look familiar.
>>>
>>> I also ran tests and/or examples of a few 3rd party packages that were
>>> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
>>> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
>>>
>>> Most packages don't have any apparent problems.
>>> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
>>> failure/error (also listed below).
>>>
>>> There is a problem with code generated by Cython 0.13: pytables-2.2.1
>>> and pandas-0.3.0, which were built with Cython 0.13, report several
>>> failures and do crash during the tests. This can probably be fixed by
>>> "recythonizing" with Cython 0.14.1.
>>>
>>>
>> I see pytables crash on Fedora 14 64 bit also, even with freshly built
>> pytables/numexpr.
>>
>
> Backtrace
>
> #0 0x003e9647a52c in __libc_free (mem=0x16cd1f0) at malloc.c:3724
> #1 0x7fffefed0988 in array_dealloc (self=0x29617b0)
> at numpy/core/src/multiarray/arrayobject.c:266
> #2 0x003ea84e8452 in PyEval_EvalFrameEx (f=,
> throwflag=)
> at /usr/src/debug/Python-2.7/Python/ceval.c:2344
> #3 0x003ea84ea71d in fast_function (f=,
> throwflag=)
> at /usr/src/debug/Python-2.7/Python/ceval.c:4157
> #4 call_function (f=, throwflag= out>)
> at /usr/src/debug/Python-2.7/Python/ceval.c:4092
>
>
>
And a test failure before the crash:
Running MDAtomReopen.test01a_assign
---
Error in test::
ValueError: value parameter '[[[1 3]
[4 5]]]' cannot be converted into an array object
compliant with CArray: '/test (CArray(1,)) ''
atom := Int32Atom(shape=(2, 2), dflt=array([[0, 0],
[0, 0]], dtype=int32))
maindim := 0
flavor := 'numpy'
byteorder := 'little'
chunkshape := (4096,)' The error was:
Chuck
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 6:41 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke wrote:
>
>>
>>
>> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>> >
>> >
>> > On 3/3/2011 10:54 PM, Ralf Gommers wrote:
>> >> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
>> >> wrote:
>> >>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
>> >>> wrote:
>> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
>> > Hi,
>> >
>> > On Fri, Jan 28, 2011 at 7:15 AM, Travis
>> > Oliphant wrote:
>> >> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
>> >> would
>> >> seem) have additional work and features that do not need to wait
>> >> for the
>> >> NumPy 2.0 ABI design to finalize in order to get out there.
>> >> If someone is willing to manage the release of NumPy 1.6, then it
>> >> sounds
>> >> like a great idea to me.
>> > This thread ended without a conclusion a month ago. Now I think
>> master
>> > is in a better state than a month ago for a release (py 2.4/2.5/3.x
>> > issues and segfault on OS X fixed, more testing of changes), and I
>> > have a better idea of my free time for March/April. Basically, I
>> have
>> > a good amount of time for the next couple of weeks, and not so much
>> at
>> > the end of March / first half of April due to an inter-continental
>> > move. But I think we can get out a beta by mid-March, and I can
>> manage
>> > the release.
>> >
>> > I've had a look at the bug tracker, here's a list of tickets for
>> 1.6:
>> > #1748 (blocker: regression for astype('str'))
>> > #1619 (issue with dtypes, with patch)
>> > #1749 (distutils, py 3.2)
>> > #1601 (distutils, py 3.2)
>> > #1622 (Solaris segfault, with patch)
>> > #1713 (Solaris segfault)
>> > #1631 (Solaris segfault)
>> >>
>> >> The distutils tickets are resolved.
>> >>
>> > Proposed schedule:
>> > March 15: beta 1
>> > March 28: rc 1
>> > April 17: rc 2 (if needed)
>> > April 24: final release
>> >>
>> >> Any comments on the schedule or tickets?
>> >>
>> >> Before the first beta can be released I think #1748 should be fixed.
>> >> Before the first RC the Solaris segfaults should be investigated, and
>> >> documentation for the new iterator (Python docstrings and C API docs)
>> >> and datetime should be written.
>> >>
>> >> Also, some testing on 64-bit Windows would be great, that usually
>> >> turns up new issues so the sooner the better.
>> >>
>> >> Ralf
>> >
>> > Hi Ralf,
>> >
>> > the numpy master branch on github can not be compiled with Visual
>> > Studio. A patch is attached. I'll test the builds tomorrow.
>> >
>> > Christoph
>> >
>>
>> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
>> There are few test failures (listed below) that look familiar.
>>
>> I also ran tests and/or examples of a few 3rd party packages that were
>> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
>> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
>>
>> Most packages don't have any apparent problems.
>> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
>> failure/error (also listed below).
>>
>> There is a problem with code generated by Cython 0.13: pytables-2.2.1
>> and pandas-0.3.0, which were built with Cython 0.13, report several
>> failures and do crash during the tests. This can probably be fixed by
>> "recythonizing" with Cython 0.14.1.
>>
>>
> I see pytables crash on Fedora 14 64 bit also, even with freshly built
> pytables/numexpr.
>
Backtrace
#0 0x003e9647a52c in __libc_free (mem=0x16cd1f0) at malloc.c:3724
#1 0x7fffefed0988 in array_dealloc (self=0x29617b0)
at numpy/core/src/multiarray/arrayobject.c:266
#2 0x003ea84e8452 in PyEval_EvalFrameEx (f=,
throwflag=)
at /usr/src/debug/Python-2.7/Python/ceval.c:2344
#3 0x003ea84ea71d in fast_function (f=,
throwflag=)
at /usr/src/debug/Python-2.7/Python/ceval.c:4157
#4 call_function (f=, throwflag=)
at /usr/src/debug/Python-2.7/Python/ceval.c:4092
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 4, 2011 at 12:54 PM, Christoph Gohlke wrote:
>
>
> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
> >
> >
> > On 3/3/2011 10:54 PM, Ralf Gommers wrote:
> >> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
> >> wrote:
> >>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
> >>> wrote:
> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
> > Hi,
> >
> > On Fri, Jan 28, 2011 at 7:15 AM, Travis
> > Oliphant wrote:
> >> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
> >> would
> >> seem) have additional work and features that do not need to wait
> >> for the
> >> NumPy 2.0 ABI design to finalize in order to get out there.
> >> If someone is willing to manage the release of NumPy 1.6, then it
> >> sounds
> >> like a great idea to me.
> > This thread ended without a conclusion a month ago. Now I think
> master
> > is in a better state than a month ago for a release (py 2.4/2.5/3.x
> > issues and segfault on OS X fixed, more testing of changes), and I
> > have a better idea of my free time for March/April. Basically, I have
> > a good amount of time for the next couple of weeks, and not so much
> at
> > the end of March / first half of April due to an inter-continental
> > move. But I think we can get out a beta by mid-March, and I can
> manage
> > the release.
> >
> > I've had a look at the bug tracker, here's a list of tickets for 1.6:
> > #1748 (blocker: regression for astype('str'))
> > #1619 (issue with dtypes, with patch)
> > #1749 (distutils, py 3.2)
> > #1601 (distutils, py 3.2)
> > #1622 (Solaris segfault, with patch)
> > #1713 (Solaris segfault)
> > #1631 (Solaris segfault)
> >>
> >> The distutils tickets are resolved.
> >>
> > Proposed schedule:
> > March 15: beta 1
> > March 28: rc 1
> > April 17: rc 2 (if needed)
> > April 24: final release
> >>
> >> Any comments on the schedule or tickets?
> >>
> >> Before the first beta can be released I think #1748 should be fixed.
> >> Before the first RC the Solaris segfaults should be investigated, and
> >> documentation for the new iterator (Python docstrings and C API docs)
> >> and datetime should be written.
> >>
> >> Also, some testing on 64-bit Windows would be great, that usually
> >> turns up new issues so the sooner the better.
> >>
> >> Ralf
> >
> > Hi Ralf,
> >
> > the numpy master branch on github can not be compiled with Visual
> > Studio. A patch is attached. I'll test the builds tomorrow.
> >
> > Christoph
> >
>
> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
> There are few test failures (listed below) that look familiar.
>
> I also ran tests and/or examples of a few 3rd party packages that were
> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
>
> Most packages don't have any apparent problems.
> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
> failure/error (also listed below).
>
> There is a problem with code generated by Cython 0.13: pytables-2.2.1
> and pandas-0.3.0, which were built with Cython 0.13, report several
> failures and do crash during the tests. This can probably be fixed by
> "recythonizing" with Cython 0.14.1.
>
>
I see pytables crash on Fedora 14 64 bit also, even with freshly built
pytables/numexpr.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
Thanks (again) for taking this on Ralf. You are doing a superb job and deserve
much thanks for keeping the NumPy project on track.
I'm very encouraged by the NumPy 1.6 work. I was looking over the code some
more on the plane yesterday that Mark Wiebe has checked in (I finally was able
to create my own fork of NumPy and start hacking on it again). The new ufunc
refactoring is very good and Mark should be congratulated. It puts NumPy in a
good place for further work that can be done for NumPy 2.0.
I do have one question, however. It looks like the code for ufunc casting
behavior was changed almost completely. I have no intrinsic problem with
that, but I am a bit concerned that we may not have tested all the corner cases
very well. The code that was in NumPy was a straightforward alteration of the
algorithm that has been in use since 1995 when Numeric was written. That is
not to say that it is "correct," just that it had a certain behavior. Large
scale code changes typically have alternative "accidental" behavior.
I am just a little nervous that the code changes will mean that more code will
break than we expect. To me, what this means is that we just emphasize the
point in the release notes, and encourage people to test their code as soon as
possible during the month-long beta-testing phase.
All the best,
-Travis
On Mar 4, 2011, at 12:54 AM, Ralf Gommers wrote:
> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
> wrote:
>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey wrote:
>>> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
Hi,
On Fri, Jan 28, 2011 at 7:15 AM, Travis Oliphant
wrote:
> The reason for a NumPy 1.6 suggestion, is that Mark (and others it would
> seem) have additional work and features that do not need to wait for the
> NumPy 2.0 ABI design to finalize in order to get out there.
> If someone is willing to manage the release of NumPy 1.6, then it sounds
> like a great idea to me.
This thread ended without a conclusion a month ago. Now I think master
is in a better state than a month ago for a release (py 2.4/2.5/3.x
issues and segfault on OS X fixed, more testing of changes), and I
have a better idea of my free time for March/April. Basically, I have
a good amount of time for the next couple of weeks, and not so much at
the end of March / first half of April due to an inter-continental
move. But I think we can get out a beta by mid-March, and I can manage
the release.
I've had a look at the bug tracker, here's a list of tickets for 1.6:
#1748 (blocker: regression for astype('str'))
#1619 (issue with dtypes, with patch)
#1749 (distutils, py 3.2)
#1601 (distutils, py 3.2)
#1622 (Solaris segfault, with patch)
#1713 (Solaris segfault)
#1631 (Solaris segfault)
>
> The distutils tickets are resolved.
>
Proposed schedule:
March 15: beta 1
March 28: rc 1
April 17: rc 2 (if needed)
April 24: final release
>
> Any comments on the schedule or tickets?
>
> Before the first beta can be released I think #1748 should be fixed.
> Before the first RC the Solaris segfaults should be investigated, and
> documentation for the new iterator (Python docstrings and C API docs)
> and datetime should be written.
>
> Also, some testing on 64-bit Windows would be great, that usually
> turns up new issues so the sooner the better.
>
> Ralf
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
Enthought, Inc.
oliph...@enthought.com
1-512-536-1057
http://www.enthought.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Fri, Mar 04, 2011 at 11:54:07AM -0800, Christoph Gohlke wrote: > I also ran tests and/or examples of a few 3rd party packages that were > built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib, > basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas. Wow, this is community service. I am impressed. Thanks heaps. Gael ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On 3/4/2011 11:54 AM, Christoph Gohlke wrote:
>
>
> On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>>
>>
>> On 3/3/2011 10:54 PM, Ralf Gommers wrote:
>>> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
>>> wrote:
On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
wrote:
> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
>> Hi,
>>
>> On Fri, Jan 28, 2011 at 7:15 AM, Travis
>> Oliphant wrote:
>>> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
>>> would
>>> seem) have additional work and features that do not need to wait
>>> for the
>>> NumPy 2.0 ABI design to finalize in order to get out there.
>>> If someone is willing to manage the release of NumPy 1.6, then it
>>> sounds
>>> like a great idea to me.
>> This thread ended without a conclusion a month ago. Now I think master
>> is in a better state than a month ago for a release (py 2.4/2.5/3.x
>> issues and segfault on OS X fixed, more testing of changes), and I
>> have a better idea of my free time for March/April. Basically, I have
>> a good amount of time for the next couple of weeks, and not so much at
>> the end of March / first half of April due to an inter-continental
>> move. But I think we can get out a beta by mid-March, and I can manage
>> the release.
>>
>> I've had a look at the bug tracker, here's a list of tickets for 1.6:
>> #1748 (blocker: regression for astype('str'))
>> #1619 (issue with dtypes, with patch)
>> #1749 (distutils, py 3.2)
>> #1601 (distutils, py 3.2)
>> #1622 (Solaris segfault, with patch)
>> #1713 (Solaris segfault)
>> #1631 (Solaris segfault)
>>>
>>> The distutils tickets are resolved.
>>>
>> Proposed schedule:
>> March 15: beta 1
>> March 28: rc 1
>> April 17: rc 2 (if needed)
>> April 24: final release
>>>
>>> Any comments on the schedule or tickets?
>>>
>>> Before the first beta can be released I think #1748 should be fixed.
>>> Before the first RC the Solaris segfaults should be investigated, and
>>> documentation for the new iterator (Python docstrings and C API docs)
>>> and datetime should be written.
>>>
>>> Also, some testing on 64-bit Windows would be great, that usually
>>> turns up new issues so the sooner the better.
>>>
>>> Ralf
>>
>> Hi Ralf,
>>
>> the numpy master branch on github can not be compiled with Visual
>> Studio. A patch is attached. I'll test the builds tomorrow.
>>
>> Christoph
>>
>
> I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
> There are few test failures (listed below) that look familiar.
>
> I also ran tests and/or examples of a few 3rd party packages that were
> built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
> basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
>
> Most packages don't have any apparent problems.
> Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
> failure/error (also listed below).
>
> There is a problem with code generated by Cython 0.13: pytables-2.2.1
> and pandas-0.3.0, which were built with Cython 0.13, report several
> failures and do crash during the tests. This can probably be fixed by
> "recythonizing" with Cython 0.14.1.
Unfortunately recythonizing with Cython 0.14.1 did not help. Both
packages still crash during tests when run against numpy 1.6.dev.
Christoph
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On 3/4/2011 1:00 AM, Christoph Gohlke wrote:
>
>
> On 3/3/2011 10:54 PM, Ralf Gommers wrote:
>> On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
>> wrote:
>>> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey
>>> wrote:
On 02/28/2011 02:00 AM, Ralf Gommers wrote:
> Hi,
>
> On Fri, Jan 28, 2011 at 7:15 AM, Travis
> Oliphant wrote:
>> The reason for a NumPy 1.6 suggestion, is that Mark (and others it
>> would
>> seem) have additional work and features that do not need to wait
>> for the
>> NumPy 2.0 ABI design to finalize in order to get out there.
>> If someone is willing to manage the release of NumPy 1.6, then it
>> sounds
>> like a great idea to me.
> This thread ended without a conclusion a month ago. Now I think master
> is in a better state than a month ago for a release (py 2.4/2.5/3.x
> issues and segfault on OS X fixed, more testing of changes), and I
> have a better idea of my free time for March/April. Basically, I have
> a good amount of time for the next couple of weeks, and not so much at
> the end of March / first half of April due to an inter-continental
> move. But I think we can get out a beta by mid-March, and I can manage
> the release.
>
> I've had a look at the bug tracker, here's a list of tickets for 1.6:
> #1748 (blocker: regression for astype('str'))
> #1619 (issue with dtypes, with patch)
> #1749 (distutils, py 3.2)
> #1601 (distutils, py 3.2)
> #1622 (Solaris segfault, with patch)
> #1713 (Solaris segfault)
> #1631 (Solaris segfault)
>>
>> The distutils tickets are resolved.
>>
> Proposed schedule:
> March 15: beta 1
> March 28: rc 1
> April 17: rc 2 (if needed)
> April 24: final release
>>
>> Any comments on the schedule or tickets?
>>
>> Before the first beta can be released I think #1748 should be fixed.
>> Before the first RC the Solaris segfaults should be investigated, and
>> documentation for the new iterator (Python docstrings and C API docs)
>> and datetime should be written.
>>
>> Also, some testing on 64-bit Windows would be great, that usually
>> turns up new issues so the sooner the better.
>>
>> Ralf
>
> Hi Ralf,
>
> the numpy master branch on github can not be compiled with Visual
> Studio. A patch is attached. I'll test the builds tomorrow.
>
> Christoph
>
I tested the 32 and 64 bit msvc9/MKL builds for Python 2.7 and 3.2.
There are few test failures (listed below) that look familiar.
I also ran tests and/or examples of a few 3rd party packages that were
built against numpy 1.5.1: scipy, pygame, PyMOL, numexpr, matplotlib,
basemap, scikits.learn, ETS.mayavi, Bottleneck, pytables, and pandas.
Most packages don't have any apparent problems.
Scipy-0.9.0-win-amd64-py3.2 and Bottleneck-0.3.0 each have one test
failure/error (also listed below).
There is a problem with code generated by Cython 0.13: pytables-2.2.1
and pandas-0.3.0, which were built with Cython 0.13, report several
failures and do crash during the tests. This can probably be fixed by
"recythonizing" with Cython 0.14.1.
Christoph
numpy-1.6.1.dev-win-amd64-py2.7
==
ERROR: Ticket #99
--
Traceback (most recent call last):
File "X:\Python27-x64\lib\site-packages\numpy\testing\decorators.py",
line 215, in knownfailer
return f(*args, **kwargs)
File
"X:\Python27-x64\lib\site-packages\numpy\core\tests\test_regression.py",
line 147, in test_intp
np.intp('0x' + 'f'*i_width,16)
TypeError: function takes at most 1 argument (2 given)
==
FAIL: test_special_values (test_umath_complex.TestClog)
--
Traceback (most recent call last):
File "X:\Python27-x64\lib\site-packages\numpy\testing\decorators.py",
line 146, in skipper_func
return f(*args, **kwargs)
File
"X:\Python27-x64\lib\site-packages\numpy\core\tests\test_umath_complex.py",
line 248, in test_special_values
assert_almost_equal(np.log(x), y)
File "X:\Python27-x64\lib\site-packages\numpy\testing\utils.py", line
443, in assert_almost_equal
raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 7 decimals
ACTUAL: array([ nan+2.35619449j])
DESIRED: (inf+2.356194490192345j)
numpy-1.6.1.dev-win-amd64-py3.2
==
FAIL: test_special_values (test_umath_complex.TestClog)
--
Traceback (most recent call last):
File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
588, in assert_array_compare
assert_array_equal(xnanid, ynanid)
File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line
687, in assert_array_equal
verbos
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On 3/3/2011 10:54 PM, Ralf Gommers wrote:
On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
wrote:
On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey wrote:
On 02/28/2011 02:00 AM, Ralf Gommers wrote:
Hi,
On Fri, Jan 28, 2011 at 7:15 AM, Travis Oliphant
wrote:
The reason for a NumPy 1.6 suggestion, is that Mark (and others it would
seem) have additional work and features that do not need to wait for the
NumPy 2.0 ABI design to finalize in order to get out there.
If someone is willing to manage the release of NumPy 1.6, then it sounds
like a great idea to me.
This thread ended without a conclusion a month ago. Now I think master
is in a better state than a month ago for a release (py 2.4/2.5/3.x
issues and segfault on OS X fixed, more testing of changes), and I
have a better idea of my free time for March/April. Basically, I have
a good amount of time for the next couple of weeks, and not so much at
the end of March / first half of April due to an inter-continental
move. But I think we can get out a beta by mid-March, and I can manage
the release.
I've had a look at the bug tracker, here's a list of tickets for 1.6:
#1748 (blocker: regression for astype('str'))
#1619 (issue with dtypes, with patch)
#1749 (distutils, py 3.2)
#1601 (distutils, py 3.2)
#1622 (Solaris segfault, with patch)
#1713 (Solaris segfault)
#1631 (Solaris segfault)
The distutils tickets are resolved.
Proposed schedule:
March 15: beta 1
March 28: rc 1
April 17: rc 2 (if needed)
April 24: final release
Any comments on the schedule or tickets?
Before the first beta can be released I think #1748 should be fixed.
Before the first RC the Solaris segfaults should be investigated, and
documentation for the new iterator (Python docstrings and C API docs)
and datetime should be written.
Also, some testing on 64-bit Windows would be great, that usually
turns up new issues so the sooner the better.
Ralf
Hi Ralf,
the numpy master branch on github can not be compiled with Visual
Studio. A patch is attached. I'll test the builds tomorrow.
Christoph
diff --git a/numpy/core/src/multiarray/arraytypes.c.src
b/numpy/core/src/multiarray/arraytypes.c.src
index a5e4713..1b2f657 100644
--- a/numpy/core/src/multiarray/arraytypes.c.src
+++ b/numpy/core/src/multiarray/arraytypes.c.src
@@ -1596,6 +1596,7 @@ static void
}
/* convert from Python object to needed one */
#if @convert@
+{
PyObject *new, *args;
/* call out to the Python builtin given by convstr */
args = Py_BuildValue("(N)", temp);
@@ -1611,6 +1612,7 @@ static void
if (temp == NULL) {
return;
}
+}
#endif /* @convert@ */
if (@to@_setitem(temp,(char *)op, aop)) {
Py_DECREF(temp);
diff --git a/numpy/core/src/multiarray/ctors.c
b/numpy/core/src/multiarray/ctors.c
index 4fb6bc7..36e1cb4 100644
--- a/numpy/core/src/multiarray/ctors.c
+++ b/numpy/core/src/multiarray/ctors.c
@@ -2395,7 +2395,6 @@ PyArray_CopyAnyIntoOrdered(PyArrayObject *dst,
PyArrayObject *src,
PyArray_StridedTransferFn *stransfer = NULL;
void *transferdata = NULL;
NpyIter *dst_iter, *src_iter;
-NPY_BEGIN_THREADS_DEF;
NpyIter_IterNext_Fn dst_iternext, src_iternext;
char **dst_dataptr, **src_dataptr;
@@ -2408,6 +2407,8 @@ PyArray_CopyAnyIntoOrdered(PyArrayObject *dst,
PyArrayObject *src,
npy_intp dst_size, src_size;
int needs_api;
+NPY_BEGIN_THREADS_DEF;
+
if (!PyArray_ISWRITEABLE(dst)) {
PyErr_SetString(PyExc_RuntimeError,
"cannot write to array");
diff --git a/numpy/core/src/multiarray/einsum.c.src
b/numpy/core/src/multiarray/einsum.c.src
index 9200c7c..5233ea5 100644
--- a/numpy/core/src/multiarray/einsum.c.src
+++ b/numpy/core/src/multiarray/einsum.c.src
@@ -50,7 +50,7 @@
#if NPY_EINSUM_DBG_TRACING
#define NPY_EINSUM_DBG_PRINTF(...) printf(__VA_ARGS__)
#else
-#define NPY_EINSUM_DBG_PRINTF(...)
+#define NPY_EINSUM_DBG_PRINTF
#endif
/**/
diff --git a/numpy/core/src/multiarray/item_selection.c
b/numpy/core/src/multiarray/item_selection.c
index db379e5..022f3d9 100644
--- a/numpy/core/src/multiarray/item_selection.c
+++ b/numpy/core/src/multiarray/item_selection.c
@@ -1880,8 +1880,8 @@ finish:
}
else {
for (i = 0; i < ndim; ++i) {
-stride = ndim*NPY_SIZEOF_INTP;
PyArrayObject *view;
+stride = ndim*NPY_SIZEOF_INTP;
view = (PyArrayObject *)PyArray_New(Py_TYPE(self), 1,
&nonzero_count,
diff --git a/numpy/core/src/multiarray/new_iterator.c.src
b/numpy/core/src/multiarray/new_iterator.c.src
index 1208e5d..3d8566f 100644
--- a/numpy/core/src/multiarray/new_iterator.c.src
+++ b/numpy/core/src/multiarray/new_iterator.c.src
@@ -50,7 +50,7 @@
#if NPY_IT_DBG_TRACING
#define NPY_IT_DBG_PRINTF(...) printf(__VA_ARGS__)
#else
-#define NPY_IT_DBG_PRINTF(...)
+#define NPY_IT_DBG_PRI
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers
wrote:
> On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey wrote:
>> On 02/28/2011 02:00 AM, Ralf Gommers wrote:
>>> Hi,
>>>
>>> On Fri, Jan 28, 2011 at 7:15 AM, Travis Oliphant
>>> wrote:
The reason for a NumPy 1.6 suggestion, is that Mark (and others it would
seem) have additional work and features that do not need to wait for the
NumPy 2.0 ABI design to finalize in order to get out there.
If someone is willing to manage the release of NumPy 1.6, then it sounds
like a great idea to me.
>>> This thread ended without a conclusion a month ago. Now I think master
>>> is in a better state than a month ago for a release (py 2.4/2.5/3.x
>>> issues and segfault on OS X fixed, more testing of changes), and I
>>> have a better idea of my free time for March/April. Basically, I have
>>> a good amount of time for the next couple of weeks, and not so much at
>>> the end of March / first half of April due to an inter-continental
>>> move. But I think we can get out a beta by mid-March, and I can manage
>>> the release.
>>>
>>> I've had a look at the bug tracker, here's a list of tickets for 1.6:
>>> #1748 (blocker: regression for astype('str'))
>>> #1619 (issue with dtypes, with patch)
>>> #1749 (distutils, py 3.2)
>>> #1601 (distutils, py 3.2)
>>> #1622 (Solaris segfault, with patch)
>>> #1713 (Solaris segfault)
>>> #1631 (Solaris segfault)
The distutils tickets are resolved.
>>> Proposed schedule:
>>> March 15: beta 1
>>> March 28: rc 1
>>> April 17: rc 2 (if needed)
>>> April 24: final release
Any comments on the schedule or tickets?
Before the first beta can be released I think #1748 should be fixed.
Before the first RC the Solaris segfaults should be investigated, and
documentation for the new iterator (Python docstrings and C API docs)
and datetime should be written.
Also, some testing on 64-bit Windows would be great, that usually
turns up new issues so the sooner the better.
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.6 schedule (was: Numpy 2.0 schedule)
On Mon, Feb 28, 2011 at 11:31 PM, Ralf Gommers wrote: > On Mon, Feb 28, 2011 at 10:36 PM, Bruce Southey wrote: >> It would be great to do some 'housekeeping' and try to address some of >> the old tickets dealt with before numpy 2.0. For example, I think ticket >> 225 (bincount does not accept input of type > N.uint16) has been >> addressed but it needs to be checked from windows and 32-bit systems. I checked #225, that's still not working. But yes, quite a few of the below tickets can be closed, some that are not applicable anymore, enhancement requests that obviously won't be implemented, numeric/numarray related ones (do we still actively support those modules?). Ralf >> Created 2006: >> #38 strides accepted as an argument to records.array >> #57 ufunc methods need improved BUFFER loop >> #213 SharedLibrary builder for numpy.distutils >> #225 bincount does not accept input of type > N.uint16 >> #236 reduceat cornercase >> #237 reduceat should handle outlier indices gracefully >> #244 Build fails with Intel Visual Fortran compiler >> #260 Add mechanism for registering objects to be deallocated and >> memory-to-be freed at Python exit >> #274 Speed up N-D Boolean indexing >> #301 power with negative argument returns 0 >> #333 Creating an array from a n-dim dtype type fails >> #338 Valgrind warning when calling scipy.interpolate.interp1d >> #349 Improve unit tests in linalg >> #354 Possible inconsistency in 0-dim and scalar empty array types >> #398 Compatibility loader for old Numeric pickles >> #400 C API access to fft for C scipy extension ? >> #402 newaxis incompatible with array indexing >> >> >> Numpy 1.0 >> #450 Make a.min() not copy data >> #417 Numpy 1.0.1 compilation fails on IRIX 6.5 >> #527 fortran linking flag option... >> #1176 deepcopy turns ndarry into string_ >> #1143 Improve performance of PyUFunc_Reduce >> #931 Records containing zero-length items pickle just fine, but >> cannot be unpickled >> #803 Assignment problem on matrix advanced selection >> >> Numpy 1.1 >> #1266 Extremely long runtimes in numpy.fft.fft >> #963 Object array comparisons eat exceptions >> #929 empty_like and zeros_like behave differently from ones_like >> #934 Documentation error in site.cfg.example >> >> Numpy 1.2 >> #1374 Ticket 628 not fixed for Solaris (polyfit uses 100% CPU and >> does not stop) >> #1209 Docstring for numpy.numarray.random_array.multinomial is out of >> date. >> #1192 integer dot product >> #1172 abs does not work with -maxint >> #1163 Incorrect conversion to Int64 by loadtxt (traced to _getconv in >> numpy.lib.io) >> #1161 Errors and/or wrong result with reverse slicing in numpy.delete >> #1094 masked array autotest fails with bus error >> #1085 Surprising results from in-place operations involving views >> #1071 loadtxt fails if the last column contains empty value >> >> >> >> ___ >> 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
