Mailman 3 July 2008 - NumPy-Discussion

1.1.1rc1 to be tagged tonight
by Jarrod Millman 22 Jul '08

22 Jul '08

Hello, This is a reminder that 1.1.1rc1 will be tagged tonight. Chuck is planning to spend some time today fixing a few final bugs on the 1.1.x branch. If anyone else is planning to commit anything to the 1.1.x branch today, please let me know immediately. Obviously now is not the time to commit anything to the branch that could break anything, so please be extremely careful if you have to touch the branch. Once the release is tagged, Chris and David will create binary installers for both Windows and Mac. Hopefully, this will give us an opportunity to have much more widespread testing before releasing 1.1.1 final at the end of the month. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

8 59

Removing some warnings from numpy.i
by Matthieu Brucher 22 Jul '08

22 Jul '08

Hi, I've enclosed a patch for numpy.i (against the trunk). Its goal is to add const char* instead of char* in some functions (pytype_string and typecode_string). The char* use raises some warnings in GCC 4.2.3 (and it is indeed not type safe IMHO). Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher

2 1

Corner case complex log error.
by Charles R Harris 22 Jul '08

22 Jul '08

FAIL: test_umath.TestC99.test_clog(<ufunc 'log'>, (-0.0, -0.0), (-inf, -0.0), 'divide') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/nose/case.py", line 203, in runTest self.test(*self.arg) File "/usr/lib/python2.5/site-packages/numpy/core/tests/test_umath.py", line 393, in _check assert got == expected, (got, expected) AssertionError: ('(-inf, 3.1415926535897931)', '(-inf, 0.0)')

3 5

Getting ready for the upcomming python versions
by Nadav Horesh 22 Jul '08

22 Jul '08

I am trying to prepare for the trouble-making python3. I installed with success python2.6b2 and then numpy1.10. scipy failed to compile with the following error message: compile options: '-DNO_ATLAS_INFO=1 -DUSE_VENDOR_BLAS=1 -I/usr/local/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include/python2.6 -c' gcc: scipy/sparse/linalg/dsolve/_zsuperlumodule.c In file included from scipy/sparse/linalg/dsolve/_superluobject.h:8, from scipy/sparse/linalg/dsolve/_zsuperlumodule.c:32: scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:60: error: conflicting types for '_Py_c_abs' /usr/local/include/python2.6/complexobject.h:30: error: previous declaration of '_Py_c_abs' was here In file included from scipy/sparse/linalg/dsolve/_superluobject.h:8, from scipy/sparse/linalg/dsolve/_zsuperlumodule.c:32: scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:60: error: conflicting types for '_Py_c_abs' /usr/local/include/python2.6/complexobject.h:30: error: previous declaration of '_Py_c_abs' was here error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DNO_ATLAS_INFO=1 -DUSE_VENDOR_BLAS=1 -I/usr/local/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include/python2.6 -c scipy/sparse/linalg/dsolve/_zsuperlumodule.c -o build/temp.linux-x86_64-2.6/scipy/sparse/linalg/dsolve/_zsuperlumodule.o" failed with exit status 1 (Both scipy0.60 and the latest from svn fail the same) My system: Gentoo linux 64 on core2 duo, gcc4.3.1. My question: Is there a migration plan for the python3? Can a layman (with some C knowledge) like me help? Any remarks about the error message above would help. Nadav.

1 0

Trac up to it's old permissions game.
by Charles R Harris 21 Jul '08

21 Jul '08

Can't browse source, etc. Chuck

1 0

Windows_XP buildbot error.
by Charles R Harris 21 Jul '08

21 Jul '08

The log file shows: File "c:\numpy-buildbot\numpy\b11\install\Lib\site-packages\numpy\lib\tests\test_format.py", line 429, in test_memmap_roundtrip fp = open(nfn, 'wb') IOError: [Errno 2] No such file or directory: 'c:\\docume~1\\thomas\\locals~1\\temp\\tmp_yrykj\\normal.npy' Is this some sort of permissions error or something specific to Thomas' machine? I don't want this to show up in the 1.1.1 release and I'm wondering if there is an easy fix besides disabling the test. Chuck

2 2

numpy.loadtext() fails with dtype + usecols
by Ryan May 21 Jul '08

21 Jul '08

Hi, I was trying to use loadtxt() today to read in some text data, and I had a problem when I specified a dtype that only contained as many elements as in columns in usecols. The example below shows the problem: import numpy as np import StringIO data = '''STID RELH TAIR JOE 70.1 25.3 BOB 60.5 27.9 ''' f = StringIO.StringIO(data) names = ['stid', 'temp'] dtypes = ['S4', 'f8'] arr = np.loadtxt(f, usecols=(0,2),dtype=zip(names,dtypes), skiprows=1) With current 1.1 (and SVN head), this yields: IndexError Traceback (most recent call last) /home/rmay/<ipython console> in <module>() /usr/lib64/python2.5/site-packages/numpy/lib/io.pyc in loadtxt(fname, dtype, comments, delimiter, converters, skiprows, usecols, unpack) 309 for j in xrange(len(vals))] 310 if usecols is not None: --> 311 row = [converterseq[j](vals[j]) for j in usecols] 312 else: 313 row = [converterseq[j](val) for j,val in enumerate(vals)] IndexError: list index out of range ------------------------------------------ I've added a patch that checks for usecols, and if present, correctly creates the converters dictionary to map each specified column with converter for the corresponding field in the dtype. With the attached patch, this works fine: >arr array([('JOE', 25.300000000000001), ('BOB', 27.899999999999999)], dtype=[('stid', '|S4'), ('temp', '<f8')]) Comments? Can I get this in for 1.1.1? Thanks, Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma

3 2

building a better OSX install for 1.1.1
by Christopher Burns 21 Jul '08

21 Jul '08

Sorry Russell, I was a bit brief before. Installer.app checks for a system requirement when the user installs numpy. I build numpy using bdist_mpkg against the python.org version of python (MacPython). If a user tries to install numpy and they _do not_ have this version of python installed, Installer.app issues a warning: "numpy requires System Python 2.5 to install." The phrase "System Python" is misleading, it's reasonable to assume that refers to the system version of python. So I'd like to change it. This string is stored in an Info.plist buried in the .mpkg that bdist_mpkg builds. I'd like to be able to override that string from the command line, but there does not seem to be any options for changing the requirements from the command line. The hack solution is to modify the string in the Info.plist after the package is built. But I'm hoping there's a proper solution that I'm missing. Thanks! Chris On Fri, Jul 18, 2008 at 11:59 AM, Russell E. Owen <rowen(a)cesmail.net> wrote: > In article > <764e38540807172233m6bce652bp40478564de10e265(a)mail.gmail.com>, > "Christopher Burns" <cburns(a)berkeley.edu> wrote: > > > I've been using bdist_mpkg to build the OSX Installer. I'd like to > update > > the requirement documentation for the 1.1.1 release candidate to say > > "MacPython from python.org" instead of "System Python". bdist_mpkg > > specifies this, does anyone know how to override it? > > I suspect I am misunderstanding your question, but... > > If you are asking how to make bdist_mkpg actually use MacPython, then > surely you simply have to have MacPython installed for that to happen? > That was certainly true for MacPython and bdist_mpkg on 10.4.x. > > Or are you asking how to make the installer fail if the user's system is > missing MacPython? That I don't know. I usually rely on the .mpkg's > ReadMe and the user being intelligent enough to read it, but of course > that is a bit risky. > > If you are asking how to modify the ReadMe file then that is trivial -- > just look through the .mpkg package and you'll find it right away. I > often replace the default ReadMe with my own when creating .mpkg > installer for others. > > -- Russell > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion(a)scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- Christopher Burns Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

4 3

bug in ma ?
by Charles Doutriaux 21 Jul '08

21 Jul '08

Hello, I think i found a bug in numpy.ma I tried it both with the trunk and the 1.1 version import numpy a= numpy.ma.arange(256) a.shape=(128,2) b=numpy.reshape(a,(64,2,2)) Traceback (most recent call last): File "quick_test_reshape.py", line 7, in <module> b=numpy.reshape(a,(64,2,2)) File "/lgm/cdat/latest/lib/python2.5/site-packages/numpy/core/fromnumeric.py", line 116, in reshape return reshape(newshape, order=order) TypeError: reshape() got an unexpected keyword argument 'order'

2 1

Ticket #794 and can o' worms.
by Charles R Harris 20 Jul '08

20 Jul '08

Hi All, I "fixed" ticket #754, but it leads to a ton of problems. The original discussion is here<http://thread.gmane.org/gmane.comp.python.numeric.general/21526/focus=21537>. The problems that arise come from conversion to different types. In [26]: a Out[26]: array([ Inf, -Inf, NaN, 0., 3., -3.]) In [27]: sign(a).astype(int) Out[27]: array([ 1, -1, -2147483648, 0, 1, -1]) In [28]: sign(a).astype(bool) Out[28]: array([ True, True, True, False, True, True], dtype=bool) In [29]: sign(a) Out[29]: array([ 1., -1., NaN, 0., 1., -1.]) In [30]: bool(NaN) Out[30]: True So there are problems with at minimum the following. 1) The way NaN is converted to bool. I think it should be False. 2) The way NaN is converted to int types. I think it should be 0. These problems show up in failing tests. I'm reverting the fix for now, but I wonder what we should do about these things. Chuck

3 6

NumPy-Discussion July 2008