Mailman 3 July 2010 - NumPy-Discussion

Weighted scoreatpercentile or median?
by Ole Streicher 26 Jul '10

26 Jul '10

Hi list, is there a way to compute the weighted median or the weighted percentile http://en.wikipedia.org/wiki/Percentile#Weighted_Percentile with numpy or scipy? I only found the "scoreatpercentile" function in scipy.stat, and the "median" functions of scipy.stat and numpy, but they both dont allow to specify a weight. Best regards Ole

1 0

Arrays of Python Values
by Ian Mallett 25 Jul '10

25 Jul '10

Hi, So working on the radiosity renderer: http://a.imageshack.us/img186/2479/image2f.png. The code now runs fast enough to generate the data required to draw that. Now, I need to optimize the radiosity calculation, so that it will converge in a reasonable amount of time. Right now, the individual blocks ("patches") are stored as instances of Python classes in a list. I'd heard that NumPy supports arrays of Python objects, so, I simply made an array out of the list, which seemed ok. Unfortunately, there is a custom sorting operation that sorted the list of by an attribute of each class: self.patches.sort( lambda x,y:cmp(x.residual_radiance,y.residual_radiance), reverse=True ) Because I've never used arrays of Python objects (and Googling didn't turn up any examples), I'm stuck on how to sort the corresponding array in NumPy in the same way. Of course, perhaps I'm just trying something that's absolutely impossible, or there's an obviously better way. I get the feeling that having no Python objects in the NumPy array would speed things up even more, but I couldn't figure out how I'd handle the different attributes (or specifically, how to keep them together during a sort). What're my options? Thanks again for the extremely valuable help, Ian

4 4

Problem using polyutils.mapdomain with fromfunction
by David Goldsmith 25 Jul '10

25 Jul '10

Why am I being told my coefficient array is not 1-d when both coefficient arrays--old and new--are reported to have shape (2L,): C:\Users\Fermat>python Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as np >>> np.version.version '1.4.1' >>> from numpy.polynomial import polyutils as pu >>> nx = 1 >>> ny = 1 >>> def whydoesntthiswork(x, y): ... old = np.array((0,2)); print old.shape ... new = np.array((-1,1)); print new.shape ... X = pu.mapdomain(x, old, new) ... return X ... >>> result = np.fromfunction(whydoesntthiswork, (nx, ny)) (2L,) (2L,) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python26\lib\site-packages\numpy\core\numeric.py", line 1539, in from function return function(*args,**kwargs) File "<stdin>", line 4, in whydoesntthiswork File "C:\Python26\lib\site-packages\numpy\polynomial\polyutils.py", line 280, in mapdomain [x] = as_series([x], trim=False) File "C:\Python26\lib\site-packages\numpy\polynomial\polyutils.py", line 139, in as_series raise ValueError("Coefficient array is not 1-d") ValueError: Coefficient array is not 1-d Thanks in advance, DG

2 2

segmentation fault when installing with pip and python2.7
by celil 25 Jul '10

25 Jul '10

Hello, I just installed numpy on Snow Leopard using pip. However, running the tests results in a segmentation fault. Has anybody else encountered this problem? How did you solve it? The sequence of commands that reproduce the bug is: $ pip install numpy $ python -c "import numpy; numpy.test('10')" And this is the output: Running unit tests for numpy NumPy version 1.4.1 NumPy is installed in /usr/local/Cellar/python/2.7/lib/python2.7/site-packages/numpy Python version 2.7 (r27:82500, Jul 18 2010, 06:55:14) [GCC 4.2.1 (Apple Inc. build 5664)] nose version 0.11.4 ...................................................................................................................................Segmentation fault Regards, Celil

7 8

Re: [Numpy-discussion] numpy.append and persisting original datatype
by Martin Galpin 25 Jul '10

25 Jul '10

Hello, After a little more research, I can see that as a work around is: foo = np.append(foo, np.asanyarray([1., 2., 3.], dtype=foo.dtype)) It seems that within numpy.append(), the call to ravel() (numpy/ function.base.py [line 3490]) produces an array with a dtype that best fits. In this case it is float64 (when my original array was float32). Best wishes

1 0

Sine Distribution on a 2D Array
by Ian Mallett 25 Jul '10

25 Jul '10

Hi, So I have a square 2D array, and I want to fill the array with sine values. The values need to be generated by their coordinates within the array. The center of the array should be treated as the angle 90 degrees. Each of the four edges should be 0 degrees. The corners, therefore, ought to be -sqrt(2)*90 degrees. The angle is equal to (distance_from_center/(dimension_of_array/2))*90 degrees. Then take the sine of this angle. To describe another way, if the array is treated like a height-field, a single mound of the sine wave should just fit inside the array. Right now, I'm having trouble because I don't know how to operate on an array's values based on the index of the values themselves. Help? Thanks, Ian

2 2

numpy.append and persisting original datatype
by Benjamin Root 25 Jul '10

25 Jul '10

On Sat, Jul 24, 2010 at 4:14 PM, Martin Galpin <galpin(a)gmail.com> wrote: > Hello, > > Given the following example: > > import numpy as np > foo = np.array([], dtype=np.float32) > print a.dtype > >> float32 > foo = np.append(foo, 1) > print foo.dtype > >> float64 > > Is this the correct behaviour? I realise that numpy.append() returns a new > copy of foo but is it the correct behaviour that the original datatype is > not persisted? If so, should this not be noted in the documentation? > > Forgive me if I have missed something. > > Best wishes > > -- > Martin > > I have moved this over to the numpy-discussion list. Ben Root

1 0

Re: [Numpy-discussion] Numpy installation problem
by Jonathan Tu 24 Jul '10

24 Jul '10

On Sat 24/07/10 3:39 PM , David Cournapeau <cournape(a)gmail.com> wrote: > On Sun, Jul 25, 2010 at 4:23 AM, Jonathan Tu wrote: > > > > On Jul 24, 2010, at 3:08 PM, Benjamin Root wrote: > > > > On Fri, Jul 23, 2010 at 10:10 AM, Jonathan Tu wrote: > >> > >> Hi, > >> I am trying to install Numpy on a Linux cluster running RHEL4. I > >> installed a local copy of Python 2.7 because RHEL4 uses Python 2.3.4 > for > >> various internal functionalities. I downloaded the Numpy source code > using > >> svn co http://svn.scipy.org/svn/numpy/trunk [1] numpy > >> and then I tried to build using > >> python setup.py build > >> This resulted in the following error: > >> gcc: numpy/linalg/lapack_litemodule.c gcc: > numpy/linalg/python_xerbla.c > >> /usr/bin/g77 -g -Wall -g -Wall -shared > >> build/temp.linux-x86_64-2.7/numpy/linalg/lapack_litemodule.o > >> build/temp.linux-x86_64-2.7/numpy/linalg/python_xerbla.o > -L/usr/lib64/ATLAS > >> -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas > -lg2c > >> -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so /usr/bin/ld: > >> /usr/lib64/ATLAS/liblapack.a(dgeev.o): relocation R_X86_64_32 against > `a > >> local symbol' can not be used when making a shared object; recompile > with > >> -fPIC /usr/lib64/ATLAS/liblapack.a: could not read symbols: Bad value > >> collect2: ld returned 1 exit status /usr/bin/ld: > >> /usr/lib64/ATLAS/liblapack.a(dgeev.o): relocation R_X86_64_32 against > `a > >> local symbol' can not be used when making a shared object; recompile > with > >> -fPIC /usr/lib64/ATLAS/liblapack.a: could not read symbols: Bad value > >> collect2: ld returned 1 exit status error: Command "/usr/bin/g77 -g > -Wall -g > >> -Wall -shared > build/temp.linux-x86_64-2.7/numpy/linalg/lapack_litemodule.o > >> build/temp.linux-x86_64-2.7/numpy/linalg/python_xerbla.o > -L/usr/lib64/ATLAS > >> -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas > -lg2c > >> -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so" failed with > exit > >> status 1 > >> > >> Full details of the output are attached in stdout.txt and stderr.txt. > I > >> thought maybe it was a compiler error so I tried > >> python setup.py build -fcompiler=gnu > >> but this also resulted in errors as well (stdout_2.txt, stderr_2.txt). > >> I just noticed that on both attempts, it is complaining that it can't > find > >> a Fortran 90 compiler. I'm not sure if I have the right compiler > available. > >> On this cluster I have the following modules: > >> ------------ /usr/share/Modules/modulefiles ------------ > >> dot module-cvs module-info modules null > use.own > >> ------------ /usr/local/share/Modules/modulefiles ------------ > >> mpich/gcc/1.2.7p1/64 openmpi/gcc-ib/1.2.3/64 > >> mpich/intel/1.2.7dmcrp1/64 openmpi/gcc-ib/1.2.5/64 > >> mpich/intel/1.2.7p1/64 openmpi/intel/1.2.3/64 > >> mpich/pgi-7.1/1.2.7p1/64 openmpi/intel-11.0/1.2.8/64 > >> mpich-debug/gcc/1.2.7p1/64 openmpi/intel-9.1/1.2.8/64 > >> mpich-debug/intel/1.2.7p1/64 openmpi/intel-ib/1.1.5/64 > >> mpich-debug/pgi-7.1/1.2.7p1/64 openmpi/intel-ib/1.2.3/64 > >> mvapich/gcc/0.9.9/64 openmpi/intel-ib/1.2.5/64 > >> mvapich/pgi-7.1/0.9.9/64 openmpi/pgi-7.0/1.2.3/64 > >> openmpi/gcc/1.2.8/64 openmpi/pgi-7.1/1.2.5/64 > >> openmpi/gcc/1.3.0/64 openmpi/pgi-7.1/1.2.8/64 > >> openmpi/gcc-ib/1.1.5/64 openmpi/pgi-8.0/1.2.8/64 > >> ------------ /opt/share/Modules/modulefiles ------------ > >> intel/10.0/64/C/10.0.026 intel/9.1/64/default > >> intel/10.0/64/Fortran/10.0.026 intel-mkl/10/64 > >> intel/10.0/64/Iidb/10.0.026 intel-mkl/10.1/64 > >> intel/10.0/64/default intel-mkl/9/32 > >> intel/11.1/64/11.1.038 intel-mkl/9/64 > >> intel/11.1/64/11.1.072 pgi/7.0/64 > >> intel/9.1/64/C/9.1.045 pgi/7.1/64 > >> intel/9.1/64/Fortran/9.1.040 pgi/8.0/64 > >> intel/9.1/64/Iidb/9.1.045 > >> If anyone has any ideas, they would be greatly appreciated! I am new > to > >> Linux and am unsure how to fix this problem. > >> > >> > >> > >> > >> Jonathan Tu > >> > > > > Jonathan, > > > > Looking at your error logs, I suspect that the issue is that the ATLAS > > libraries that were installed on your system were probably built using > f90, > > and then your f77-built objects can't link against ATLAS. Do you have > admin > > access to this machine? If possible, try using the yum package > manager to > > install f90 (its availability depends on whatever RHEL license you > have, > > though...). > > > > If you can install f90, I would then remove the numpy build directory > and > > try building it again. > > > > I hope this helps, > > Ben Root > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion [2] > > > > > > Hi Ben, > > I managed to complete my installation. It required setting up the > configure > > file to reference my local installation of Python, rather than the > default > > /usr/bin/Python. However, I would like to see whether or not I am > using the > > optimized ATLAS/LAPACK libraries for my matrix computations. > > Run ldd on the concerned extensions: numpy/linalg/lapack_lite.so and > numpy/core/_dotblas.so > > David I am unable to find the files lapack_lite.so or _dotblas.so. I used the locate command to look for them. Does this mean my Numpy installation was not build against LAPACK at all? If so, how would I fix this? I'm sorry for the very basic questions, but I am fairly new to Linux and Python. Jonathan Tu

3 18

Numpy installation problem
by Jonathan Tu 24 Jul '10

24 Jul '10

Hi, I am trying to install Numpy on a Linux cluster running RHEL4. I installed a local copy of Python 2.7 because RHEL4 uses Python 2.3.4 for various internal functionalities. I downloaded the Numpy source code using svn co http://svn.scipy.org/svn/numpy/trunk numpy and then I tried to build using python setup.py build This resulted in the following error: gcc: numpy/linalg/lapack_litemodule.c gcc: numpy/linalg/python_xerbla.c /usr/bin/g77 -g -Wall -g -Wall -shared build/temp.linux-x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.linux-x86_64-2.7/numpy/linalg/python_xerbla.o -L/usr/lib64/ATLAS -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lg2c -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so /usr/bin/ld: /usr/lib64/ATLAS/liblapack.a(dgeev.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/ATLAS/liblapack.a: could not read symbols: Bad value collect2: ld returned 1 exit status /usr/bin/ld: /usr/lib64/ATLAS/liblapack.a(dgeev.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/ATLAS/liblapack.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: Command "/usr/bin/g77 -g -Wall -g -Wall -shared build/temp.linux-x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.linux-x86_64-2.7/numpy/linalg/python_xerbla.o -L/usr/lib64/ATLAS -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lg2c -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so" failed with exit status 1 Full details of the output are attached in stdout.txt and stderr.txt. I thought maybe it was a compiler error so I tried python setup.py build -fcompiler=gnu but this also resulted in errors as well (stdout_2.txt, stderr_2.txt). I just noticed that on both attempts, it is complaining that it can't find a Fortran 90 compiler. I'm not sure if I have the right compiler available. On this cluster I have the following modules: ------------ /usr/share/Modules/modulefiles ------------ dot module-cvs module-info modules null use.own ------------ /usr/local/share/Modules/modulefiles ------------ mpich/gcc/1.2.7p1/64 openmpi/gcc-ib/1.2.3/64 mpich/intel/1.2.7dmcrp1/64 openmpi/gcc-ib/1.2.5/64 mpich/intel/1.2.7p1/64 openmpi/intel/1.2.3/64 mpich/pgi-7.1/1.2.7p1/64 openmpi/intel-11.0/1.2.8/64 mpich-debug/gcc/1.2.7p1/64 openmpi/intel-9.1/1.2.8/64 mpich-debug/intel/1.2.7p1/64 openmpi/intel-ib/1.1.5/64 mpich-debug/pgi-7.1/1.2.7p1/64 openmpi/intel-ib/1.2.3/64 mvapich/gcc/0.9.9/64 openmpi/intel-ib/1.2.5/64 mvapich/pgi-7.1/0.9.9/64 openmpi/pgi-7.0/1.2.3/64 openmpi/gcc/1.2.8/64 openmpi/pgi-7.1/1.2.5/64 openmpi/gcc/1.3.0/64 openmpi/pgi-7.1/1.2.8/64 openmpi/gcc-ib/1.1.5/64 openmpi/pgi-8.0/1.2.8/64 ------------ /opt/share/Modules/modulefiles ------------ intel/10.0/64/C/10.0.026 intel/9.1/64/default intel/10.0/64/Fortran/10.0.026 intel-mkl/10/64 intel/10.0/64/Iidb/10.0.026 intel-mkl/10.1/64 intel/10.0/64/default intel-mkl/9/32 intel/11.1/64/11.1.038 intel-mkl/9/64 intel/11.1/64/11.1.072 pgi/7.0/64 intel/9.1/64/C/9.1.045 pgi/7.1/64 intel/9.1/64/Fortran/9.1.040 pgi/8.0/64 intel/9.1/64/Iidb/9.1.045 If anyone has any ideas, they would be greatly appreciated! I am new to Linux and am unsure how to fix this problem. Jonathan Tu

4 3

Re: [Numpy-discussion] f2py problem with complex inout in subroutine
by Mark Bakker 24 Jul '10

24 Jul '10

Thanks for fixing this, Pearu. Complex arrays with intent(inout) don't seem to work either. They compile, but a problem occurs when calling the routine. Did you fix that as well? Here's an example that doesn't work (sorry, I cannot update to svn 8478 on my machine right now): subroutine test3(nlab,omega) implicit none integer, intent(in) :: nlab complex(kind=8), dimension(nlab), intent(inout) :: omega integer :: n do n = 1,nlab omega(n) = cmplx(1,1,kind=8) end do end subroutine test3 Thanks, Mark On 07/09/2010 02:03 PM, Mark Bakker wrote: >> Hello list. The following subroutine fails to compile with f2py. >> I use a complex variable with intent(inout). It works fine with two real >> variables, so I have a workaround, but it would be nicer with a complex >> variable. >> Any thoughts on what I am doing wrong? >compilation failed because of typos in the generated code. This is fixed >in svn revision 8478. >Pearu

2 1