Mailman 3 August 2008 - NumPy-Discussion

isn't it a bug in array.fill()?
by dmitrey 29 Aug '08

29 Aug '08

hi all, isn't it a bug (latest numpy from svn, as well as my older version) from numpy import array print array((1,2,3)).fill(10) None Regards, D.

5 10

Re: [Numpy-discussion] isn't it a bug in array.fill()
by dmitrey 29 Aug '08

29 Aug '08

sorry, it isn't a bug, it's my fault, fill() returns None and do in-place modification. D.

1 0

Problem with numpy in pyinstaller
by Jeffrey Starn 29 Aug '08

29 Aug '08

I have a program that imports numpy and scipy. When I try to use PyInstaller, I get the following error: File "<string>", line 21, in <module> NameError: name 'io' is not defined The code up to line 21 is (line numbers differ becasue of comments): from numpy import * from numpy import random from scipy import * from scipy.linalg import cholesky from scipy.io import write_array model=raw_input('MF2K or UCode? ') model=model.upper() fname=raw_input('Root name? ') NumRan=raw_input('Number of random realizations? ') NumRan=int(NumRan) outfile=fname+".ranvar" MvName=fname+"._mv" Mv=io.read_array(MvName,lines=(1,-1) I have seen related psots, but I really don't understand what the fix is. Thanks. --------------------------------------------------------------------------------------------------------- Jeff Starn, Ground-water Specialist U.S. Geological Survey 101 Pitkin Street East Hartford, CT 06108 (860) 291-6746 jjstarn(a)usgs.gov ---------------------------------------------------------------------------------------------------------

1 0

#882: PyArray_ConvertToCommon and 0 sized sequences
by David Cournapeau 29 Aug '08

29 Aug '08

Hi, The error in #882 looks pretty straightforward: from numpy import numarray a = numarray.array(1) a.choose([]) core dumps because a.choose calls PyArray_ConvertCommonType with a 0-sized array, which is not handled correctly. Should the 0-sized case be handled in this function, or in PyArray_Choose (the caller of PyArray_ConvertCommonType) ? cheers, David

1 0

Where does _assert_func come from.
by Charles R Harris 29 Aug '08

29 Aug '08

Where does _assert_func come from in this fragment from a test class? class _GenericTest(object): def _test_equal(self, a, b): self._assert_func(a, b) I hope it isn't monkey patched in. Chuck

2 5

numpy and py2exe
by Christopher Barker 29 Aug '08

29 Aug '08

Hi all, An issue just came up with numpy and py2exe on the wxPython list. A solution has been found, but I thought I'd post here, so that it could be on the numpy developers' radar when considering the structure of numpy for the future: > I'm compile a wxPython script using GUI2Exe, and am getting the > following when running the produced exe: > > $ ./dist/svm.exe > Traceback (most recent call last): > File "svm.py", line 28, in <module> > import graphic_svm_data > File "graphic_svm_data.pyo", line 29, in <module> > File "floatcanvas\NavCanvas.pyo", line 7, in <module> > File "floatcanvas\FloatCanvas.pyo", line 7, in <module> > File "numpy\__init__.pyo", line 93, in <module> > File "numpy\add_newdocs.pyo", line 9, in <module> > File "numpy\lib\__init__.pyo", line 19, in <module> > File "numpy\lib\financial.pyo", line 78, in <module> > TypeError: unsupported operand type(s) for +=: 'NoneType' and 'str' > I tried to add numpy.lib.financial to the Excludes and Ignores list, but am still getting this error. > > Googling found that this problem is a known bug: http://article.gmane.org/gmane.comp.python.py2exe/2920 The solution was to: > 2) Use Optimize=1 or Optimize=0 in GUI2Exe and re-build your > executable. Uing Optimize=2 strips all docstrings in the executable, > which may cause troubles (as in your case); > [Ron Barak] YES!!! > With Optimize=1 my script finally compiles to exe. While this worked, I have a couple observations: 1) This broke on numpy.lib.financial. that had nothing to do with the issue, but it would be nice if people could use numpy with py2exe and the like without having to include all those unused packages. I think this ties in with the discussion about speeding up with importing process, and may be addressed in future versions if I understood the results of some of the discussion at SciPy right. 2) it would also be nice if one could use numpy with the docstrings removed, like in this case. I have no idea what the issues are with that. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

2 3

ImportError: No module named my_module
by Nils Wagner 28 Aug '08

28 Aug '08

====================================================================== ERROR: Failure: ImportError (No module named my_module) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.10.1-py2.5.egg/nose/loader.py", line 364, in loadTestsFromName addr.filename, addr.module) File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.10.1-py2.5.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.10.1-py2.5.egg/nose/importer.py", line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/data/home/nwagner/local/lib/python2.5/site-packages/numpy/doc/__init__.py", line 10, in <module> __import__(__name__ + '.' + f) File "/data/home/nwagner/local/lib/python2.5/site-packages/numpy/doc/example.py", line 35, in <module> from my_module import my_func, other_func ImportError: No module named my_module

3 5

Re: [Numpy-discussion] rc1 update
by Travis E. Oliphant 28 Aug '08

28 Aug '08

Andrew Straw wrote: > Joining the party late, here, so I don't know how much has already been > said... Particularly in favor of renaming NPY_VERSION. What's the benefit? > > I'm -1 on removing the name NPY_VERSION. It would cause unnecessary > breakage. > > I'm -0 on defining an additional NPY_ABI_VERSION to equal NPY_VERSION. > It just seems unnecessary to me. Won't a comment do, e.g. /* We wanted > to name this NPY_ABI_VERSION, but it was already NPY_VERSION since pre > 1.0, so we're sticking with it. (Until 1.2, it also served a dual role > as NPY_API_VERSION, when we added that, below.) */ ? > > I'm +0 on renaming the recently added NPY_FEATURE_VERSION to > NPY_API_VERSION. I don't care what it's called, really. > > Since A) this is a C developer thing only (aka people who should know > what they're doing), B) there is already IMO fairly good documentation > immediately above the NPY_VERSION and NPY_FEATURE_VERSION in the header > file, and C) very little impetus for anyone to actually directly use > NPY_VERSION anyway (there's a runtime ABI check during import_array() > which is the most important thing -- it checks at runtime if the compile > time ABI version of the caller and numpy itself are the same), I think > it's best to leave NPY_VERSION as NPY_VERSION. > > The only code that I know of that currently explicitly uses NPY_VERSION > is C preprocessor tests for which C API to use -- from now, new code > being written will check the new NPY_FEATURE_VERSION (or NPY_API_VERSION > or whatever it ends up being called) for API features. Anyone updating > old code will already have a bit of additional complexity to deal with, > and I want to minimize the amount of additional complexity. We don't > want a rat's nest of C preprossor #ifdefs as people track the numpy > version checking defines. Given the addition of NPY_FEATURE_VERSION, > code that's already been written with explicit NPY_VERSION checks for > API information is already going to become outdated, but as long as we > keep the NPY_VERSION name, at least it won't break or require another > level of complexity to maintain forward compatibility. > > +1 on what Andrew said. -Travis

4 3

Array subclassing - question for Travis
by Matthew Brett 28 Aug '08

28 Aug '08

Hi Travis and team, I am just writing some docs for subclassing, and ran into some behavior I didn't understand: In [143]: class A(np.ndarray): pass In [144]: arr = np.arange(5) In [145]: obj = arr.copy().view(A) In [146]: type(obj) Out[146]: <class '__main__.A'> In [147]: obj.__array_priority__ # shouldn't this be 1.0 by default (from the numpy book)? Out[147]: 0.0 In [148]: type(np.multiply(arr, obj)) # this is what I expected Out[148]: <class '__main__.A'> In [149]: type(np.multiply.outer(arr, obj)) # this is not - I expected class A again Out[149]: <type 'numpy.ndarray'> In [151]: class A(np.ndarray): __array_priority__ = 20.0 # setting array priority does not affect behavior In [152]: obj = arr.copy().view(A) In [153]: type(np.multiply.outer(arr, obj)) Out[153]: <type 'numpy.ndarray'> Is this what you would expect? Thanks for clarification, and apologies if I misunderstood... Matthew

2 3

numpy trunk build broken on 32-bit ubuntu
by Fernando Perez 28 Aug '08

28 Aug '08

Howdy, building numpy from trunk right now (r5708) on a 32-bit ubuntu box gives: compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-i686-2.5/build creating build/temp.linux-i686-2.5/build/src.linux-i686-2.5 creating build/temp.linux-i686-2.5/build/src.linux-i686-2.5/numpy creating build/temp.linux-i686-2.5/build/src.linux-i686-2.5/numpy/core creating build/temp.linux-i686-2.5/build/src.linux-i686-2.5/numpy/core/src compile options: '-Ibuild/src.linux-i686-2.5/numpy/core/src -Inumpy/core/include -Ibuild/src.linux-i686-2.5/numpy/core/include/numpy -Inumpy/core/src -Inumpy/core/include -I/usr/include/python2.5 -c' gcc: build/src.linux-i686-2.5/numpy/core/src/umathmodule.c numpy/core/src/umathmodule.c.src:332: error: static declaration of 'trunc' follows non-static declaration numpy/core/src/umathmodule.c.src: In function 'trunc': numpy/core/src/umathmodule.c.src:333: warning: unused variable 'r' numpy/core/src/umathmodule.c.src:333: warning: unused variable 'y' numpy/core/src/umathmodule.c.src:332: error: static declaration of 'trunc' follows non-static declaration numpy/core/src/umathmodule.c.src: In function 'trunc': numpy/core/src/umathmodule.c.src:333: warning: unused variable 'r' numpy/core/src/umathmodule.c.src:333: warning: unused variable 'y' error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -Ibuild/src.linux-i686-2.5/numpy/core/src -Inumpy/core/include -Ibuild/src.linux-i686-2.5/numpy/core/include/numpy -Inumpy/core/src -Inumpy/core/include -I/usr/include/python2.5 -c build/src.linux-i686-2.5/numpy/core/src/umathmodule.c -o build/temp.linux-i686-2.5/build/src.linux-i686-2.5/numpy/core/src/umathmodule.o" failed with exit status 1 Notes (Matthew Brett found all of this): - on 64-bit fedora it builds fine - calling a similar test on 32-bit ubuntu with "gcc -std=c99" works. Perhaps the build is using something similar... - Not that I want to blame anyone, but I suspect this has something to do with David C's recent checkins: ------------------------------------------------------------------------ r5699 | cdavid | 2008-08-25 15:05:29 -0700 (Mon, 25 Aug 2008) | 2 lines Add a trunc function in umath module. ------------------------------------------------------------------------ r5698 | cdavid | 2008-08-25 15:05:21 -0700 (Mon, 25 Aug 2008) | 2 lines Add pure C trunc function implementations for platform which do not have it. as that is where the errror is coming from. Cheers, f

5 4