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,

...

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

On Fri, Jan 28, 2011 at 7:15 AM, Travis Oliphant wrote: 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 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) numpy-1.6.1.dev-win32-py2.7 numpy-1.6.1.dev-win32-py3.2 ====================================================================== FAIL: Test basic arithmetic function errors ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python27\lib\site-packages\numpy\core\tests\test_numeric.py", line 320, in test_floating_exceptions np.power, ftype(2), ftype(2**fi.nexp)) File "X:\Python27\lib\site-packages\numpy\core\tests\test_numeric.py", line 261, in assert_raises_fpe "Type %s did not raise fpe error '%s'." % (ftype, fpeerr)) File "X:\Python27\lib\site-packages\numpy\testing\utils.py", line 34, in assert_ raise AssertionError(msg) AssertionError: Type did not raise fpe error 'overflow'. ====================================================================== FAIL: test_special_values (test_umath_complex.TestClog) ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python27\lib\site-packages\numpy\testing\decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "X:\Python27\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 168, in test_special_values self.assertRaises(FloatingPointError, np.log, x) AssertionError: FloatingPointError not raised scipy-0.9.0-win-amd64-py3.2 ====================================================================== FAIL: minimum position 7 ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python32\lib\site-packages\nose\case.py", line 188, in runTest self.test(*self.arg) File "X:\Python32\lib\site-packages\scipy\ndimage\tests\test_measurements.py", line 701, in test_minimum_position07 assert_equal(output[0], (0, 1)) File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line 251, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line 300, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: nan DESIRED: 0 Bottleneck-0.3.0.win32-py2.7 Bottleneck-0.3.0.win-amd64-py2.7 ====================================================================== ERROR: Test group_nanmean. ---------------------------------------------------------------------- Traceback (most recent call last): File "X:\Python27-x64\lib\site-packages\nose\case.py", line 187, in runTest self.test(*self.arg) File "D:\Bottleneck-0.3.0\bottleneck\tests\group_test.py", line 63, in unit_maker a1, lab1 = func(arr, label, axis=axis) File "group_nanmean.pyx", line 74, in group.group_nanmean (bottleneck/src/group/group.c:2873) File "group_nanmean.pyx", line 179, in group.group_nanmean_selector (bottleneck/src/group/group.c:3464) TypeError: Unsupported ndim/dtype (1/int32).

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

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 0x0000003e9647a52c in __libc_free (mem=0x16cd1f0) at malloc.c:3724 #1 0x00007fffefed0988 in array_dealloc (self=0x29617b0) at numpy/core/src/multiarray/arrayobject.c:266 #2 0x0000003ea84e8452 in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:2344 #3 0x0000003ea84ea71d in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:4157 #4 call_function (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:4092 Chuck

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.harris@gmail.com> wrote:

...

On Fri, Mar 4, 2011 at 6:41 PM, Charles R Harris < charlesr.harris@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 0x0000003e9647a52c in __libc_free (mem=0x16cd1f0) at malloc.c:3724 #1 0x00007fffefed0988 in array_dealloc (self=0x29617b0) at numpy/core/src/multiarray/arrayobject.c:266 #2 0x0000003ea84e8452 in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:2344 #3 0x0000003ea84ea71d in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:4157 #4 call_function (f=<value optimized out>, throwflag=<value optimized 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

...

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. FWIW, Ben Root

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 :040000 040000 a23fbcff385fca9704a5313e81217a6d80e3512c 09b684bd8893e44405534fedad165ce85e751019 M numpy If we agree that this is still a bug and not a feature, I will file a report. Ben Root

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

:040000 040000 a23fbcff385fca9704a5313e81217a6d80e3512c 09b684bd8893e44405534fedad165ce85e751019 M numpy

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

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

:040000 040000 a23fbcff385fca9704a5313e81217a6d80e3512c 09b684bd8893e44405534fedad165ce85e751019 M numpy

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

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

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

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

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

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.

numpy-1.6.1.dev-win32-py2.7 numpy-1.6.1.dev-win32-py3.2

====================================================================== FAIL: Test basic arithmetic function errors ---------------------------------------------------------------------- Traceback (most recent call last):   File "X:\Python27\lib\site-packages\numpy\core\tests\test_numeric.py", line 320, in test_floating_exceptions     np.power, ftype(2), ftype(2**fi.nexp))   File "X:\Python27\lib\site-packages\numpy\core\tests\test_numeric.py", line 261, in assert_raises_fpe     "Type %s did not raise fpe error '%s'." % (ftype, fpeerr))   File "X:\Python27\lib\site-packages\numpy\testing\utils.py", line 34, in assert_     raise AssertionError(msg) AssertionError: Type did not raise fpe error 'overflow'.

I had already opened #1755 for that. Would be good to have it fixed, but not very urgent I'd say.

====================================================================== FAIL: test_special_values (test_umath_complex.TestClog) ---------------------------------------------------------------------- Traceback (most recent call last):   File "X:\Python27\lib\site-packages\numpy\testing\decorators.py", line 146, in skipper_func     return f(*args, **kwargs)   File "X:\Python27\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 168, in test_special_values     self.assertRaises(FloatingPointError, np.log, x) AssertionError: FloatingPointError not raised

scipy-0.9.0-win-amd64-py3.2

====================================================================== FAIL: minimum position 7 ---------------------------------------------------------------------- Traceback (most recent call last):   File "X:\Python32\lib\site-packages\nose\case.py", line 188, in runTest     self.test(*self.arg)   File "X:\Python32\lib\site-packages\scipy\ndimage\tests\test_measurements.py",  line 701, in test_minimum_position07     assert_equal(output[0], (0, 1))   File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line 251, in assert_equal     assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose)   File "X:\Python32\lib\site-packages\numpy\testing\utils.py", line 300, in assert_equal     raise AssertionError(msg) AssertionError: Items are not equal: item=0

 ACTUAL: nan  DESIRED: 0

That one is new, but since we didn't test scipy 0.9.0 extensively on py-3.2 it's not that surprising to get one failure. Ralf

Bottleneck-0.3.0.win32-py2.7 Bottleneck-0.3.0.win-amd64-py2.7

====================================================================== ERROR: Test group_nanmean. ---------------------------------------------------------------------- Traceback (most recent call last):   File "X:\Python27-x64\lib\site-packages\nose\case.py", line 187, in runTest     self.test(*self.arg)   File "D:\Bottleneck-0.3.0\bottleneck\tests\group_test.py", line 63, in unit_maker     a1, lab1 = func(arr, label, axis=axis)   File "group_nanmean.pyx", line 74, in group.group_nanmean (bottleneck/src/group/group.c:2873)   File "group_nanmean.pyx", line 179, in group.group_nanmean_selector (bottleneck/src/group/group.c:3464) TypeError: Unsupported ndim/dtype (1/int32).

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

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

On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers wrote:

<snip>

...

...

...

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

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:

...

<snip>

...

...

...

...

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. Of course, testing this thoroughly is necessary, and the work being done by Ralf, Christoph, and others is fantastic. 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.

All the existing parameters are still there, and I added tests for the 'sig' parameter. It might be worthwhile for someone who has used these features to write examples for the documentation, as they're a bit tricky to understand from the descriptions. I also added an 'out' keyword parameter to make ufuncs more consistent with other functions' output parameters.

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.

Thanks! Mark

On 3/6/11 5:54 AM, Charles R Harris wrote:

I suppose this might cause a problem with lazy/quick c extensions that expected elements in a certain order, so some breakage could occur.

absolutely! (I've gotten a bit confused about this thread, but if this is about the question of whether structured dtypes are dtypes are assumed to always keep order, read on -- otherwise, ignore).. I have always assumed a structured dtype was much like a C struct: i.e. arrangement in memory is fixed, and the named fields are just for convenience. I was very surprised to learn that they could ever be used in more a a dict-like manner. Also, I noted a recent post to this list suggesting that folks sometime miss-use stuctured arrays (particularly folks coming from MATLAB, etc), by using them when what they really want is a dict. In that post, the poster suggested that the primary use of structured arrays was for interacting with data files and C code that has arrays of structures, and indeed, that is how I have primarily used them. So I think for performance and consistency with C code, keeping dtype order is the best way to go. If that breaks backward compatibility too much, then it shouldn't be changed, but I think it better reflects what dtypes are all about. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

Mon, 07 Mar 2011 11:23:33 -0600, Robert Kern wrote: [clip]

Can someone explain exactly what changed? Or point to the changeset that made it? It's not clear to me what operations are different under Mark's changes.

Mark mentioned three points here: http://permalink.gmane.org/gmane.comp.python.numeric.general/42753 Below, first two. 1) Structured array copying copies by field name. Commit 22d96096bf7d5fb199ca80f2fcd04e8d27815476 Before:

...

...

x = np.array([(0, 1)], dtype=[('a', int), ('b', int)]) y = np.array([(2, 3)], dtype=[('a', int), ('b', int)]) y = np.array([(2, 3)], dtype=[('b', int), ('a', int)]) x[:] = y x array([(2, 3)], dtype=[('a', '

After:

...

...

x = np.array([(0, 1)], dtype=[('a', int), ('b', int)]) y = np.array([(2, 3)], dtype=[('b', int), ('a', int)]) x[:] = y x array([(3, 2)], dtype=[('a', '

This seems like a pretty hazardous change. Granted, it's in a bit of a grey area, but people may rely on this. 2) Ufuncs don't necessarily return arrays in C-order, but instead try to keep the memory layout of the original if it seems advantageous vs. memory access. Before:

...

...

np.sin(np.zeros((5,5,5)).transpose(1,2,0)).strides (200, 40, 8)

After:

...

...

np.sin(np.zeros((5,5,5)).transpose(1,2,0)).strides (40, 8, 200)

This gets +1 from me; the drawbacks to this are mostly in code that makes too much assumptions and makes no checks. -- Pauli Virtanen

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

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

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