josef.pktd | 1 Feb 2012 02:45
Picon

Re: numpy all unexpected result (generator)

On Tue, Jan 31, 2012 at 5:35 PM, Travis Oliphant <travis <at> continuum.io> wrote:
> Actually i believe the NumPy 'any' and 'all' names pre-date the Python usage which first appeared in
Python 2.5
>
> I agree with Chris that namespaces are a great idea.  I don't agree with deprecating 'any' and 'all'

I completely agree here.

I also like to keep np.all, np.any, np.max, ...

>>> np.max((i>  0 for i in xrange (10)))
<generator object <genexpr> at 0x046493F0>
>>> max((i>  0 for i in xrange (10)))
True

I used an old-style matplotlib example as recipe yesterday, and the
first thing I did is getting rid of the missing name spaces, and I had
to think twice what amax and amin are.

aall, aany ??? ;)

Josef

>
> It also seems useful to revisit under what conditions 'array' could correctly interpret a generator
expression, but in the context of streaming or deferred arrays.
>
> Travis
>
>
(Continue reading)

Mark Bakker | 1 Feb 2012 10:25
Picon

combination of list of indices and newaxis not allowed?

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'

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Olivier Delalleau | 1 Feb 2012 12:47
Picon

Re: combination of list of indices and newaxis not allowed?

I think you just can't use newaxis in advanced indexing (doc says "The newaxis object can be used in the basic slicing syntax", and does not mention newaxis in the advanced indexing part).

-=- Olivier

Le 1 février 2012 04:25, Mark Bakker <markbak <at> gmail.com> a écrit :
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'


_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Pierre Haessig | 1 Feb 2012 17:47
Favicon
Gravatar

Re: Cross-covariance function

Hi Bruce,
Sorry for the delay in the answer.

Le 27/01/2012 17:28, Bruce Southey a écrit :
> The output is still a covariance so do we really need yet another set 
> of very similar functions to maintain?
> Or can we get away with a new keyword?
>
The idea of an additional keyword seems appealing.
Just to make sure I understood it well, you woud be proposing a new 
signature like :
def cov(.... get_full_cov_matrix=True)

and when `get_full_cov_matrix` is set to False, only the cross 
covariance part would be returned.
Am I right ?
> If speed really matters to you guys then surely moving np.cov into C 
> would have more impact on 'saving the world' than this proposal. That 
> also ignores algorithm used ( 
> http://en.wikipedia.org/wiki/Algorithms_for_calculating_variance#Covariance). 
>
>
I didn't get your point about the algorithm here. From this 
nomenclature, I would say that numpy.cov is based on a vectorized 
"two-pass algorithm" which computes the means first and then substracts 
it before computing the matrix product. Would you make it different ?

> Actually np.cov also is deficient in that it does not have the dtype 
> argument so it is prone to numerical precision errors (especially 
> getting the mean of the array). Probably should be a ticket...
I'm not a specialist of numerical precisions, but I got very impressed 
by the recent example raised on Jan 24th by Michael Aye which was one of 
the first "real life" example I've seen.

The way I see the cov algorithm, I see first a possibility to propagate 
an optional dtype argument to the mean computation.
However, I'm unsure about what to do after, for the matrix product since 
"dot(X.T, X.conj()) / fact" is also a sort of mean computation. 
Therefore it can also be affected by numerical precision issue. What 
would you suggest ?

(the only solution I see would be to use the running variance algorithm. 
Since the code wouldn't be vectorized anymore, this indeed would 
benefits from going to C)

Best,
Pierre
martin großhauser | 1 Feb 2012 17:53
Picon

Broadcasting doesn't work with divide after tile

Hello,

when I try in my script to divide a masked array by a scalar I get an
error. The instruction is:

>> sppa = sp / 100.

sp is a masked array with ndim = 3.

error is:
Traceback (most recent call last):
  File "/media/nethome/Work/workspace/interimEnso/src/mlBudget.py",
line 95, in <module>
    sppa = sp / 100.
  File "/usr/lib/pymodules/python2.7/numpy/ma/core.py", line 3673, in __div__
    return divide(self, other)
  File "/usr/lib/pymodules/python2.7/numpy/ma/core.py", line 1072, in __call__
    m |= ma
ValueError: invalid return array shape

The interesting thing is that this error only occurs after a tiling instruction:
>>         sp4d = N.tile(sp, (ninterf, 1, 1, 1))

If I do the division before the tiling I don't get an error. There's
also no error if I do the division with N.divide(sp, 100.).

Also printing the array sp after tiling doesn't work, while it works
before. If I debug the script with eclipse/PyDev, in the variables
window I get the message "Unable to get repr for <class
'numpy.ma.core.MaskedArray'>" for the sp array after tiling.

The tiling operation shouldn't change the array, should it? Is this a
bug, or is it expected behaviour?

Regards,
Martin Groszhauser

If I try to print the
Dustin Lang | 1 Feb 2012 18:03
Picon
Favicon

I must be wrong? -- endian detection failure on Mac OSX 10.5


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  <at>  
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
Samuel John | 1 Feb 2012 18:13
Picon
Gravatar

Re: I must be wrong? -- endian detection failure on Mac OSX 10.5

Hi!

Your Machine should be able to handle at least Mac OS X10.6 and even 10.7.
If there is not a strong reason to remain on 10.5...

10.5 is so long ago, I can barely remember.

cheers,
 Samuel

On 01.02.2012, at 18:03, Dustin Lang wrote:

> 
> 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  <at>  
> 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
> 
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion <at> scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
Aronne Merrelli | 1 Feb 2012 18:33
Picon

Help with f2py in MacPorts environment

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

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Pierre Haessig | 1 Feb 2012 19:31
Favicon
Gravatar

autocorrelation computation performance : use of np.correlate

Hi,

[I'm not sure whether this discussion belongs to numpy-discussion or 
scipy-dev]

In day to day time series analysis I regularly need to look at the data 
autocorrelation ("acorr" or "acf" depending on the software package).
The straighforward available function I have is matplotlib.pyplot.acorr. 
However, for a moderately long time series (say of length 10**5) it 
taking a huge time just to just dislays the autocorrelation values 
within a small range of time lags.
The main reason being it is relying on np.correlate(x,x, mode=2) while 
only a few lags are needed.
(I guess mode=2 is an (old fashioned?) way to set mode='full')

I know that np.correlate performance issue has been discussed already, 
and there is a *somehow* related ticket 
(http://projects.scipy.org/numpy/ticket/1260). I noticed in the ticket's 
change number 2 the following comment by Josef : "Maybe a truncated 
convolution/correlation would be good". I'll come back to this soon.

I made an example script "acf_timing.py" to start my point with some 
timing data :

In Ipython:
 >>> run acf_timing.py # it imports statsmodel's acf + define 2 other 
acf implementations + an example data 10**5 samples long

%time l,c = mpl_acf(a, 10)
CPU times: user 8.69 s, sys: 0.00 s, total: 8.69 s
Wall time: 11.18 s # pretty long...

  %time c = sm_acf(a, 10)
CPU times: user 8.76 s, sys: 0.01 s, total: 8.78 s
Wall time: 10.79 s # long as well. statsmodel has a similar underlying 
implementation
# 
http://statsmodels.sourceforge.net/generated/scikits.statsmodels.tsa.stattools.acf.html#scikits.statsmodels.tsa.stattools.acf

#Now, better option : use the fft convolution
%time c=sm_acf(a, 10,fft=True)
CPU times: user 0.03 s, sys: 0.01 s, total: 0.04 s
Wall time: 0.07 s
# Fast, but I'm not sure about the memory implication of using fft though.

#The naive option : just compute the acf lags that are needed
%time l,c = naive_acf(a, 10)
CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s
Wall time: 0.01 s
# Iterative computation. Pretty silly but very fast
# (Now of course, this naive implementation won't scale nicely for a lot 
of lags)

Now comes (at last) the question : what should be done about this 
performance issue ?
  - should there be a truncated np.convolve/np.correlate function, as 
Josef suggested ?
  - or should people in need of autocorrelation find some workarounds 
because this usecase is not big enough to call for a change in np.convolve ?

I really feel this question is about *where* a change should be 
implemented  (numpy, scipy.signal, maplotlib ?) so that it makes sense 
while not breaking 10^10 lines of numpy related code...

Best,
Pierre

Attachment (acf_timing.py): text/x-python, 1780 bytes
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
martin großhauser | 1 Feb 2012 19:55
Picon

Re: Broadcasting doesn't work with divide after tile

2012/2/1 martin großhauser <mgroszhauser <at> gmail.com>:
> Hello,
>
> when I try in my script to divide a masked array by a scalar I get an
> error. The instruction is:
>
>>> sppa = sp / 100.
>
> sp is a masked array with ndim = 3.
>
> error is:
> Traceback (most recent call last):
>  File "/media/nethome/Work/workspace/interimEnso/src/mlBudget.py",
> line 95, in <module>
>    sppa = sp / 100.
>  File "/usr/lib/pymodules/python2.7/numpy/ma/core.py", line 3673, in __div__
>    return divide(self, other)
>  File "/usr/lib/pymodules/python2.7/numpy/ma/core.py", line 1072, in __call__
>    m |= ma
> ValueError: invalid return array shape
>
> The interesting thing is that this error only occurs after a tiling instruction:
>>>         sp4d = N.tile(sp, (ninterf, 1, 1, 1))
>
> If I do the division before the tiling I don't get an error. There's
> also no error if I do the division with N.divide(sp, 100.).
>
> Also printing the array sp after tiling doesn't work, while it works
> before. If I debug the script with eclipse/PyDev, in the variables
> window I get the message "Unable to get repr for <class
> 'numpy.ma.core.MaskedArray'>" for the sp array after tiling.
>
> The tiling operation shouldn't change the array, should it? Is this a
> bug, or is it expected behaviour?
>
> Regards,
> Martin Groszhauser

I forgot to mention that I'm using Numpy 1.5.1 from Ubuntu 11.04
(1.5.1-1ubuntu2).

Gmane