Mailman 3 June 2010 - NumPy-Discussion

BUG: NumPy exposes the wrong include directory
by Stéfan van der Walt 26 Aug '10

26 Aug '10

Hi all, Under Ubuntu, the NumPy headers are dumped under /usr/include/python2.6. This is not the location that should be exposed when another copy of NumPy is installed. The attached patch lets from numpy.distutils.system_info import get_info print get_info['numpy'] return the correct path. However, it's a quick hack, and I'd like someone familiar with numpy.distutils to have a look and suggest a proper fix. Regards Stéfan

3 4

Compiling NumPy on 64 bit Solaris 10 sparc)
by Chris LeBlanc 30 Jul '10

30 Jul '10

Hi, Firstly thanks to everyone that has helped bring NumPy to the point it is today. Its an excellent bit of software. I've recently managed to get NumPy to compile on a 64 bit Solaris 10 (sparc) machine. We've embedded 64 bit Python in some of our C code using the Python C-API, and therefore require a 64 bit version of NumPy. I had to use a bit of a hack to get NumPy to compile in 64 bit mode, and I'm just wondering if there's a more elegant way of doing it? If I set CFLAGS to "-m64 -xcode=pic32", and CC to "/usr/bin/cc", it will raise the following error: ... snipped most of backtrace ... File "/home/leblanc/source/numpy/numpy/distutils/command/build_src.py", line 385, in generate_sources source = func(extension, build_dir) File "numpy/core/setup.py", line 675, in get_mathlib_info raise RuntimeError("Broken toolchain: cannot link a simple C program") However, if I create a wrapper script and set CC to the path of the wrapper, then it will build normally and create a NumPy module I can use from the 64 bit version of Python installed on the system (/usr/bin/sparcv9/python). Here's the wrapper: #!/bin/sh /usr/bin/cc -m64 -xcode=pic32 $* I did a bit of googling and couldn't find much information on this issue (which is why I wanted to post this message, so others could find it). I'm satisfied with the results, but wondering if there's a better way to do it. Cheers, Chris Chris LeBlanc GNS Science

3 4

loadtxt() behavior on single-line files
by Benjamin Root 27 Jul '10

27 Jul '10

Hi, I was having the hardest time trying to figure out an intermittent bug in one of my programs. Essentially, in some situations, it was throwing an error saying that the array object was not an array. It took me a while, but then I figured out that my program was assuming that the object returned from a loadtxt() call was always a structured array (I was using dtypes). However, if the data file being loaded only had one data record, then all you get back is a structured record. import numpy as np from StringIO import StringIO strData = StringIO("89.23 47.2\n13.2 42.2") a = np.loadtxt(strData, dtype=[('x', float), ('y', float)]) print "Length Two" print a print a.shape print len(a) strData = StringIO("53.2 49.2") a = np.loadtxt(strData, dtype=[('x', float), ('y', float)]) print "\n\nLength One" print a print a.shape try : print len(a) except TypeError as err print "ERROR:", err Which gets me this output: Length Two [(89.230000000000004, 47.200000000000003) (13.199999999999999, 42.200000000000003)] (2,) 2 Length One (53.200000000000003, 49.200000000000003) () ERROR: len() of unsized object Note that this isn't restricted to structured arrays. For regular ndarrays, loadtxt() appears to mimic the behavior of np.squeeze(): >>> a = np.ones((1, 1, 1)) >>> np.squeeze(a)[0] IndexError: 0-d arrays can't be indexed >>> strData = StringIO("53.2") >>> a = np.loadtxt(strData) >>> a[0] IndexError: 0-d arrays can't be indexed So, if you have multiple lines with multiple columns, you get a 2-D array, as expected. if you have a single line of data with multiple columns, you get a 1-D array. If you have a single column with many lines, you also get a 1-D array (which is probably expected, I guess). If you have a single column with a single line, you get a scalar (actually, a 0-D array). Is this a bug or a feature? I can see the advantages of having loadtxt() returning the lowest # of dimensions that can hold the given data, but it leaves the code vulnerable to certain edge cases. Maybe there is a different way I should be doing this, but I feel that this behavior at the very least should be included in the loadtxt documentation. Ben Root

3 4

__array__struct__: about using PyCapsule instead of PyCObject for Python 2.7
by Lisandro Dalcin 17 Jul '10

17 Jul '10

Do we really need this for NumPy 2? What about using the old PyCObject for all Py 2.x versions? If this is not done, perhaps NumPy 2 on top of Py 2.x should still accept the __array_struct__ being a PyCObject? As reference, Cython still uses PyCObject for Py<3.1 http://hg.cython.org/cython-devel/rev/8a58f1544bd8#l1.33 . -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

5 9

_wrapit bug?
by Benjamin Root 17 Jul '10

17 Jul '10

Hi, I was just digging through the fromnumeric.py code when I noticed that the function _wrapit used asarray() rather than asanyarray(). I don't know if this function really gets used anymore (as it gets called in special situations), but would seem to be an issue as it would cause arrays such as masked_array to lose its type. For example, if _wrapit was called for a max() function on a masked array, the max returned would be for the ndarray's max, not the masked_array's max. Let me know if this is a non-issue, I just thought I ought to point it out. Thanks, Ben Root

2 1

Numpy 1.5 for Python 2.7 and 3.1
by Christoph Gohlke 03 Jul '10

03 Jul '10

Dear NumPy developers, at <http://projects.scipy.org/numpy/ticket/1520> I have posted a patch against numpy svn trunk r8464 that: 1) removes the datetime functionality 2) restores ABI compatibility with numpy 1.4.1 3) enables numpy to build and run on Python 2.7 and 3.1 (at least on Windows) I hope this work can be used to get a numpy 1.5.x branch started. Regarding Python 2.7, which is scheduled to be released within 2 weeks: numpy 1.4.1 does build and work with minor changes (http://projects.scipy.org/numpy/changeset/7926 and followups). However, for Python 2.7, the proposed patch will not be binary compatible with numpy 1.4.1 because it uses PyCapsule instead of PyCObject. Best, Christoph

3 2

? FAIL: test_print.test_complex_types(<type 'numpy.complex64'>, )
by Vincent Davis 03 Jul '10

03 Jul '10

I didn't find these documented anywhere, I have numpy(couple day old snapshot) install on python 2.7 OSX 64bit. Thanks Vincent ====================================================================== FAIL: test_print.test_complex_types(<type 'numpy.complex64'>,) Check formatting of complex types. ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_print.py", line 61, in check_complex_type err_msg='Failed str formatting for type %s' % tp) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 313, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: Failed str formatting for type <type 'numpy.complex64'> ACTUAL: '-1j' DESIRED: '(-0-1j)' >> raise AssertionError("\nItems are not equal: Failed str formatting for type <type 'numpy.complex64'>\n ACTUAL: '-1j'\n DESIRED: '(-0-1j)'") ====================================================================== FAIL: test_print.test_complex_types(<type 'numpy.complex128'>,) Check formatting of complex types. ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_print.py", line 61, in check_complex_type err_msg='Failed str formatting for type %s' % tp) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 313, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: Failed str formatting for type <type 'numpy.complex128'> ACTUAL: '-1j' DESIRED: '(-0-1j)' >> raise AssertionError("\nItems are not equal: Failed str formatting for type <type 'numpy.complex128'>\n ACTUAL: '-1j'\n DESIRED: '(-0-1j)'") ====================================================================== FAIL: test_print.test_complex_types(<type 'numpy.complex256'>,) Check formatting of complex types. ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_print.py", line 61, in check_complex_type err_msg='Failed str formatting for type %s' % tp) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 313, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: Failed str formatting for type <type 'numpy.complex256'> ACTUAL: '-1j' DESIRED: '(-0-1j)' >> raise AssertionError("\nItems are not equal: Failed str formatting for type <type 'numpy.complex256'>\n ACTUAL: '-1j'\n DESIRED: '(-0-1j)'") ---------------------------------------------------------------------- Ran 2466 tests in 11.029s FAILED (KNOWNFAIL=4, SKIP=1, failures=3) <nose.result.TextTestResult run=2466 errors=0 failures=3>

2 2

numpy.all docstring reality check
by David Goldsmith 02 Jul '10

02 Jul '10

Hi, folks. Under Parameters, the docstring for numpy.core.fromnumeric.all says: "out : ndarray, optionalAlternative output array in which to place the result. It must have the same shape as the expected output and *the type is preserved*." [emphasis added].I assume this is a copy-and-paste-from-another-docstring "typo" (shouldn't it be (possibly ndarray of) bool), but I just wanted to double check. DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)

3 3

Ticket #1223...
by David Goldsmith 01 Jul '10

01 Jul '10

...concerns the behavior of numpy.random.multivariate_normal; if that's of interest to you, I urge you to take a look at the comments (esp. mine :-) ); otherwise, please ignore the noise. Thanks! DG

4 7

NumPy re-factoring project
by Jason McCampbell 01 Jul '10

01 Jul '10

Hi everyone, This is a follow-up to Travis's message on the re-factoring project from May 25th and the subsequent discussion. For background, I am a developer at Enthought working on the NumPy re-factoring project with Travis and Scott. The immediate goal from our perspective is to re-factor the core of NumPy into two architectural layers: a true core that is CPython-independent and an interface layer that binds the core to CPython. A design proposal is now posted on the NumPy developer wiki: http://projects.scipy.org/numpy/wiki/NumPyRefactoring The write-up is a fairly high-level description of what we think the split will look like and how to deal with issues such as memory management. There are also placeholders listed as 'TBD' where more investigation is still needed and will be filled in over time. At the end of the page there is a section on the C API with a link to a function-by-function breakdown of the C API and whether the function belongs in the interface layer, the core, or need to be split between the two. All functions listed as 'core' will continue to have an interface-level wrapper with the same name to ensure source-compatibility. All of this, particularly the interface/core function designations, is a first analysis and in flux. The goal is to get the information out and elicit discussion and feedback from the community. Best regards, Jason Jason McCampbell Enthought, Inc.

15 61