Mailman 3 February 2012 - NumPy-Discussion

combination of list of indices and newaxis not allowed?
by Mark Bakker Feb. 2, 2012

Feb. 2, 2012

Hello list, I am trying to specify the indices of an array with a list and add a newaxis, but that combination doesn't seem to be allowed. Any reason why? Here's an example: a = arange(3) This works: a[[0,2]][:,newaxis] Out[445]: array([[0], [2]]) This is more elegant syntax (and, I thought, correct), but it doesn't work: a[[0,2],newaxis] --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /Users/mark/ttim/svn/trunk/<ipython-input-444-b37a4cca4311> in <module>() ----> 1 a[[0,2],newaxis] TypeError: long() argument must be a string or a number, not 'NoneType'

3 2

Help with f2py in MacPorts environment
by Aronne Merrelli Feb. 1, 2012

Feb. 1, 2012

Hello, I'm trying to do a simple test with f2py, using the Hermite polynomial example here: http://www.scipy.org/Cookbook/F2Py I cannot figure out how to configure the compile/build commands to work with my system. I'm a novice at this stuff, so please bear with me... I'm running on Mac OS X, and since the Xcode compiler does not include fortran, I have the version 4.4 of gcc installed from MacPorts. So my compilers should be /opt/local/bin/gcc-mp-4.4 and gfortran-mp-4.4, and the associated lib/include directories are also under /opt. I've used this to compile other fortran programs so I am confident it is installed correctly. Now, I downloaded that hermite polynomial code, and the first command (f2py -m hermite -h hermite.pyf hermite.f) runs fine. I'm stuck on the second command that is supposed to compile the code and create the .so file. The keyword arguments to f2py (-f90exec, -compiler) don't seem to help but it appears to read shell variables, so the farthest I could get was to do the following: CC=/opt/local/bin/gcc-mp-4.4 F90=/opt/local/bin/gfortran-mp-4.4 f2py --verbose -c hermite.pyf hermite.f In verbose mode it prints out the contents of the distutils objects, and it looks like it is getting the correct compiler paths, but things are still garbled because certain things appear to still reference the Xcode compiler - here is a piece of the distutils content printed by f2py: ******************************************************************************** distutils.unixccompiler.UnixCCompiler linker_exe = ['/opt/local/bin/gcc-mp-4.4'] compiler_so = ['/opt/local/bin/gcc-mp-4.4', '-fno-strict-aliasing', '-fno-common', '-dynamic', '-arch', 'i386', '-isysroot', '/Developer/SDKs/MacOSX10.5.sdk', '-DNDEBUG', '-g', '-O3', '-arch', 'i386', '-isysroot', '/Developer/SDKs/MacOSX10.5.sdk'] So it has the correct path to the MacPorts gcc but then the flags are not correct since those refer to Xcode; it causes a stop error because gcc-mp-4.4 has no -arch flag. My guess is that I have to figure out how to change those flags - which probably means modifying the distutils calls somehow. Has anyone dealt this issue before, and maybe has some pointers on where to look? It is not clear to me how any of the f2py command line flags will modify these things, and I don't see how to setup my own 'UnixCCompiler' object that has the correct flags. Thanks, Aronne

1 0

I must be wrong? -- endian detection failure on Mac OSX 10.5
by Dustin Lang Feb. 1, 2012

Feb. 1, 2012

Hi, I don't really believe this is a numpy bug that hasn't been detected, so it must be something weird about my setup, but I can't figure it out. Here goes. The symptom is that while numpy-1.4.1 builds fine, numpy-1.5.0 and later releases fail with: In file included from numpy/core/src/npymath/npy_math.c.src:56: numpy/core/src/npymath/npy_math_private.h:78: error: conflicting types for ieee_double_shape_type numpy/core/src/npymath/npy_math_private.h:64: note: previous declaration of ieee_double_shape_type was here error: Command "gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Inumpy/core/include -Ibuild/src.macosx-10.5-i386-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/local/python-2.7.2/include/python2.7 -Ibuild/src.macosx-10.5-i386-2.7/numpy/core/src/multiarray -Ibuild/src.macosx-10.5-i386-2.7/numpy/core/src/umath -c build/src.macosx-10.5-i386-2.7/numpy/core/src/npymath/npy_math.c -o build/temp.macosx-10.5-i386-2.7/build/src.macosx-10.5-i386-2.7/numpy/core/src/npymath/npy_math.o" failed with exit status 1 The relevant code looks like, #define IEEE_WORD_ORDER NPY_BYTE_ORDER #if IEEE_WORD_ORDER == NPY_BIG_ENDIAN // declare ieee_double_shape_type; #endif #if IEEE_WORD_ORDER == NPY_LITTLE_ENDIAN // declare ieee_double_shape_type; #endif so it looks like both word-order blocks are getting compiled. For the record, including the same header files as the failing code and compiling with the same command-line args I get: LITTLE_ENDIAN is defined: 1234 __LITTLE_ENDIAN is not defined __LITTLE_ENDIAN__ is defined: 1 (by gcc) BIG_ENDIAN is defined: 4321 __BIG_ENDIAN is not defined __BIG_ENDIAN__ is not defined BYTE_ORDER is defined: 1234 __BYTE_ORDER is not defined __BYTE_ORDER__ is not defined NPY_BYTE_ORDER is defined => __BYTE_ORDER NPY_BIG_ENDIAN is defined => __BIG_ENDIAN NPY_LITTLE_ENDIAN is defined => __LITTLE_ENDIAN and NPY_BYTE_ORDER etc are set in npy_endian.h, in this block of code: #ifdef NPY_HAVE_ENDIAN_H /* Use endian.h if available */ #include <endian.h> #define NPY_BYTE_ORDER __BYTE_ORDER #define NPY_LITTLE_ENDIAN __LITTLE_ENDIAN #define NPY_BIG_ENDIAN __BIG_ENDIAN #else (setup.py detected that I do have endian.h: build/src.macosx-10.5-i386-2.7/numpy/core/include/numpy/_numpyconfig.h:#define NPY_HAVE_ENDIAN_H 1 ) So my guess is that npy_endian.h is expecting glibc-style endian.h with __BYTE_ORDER but getting Apple's endian.h with BYTE_ORDER. Then NPY_BYTE_ORDER gets defined to __BYTE_ORDER which is itself not defined. Same with NPY_{BIG,LITTLE}_ENDIAN, and then apparently the two undefined things compare equal in wacky preprocessor land? For what it's worth, in my own codebase I see that I do this: #if \ (defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \ (defined( _BYTE_ORDER) && ( _BYTE_ORDER == _BIG_ENDIAN)) || \ (defined( BYTE_ORDER) && ( BYTE_ORDER == BIG_ENDIAN)) // yup, big-endian #endif This is a Mac OSX 10.5.8 machine, MacBook5,1, Intel Core2 Duo CPU P8600 @ 2.40GHz, gcc 4.4.6 and python 2.7.2 The weirdness on this system is that I installed a gcc with only x86_64 support, while the kernel and uname insist that it's i386, but I don't *think* that's implicated here. cheers, dustin

2 1

Re: [Numpy-discussion] Cross-covariance function
by Elliot Saba Feb. 1, 2012

Feb. 1, 2012

Thank you Sturla, that's exactly what I want. I'm sorry that I was not able to reply for so long, but Pierre's code is similar to what I have already implemented, and I am in support of changing the functionality of cov(). I am unaware of any arguments for a covariance function that works in this way, except for the fact that the MATLAB cov() function behaves in the same way. [1] MATLAB, however, has an xcov() function, which is similar to what we have been discussing. [2] Unless you all wish to retain compatibility with MATLAB, I feel that the behaviour of cov() suggested by Pierre is the most straightforward method, and that if users wish to calculate the covariance of X concatenated with Y, then they may simply concatenate the matrices explicitly before passing into cov(), as this way the default method does not use 75% more CPU time. Again, if there is an argument for this functionality, I would love to learn of it! -E [1] http://www.mathworks.com/help//techdoc/ref/cov.html [2] http://www.mathworks.com/help/toolbox/signal/ref/xcov.html

8 18

numpy all unexpected result (generator)
by Neal Becker Feb. 1, 2012

Feb. 1, 2012

I was just bitten by this unexpected behavior: In [24]: all ([i> 0 for i in xrange (10)]) Out[24]: False In [25]: all (i> 0 for i in xrange (10)) Out[25]: True Turns out: In [31]: all is numpy.all Out[31]: True So numpy.all doesn't seem to do what I would expect when given a generator. Bug?

10 20