Mailman 3 February 2008 - NumPy-Discussion

non-contiguous array error
by Brad Malone Feb. 11, 2008

Feb. 11, 2008

Hi, I am receiving a "AttributeError: incompatible shape for a non-contiguous array" error. A quick illustration of the type of code that gives me the error is shown below: -------------------------------------------- from numpy import * list=[i for i in range(0,27)] c=array(list) c.shape=(3,3,3) d=fft.fftn(c) d.shape=(27) <error here> -------------------------------------------- I suppose this has something to do with the fact that the fourier transform of c has imaginary parts, which affects the way the information is stored in memory, and this messed up the call to .shape? Is there another way to do this, or will I need to rewrite this section of my code? Thanks for all you do, Brad

2 1

numerical noise for simple calcululations
by dmitrey Feb. 10, 2008

Feb. 10, 2008

hi all, I need a good estimation of noise value for simple calculations. I.e. when I calculate something like sin(15)+cos(80) I get a solution with precision, for example, 1e-11. I guess the precision depends on system arch, isn't it? So what's the best way to estimate the value? I guess here should be something like 10*numpy.machine_precision, isn't it? Regards, D.

2 2

_compiled_base.c
by Charles R Harris Feb. 10, 2008

Feb. 10, 2008

There is some ugly code in _compiled_base.c and what look to be duplicate functions. Do we really need it? Chuck

1 0

How not to screw up the interface.
by Charles R Harris Feb. 10, 2008

Feb. 10, 2008

Question, The current string compare doesn't work correctly with strings containing zeros, so I have replaced it in various spots with a working version. I think this should be added to the array_api to match up with PyArray_CompareUCS4. However, I notice that that the multiarray_api_order and array_api_order files are merged and the pointers in the api are at different offsets if I just add the new function to the end of the array_api_order.txt file. Is this a problem, and if so, where should I put it? Chuck

1 0

Getting started with numscons build system
by David Cournapeau Feb. 9, 2008

Feb. 9, 2008

Hi, Since numscons is now available on the trunk, more people can easily try it out. I put some basic instructions there, mainly how to get started and how to easily modify compilation flags, as well as a list of supported platforms http://scipy.org/scipy/numpy/wiki/Numcons I will add more when I will have more time. David

2 2

David's build_with_scons branch merged!
by Jarrod Millman Feb. 9, 2008

Feb. 9, 2008

Hello, In preparation for the upcoming NumPy 1.0.5 release, I just merged David Cournapeau's build_with_scons branch: http://projects.scipy.org/scipy/numpy/changeset/4773 The current build system using numpy.distutils is still the default. NumPy does not include numscons; this merge adds scons support to numpy.distutils, provides some scons scripts, and modifies the configuration of numpy/core. David has extensively tested these changes and I did a very quick sanity check to make sure I didn't completely break everything. Obviously, we will need to push back the 1.0.5 release date again to ensure that there is sufficient testing. So please test these changes and let us know if you have any problems (or successes). David has been putting in a considerable effort over the last several months in developing numscons. If you are interested in the advantages to Davids approach, please read the description here: http://projects.scipy.org/scipy/numpy/wiki/NumpyScons Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

3 2

svn 4777 fails to build with icc
by rex Feb. 9, 2008

Feb. 9, 2008

After doing the necessary fix for distutils, svn4774 builds with gcc, but trying to build with icc with: python setup.py config --compiler=intel build_clib --compiler=intel build_ext --compiler=intel install > inst.log fails with: Running from numpy source directory. /usr/local/src/numpy4777/numpy/distutils/system_info.py:1341: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) /usr/local/src/numpy4777/numpy/distutils/system_info.py:1350: UserWarning: Blas (http://www.netlib.org/blas/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [blas]) or by setting the BLAS environment variable. warnings.warn(BlasNotFoundError.__doc__) /usr/local/src/numpy4777/numpy/distutils/system_info.py:1353: UserWarning: Blas (http://www.netlib.org/blas/) sources not found. Directories to search for the sources can be specified in the numpy/distutils/site.cfg file (section [blas_src]) or by setting the BLAS_SRC environment variable. warnings.warn(BlasSrcNotFoundError.__doc__) /usr/local/src/numpy4777/numpy/distutils/system_info.py:1248: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) /usr/local/src/numpy4777/numpy/distutils/system_info.py:1259: UserWarning: Lapack (http://www.netlib.org/lapack/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [lapack]) or by setting the LAPACK environment variable. warnings.warn(LapackNotFoundError.__doc__) /usr/local/src/numpy4777/numpy/distutils/system_info.py:1262: UserWarning: Lapack (http://www.netlib.org/lapack/) sources not found. Directories to search for the sources can be specified in the numpy/distutils/site.cfg file (section [lapack_src]) or by setting the LAPACK_SRC environment variable. warnings.warn(LapackSrcNotFoundError.__doc__) site.cfg is: [DEFAULT] library_dirs=/opt/intel/mkl/10.0.1.014/lib/32 include_dirs=/opt/intel/mkl/10.0.1.014/include [mkl] library_dirs = /opt/intel/mkl/10.0.1.014/lib/32/ lapack_libs = mkl_lapack [lapack_src] libraries=mkl_lapack,mkl,guide OS is Debian Etch 4.0 I've built hundreds of programs from source over the years, including many versions of Numpy and Scipy. NOTHING has ever been as frustrating as these two. I often spend days trying to build a new release. Sometimes it works. More often, it does not, especially Scipy. I even switched from SUSE to Debian in the hope that it would help. It did not. I suggest that efforts to produce a product that ordinary 150 IQ mortals can install rather than add new features would grow the user population faster. For example, distutils has been broken for months for Intel MKL. I've posted 3x about it now. -rex -- I pray for a soroban.

2 1

svn 4777 distutils fails to find Intel MKL
by rex Feb. 9, 2008

Feb. 9, 2008

This is the 3rd time I have reported this problem and a fix. -rex ----- Forwarded message from rex <rex(a)nosyntax.com> ----- Date: Fri, 9 Nov 2007 11:16:17 -0800 From: rex <rex(a)nosyntax.com> To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> Subject: NumPy 1.04, MKL 10.0, & Intel 10.1 icc & ifort Message-ID: <20071109191617.GA17405(a)nosyntax.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Status: RO Content-Length: 4571 Lines: 126 Build was successful after a change in distutils. Core 2 Duo, Debian Etch-32, Python 2.5, icc 10.1, ifort 10.1, & mkl 10.0. MKL & the compilers were installed to their default locations: /opt/intel/mkl/, /opt/intel/cc/, /opt/intel/fc/ Installation will not interfere with earlier versions. NumPy site.cfg for MKL 10.0 ========================================== [DEFAULT] library_dirs=/opt/intel/mkl/10.0.011/lib/32 include_dirs=/opt/intel/mkl/10.0.011/include [mkl] libraries=mkl,guide [lapack_info] libraries=mkl_lapack,mkl,guide ========================================== Changes in distutils: ========================================================= In MKL 9.1 & 10.0, mkl_lapack32 & mkl_lapack64 no longer exist. They were replaced by /32/mkl_lapack and /64/mkl_lapack. As a result, numpy-1.04/numpy/distutils/system_info.py needs to be changed: #lapack_libs = self.get_libs('lapack_libs',['mkl_lapack32','mkl_lapack64']) lapack_libs = self.get_libs('lapack_libs',['mkl_lapack']) If the above change is not made numpy builds, but without using MKL. In numpy-1.04/numpy/distutils/ccompiler.py change: #cc_exe = 'icc' #works, but is suboptimal cc_exe = 'icc -msse3 -fast' #adjust to suit your cpu ========================================================= Running the command below (all one line) from the numpy-1.04 directory python setup.py config --compiler=intel build_clib --compiler=intel build_ext --compiler=intel install > inst.log Gave this inst.log: ===================================================== F2PY Version 2_4412 blas_opt_info: blas_mkl_info: FOUND: libraries = ['mkl', 'pthread', 'mkl', 'guide'] library_dirs = ['/opt/intel/mkl/10.0.011/lib/32'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/opt/intel/mkl/10.0.011/include'] FOUND: libraries = ['mkl', 'pthread', 'mkl', 'guide'] library_dirs = ['/opt/intel/mkl/10.0.011/lib/32'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/opt/intel/mkl/10.0.011/include'] lapack_opt_info: lapack_mkl_info: mkl_info: FOUND: libraries = ['mkl', 'pthread', 'mkl', 'guide'] library_dirs = ['/opt/intel/mkl/10.0.011/lib/32'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/opt/intel/mkl/10.0.011/include'] FOUND: libraries = ['mkl_lapack', 'mkl', 'pthread', 'mkl', 'guide', 'mkl', 'guide'] library_dirs = ['/opt/intel/mkl/10.0.011/lib/32'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/opt/intel/mkl/10.0.011/include'] FOUND: libraries = ['mkl_lapack', 'mkl', 'pthread', 'mkl', 'guide', 'mkl', 'guide'] library_dirs = ['/opt/intel/mkl/10.0.011/lib/32'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/opt/intel/mkl/10.0.011/include'] running config running build_clib running build_ext running build_src building py_modules sources creating build [...] =========================================================== For reference, here are the respective lib/32 files for MKL 9.1 and 10.0: c2d0:/opt/intel/mkl/9.1/lib/32# ls libguide.a libmkl_gfortran.a libmkl_ias.so libmkl_p3.so libmkl_p4.so libmkl_vml_def.so libmkl_vml_p4p.so libguide.so libmkl_gfortran.so libmkl_lapack.a libmkl_p4m.so libmkl.so libmkl_vml_p3.so libmkl_vml_p4.so libmkl_def.so libmkl_ia32.a libmkl_lapack.so libmkl_p4p.so libmkl_solver.a libmkl_vml_p4m.so libvml.so c2d0:/opt/intel/mkl/10.0.011/lib/32# ls libguide.a libmkl_cdft_core.a libmkl_intel.a libmkl_p4.so libmkl_vml_ia.so libguide.so libmkl_core.a libmkl_intel.so libmkl_scalapack.a libmkl_vml_p3.so libiomp5.a libmkl_core.so libmkl_intel_thread.a libmkl_scalapack_core.a libmkl_vml_p4m2.so libiomp5.so libmkl_def.so libmkl_intel_thread.so libmkl_sequential.a libmkl_vml_p4m.s o libmkl_blacs.a libmkl_gf.a libmkl_lapack.a libmkl_sequential.so libmkl_vml_p4p.so libmkl_blacs_intelmpi20.a libmkl_gf.so libmkl_lapack.so libmkl.so libmkl_vml_p4.so libmkl_blacs_intelmpi.a libmkl_gnu_thread.a libmkl_p3.so libmkl_solver.a libmkl_blacs_openmpi.a libmkl_gnu_thread.so libmkl_p4m.so libmkl_solver_sequential.a libmkl_cdft.a libmkl_ia32.a libmkl_p4p.so libmkl_vml_def.so Thanks to all who have helped me with earlier versions. -rex ----- End forwarded message -----

2 1

[f2py] Troubles building a module
by Fabrice Silva Feb. 9, 2008

Feb. 9, 2008

Reading the tutorial http://scipy.org/Cookbook/Theoretical_Ecology/Hastings_and_Powell I've tried to run the provided code. But compiling the fortran module with the line command given in the tuto, I've got the following traceback (you can see it with syntax highlighting at http://paste.debian.net/48759 ): fab@Portable-s2m:/tmp$ f2py -c -m hastings hastings.f90 running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src building extension "hastings" sources f2py options: [] f2py:> /tmp/tmptfNK80/src.linux-i686-2.4/hastingsmodule.c creating /tmp/tmptfNK80 creating /tmp/tmptfNK80/src.linux-i686-2.4 Reading fortran codes... Reading file 'hastings.f90' (format:free) Post-processing... Block: hastings Block: model Block: fweb Post-processing (stage 2)... Block: hastings Block: unknown_interface Block: model Block: fweb Building modules... Building module "hastings"... Constructing F90 module support for "model"... Variables: a1 a2 b1 b2 d2 d1 Constructing wrapper function "model.fweb"... yprime = fweb(y,t) Wrote C/API module "hastings" to file "/tmp/tmptfNK80/src.linux-i686-2.4/hastingsmodule.c" Traceback (most recent call last): File "/usr/bin/f2py", line 26, in ? main() File "/var/lib/python-support/python2.4/numpy/f2py/f2py2e.py", line 558, in main run_compile() File "/var/lib/python-support/python2.4/numpy/f2py/f2py2e.py", line 545, in run_compile setup(ext_modules = [ext]) File "/var/lib/python-support/python2.4/numpy/distutils/core.py", line 176, in setup return old_setup(**new_attr) File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/distutils/command/build.py", line 113, in run self.run_command(cmd_name) File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/var/lib/python-support/python2.4/numpy/distutils/command/build_src.py", line 130, in run self.build_sources() File "/var/lib/python-support/python2.4/numpy/distutils/command/build_src.py", line 147, in build_sources self.build_extension_sources(ext) File "/var/lib/python-support/python2.4/numpy/distutils/command/build_src.py", line 256, in build_extension_sources sources = self.f2py_sources(sources, ext) File "/var/lib/python-support/python2.4/numpy/distutils/command/build_src.py", line 511, in f2py_sources numpy.f2py.run_main(f2py_options + ['--lower', File "/var/lib/python-support/python2.4/numpy/f2py/f2py2e.py", line 367, in run_main ret=buildmodules(postlist) File "/var/lib/python-support/python2.4/numpy/f2py/f2py2e.py", line 319, in buildmodules dict_append(ret[mnames[i]],rules.buildmodule(modules[i],um)) File "/var/lib/python-support/python2.4/numpy/f2py/rules.py", line 1222, in buildmodule for l in '\n\n'.join(funcwrappers2)+'\n'.split('\n'): TypeError: cannot concatenate 'str' and 'list' objects

1 0

Re: [Numpy-discussion] Numpy-discussion Digest, Vol 17, Issue 15
by matthew yeomans Feb. 9, 2008

Feb. 9, 2008

Thanks I been trying to compile a code that uses random,pylab and numpy with py2exe the code of setup.py(compiles mycode.py into mycode.exe) follows #Start here from distutils.core import setup import py2exe import pylab import numpy import glob import scipy import random import os setup( console=['mycode.py'],options={'py2exe': {"skip_archive":1,'packages':['matplotlib','pytz']',}},data_files=[ matplotlib.get_py2exe_datafiles()]) #End here It works well for codes that uses pylab only. But It i add more modules i get trouble Is there any good books on how to use py2exe? On 2/7/08, numpy-discussion-request(a)scipy.org < numpy-discussion-request(a)scipy.org> wrote: > > Send Numpy-discussion mailing list submissions to > numpy-discussion(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://projects.scipy.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)scipy.org > > You can reach the person managing the list at > numpy-discussion-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Numpy-discussion digest..." > > > Today's Topics: > > 1. f2py compiled module not found by python (Chris) > 2. Re: f2py compiled module not found by python (Pearu Peterson) > 3. Re: Bug in numpy all() function (Robert Kern) > 4. Re: f2py compiled module not found by python (Chris) > 5. Re: random enhancement (Robert Kern) > 6. Re: Bug in numpy all() function (Anne Archibald) > 7. Re: Bug in numpy all() function (Robert Kern) > 8. Re: Numpy-discussion Digest, Vol 17, Issue 13 (Steven H. Rogers) > 9. isn't it a bug? (matrix multiplication) (dmitrey) > 10. Re: isn't it a bug? (matrix multiplication) (Alan G Isaac) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 6 Feb 2008 18:35:35 +0000 (UTC) > From: Chris <listservs(a)mac.com> > Subject: [Numpy-discussion] f2py compiled module not found by python > To: numpy-discussion(a)scipy.org > Message-ID: <loom.20080206T183501-435(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > > Hello, > > I'm trying to build a package on Linux (Ubuntu) that contains a fortran > module, built using f2py. However, despite the module building and > installing without error, python cannot seem to see it (see log below). > This works fine on Windows and Mac; the problem only seems to > happen on Linux: > > In [1]: import PyMC > ----------------------------------------------- > exceptions.ImportError Traceback (most > recent call last) > > /home/tianhuil/?ipython console> > > /usr/lib/python2.4/site-packages/PyMC/__init__.py > > /home/tianhuil/?string> > > /usr/lib/python2.4/site-packages/PyMC/MCMC.py > > ImportError: No module named flib > /usr/lib/python2.4/site-packages/PyMC/MCMC.py > > Notice that the module exists in the site-packages > directory: > > tianhuil <at> tianhuil:/usr/lib/python2.4/site-packages/PyMC$ ll > total 432 > drwxr-xr-x 2 root root 4096 2008-02-03 17:24 Backends > -rwxrwx--- 1 root root 195890 2008-02-03 17:24 flib.so > -rwxrwx--- 1 root root 259 2008-02-03 17:14 __init__.py > -rw-r--r-- 1 root root 473 2008-02-03 17:24 __init__.pyc > -rwxrwx--- 1 root root 10250 2008-02-03 17:14 Matplot.py > -rw-r--r-- 1 root root 7516 2008-02-03 17:24 Matplot.pyc > -rwxrwx--- 1 root root 98274 2008-02-03 17:14 MCMC.py > -rw-r--r-- 1 root root 79039 2008-02-03 17:24 MCMC.pyc > drwxr-xr-x 2 root root 4096 2008-02-03 17:24 Tests > -rwxrwx--- 1 root root 6631 2008-02-03 17:14 TimeSeries.py > -rw-r--r-- 1 root root 5043 2008-02-03 17:24 TimeSeries.pyc > > > > ------------------------------ > > Message: 2 > Date: Wed, 6 Feb 2008 20:58:07 +0200 (EET) > From: "Pearu Peterson" <pearu(a)cens.ioc.ee> > Subject: Re: [Numpy-discussion] f2py compiled module not found by > python > To: "Discussion of Numerical Python" <numpy-discussion(a)scipy.org> > Message-ID: <61111.85.166.27.136.1202324287.squirrel(a)cens.ioc.ee> > Content-Type: text/plain;charset=iso-8859-1 > > On Wed, February 6, 2008 8:35 pm, Chris wrote: > > Hello, > > > > I'm trying to build a package on Linux (Ubuntu) that contains a fortran > > module, built using f2py. However, despite the module building and > > installing without error, python cannot seem to see it (see log below). > > This works fine on Windows and Mac; the problem only seems to > > happen on Linux: > > Can you import flib module directly? That is, what happens if you > execute > cd .../PyMC > PYTHONPATH=. python -c 'import flib' > ? > Pearu > > > > > ------------------------------ > > Message: 3 > Date: Wed, 06 Feb 2008 14:03:20 -0600 > From: Robert Kern <robert.kern(a)gmail.com> > Subject: Re: [Numpy-discussion] Bug in numpy all() function > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: <47AA1288.6070700(a)gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Dan Goodman wrote: > > Hi all, > > > > I think this is a bug (I'm running Numpy 1.0.3.1): > > > >>>> from numpy import * > >>>> def f(x): return False > > > >>>> all(f(x) for x in range(10)) > > True > > > > I guess the all function doesn't know about generators? > > Yup. It works on arrays and things it can turn into arrays by calling the > C API > equivalent of numpy.asarray(). There's a ton of magic and special cases in > asarray() in order to interpret nested Python sequences as arrays. That > magic > works fairly well when we have sequences with known lengths; it fails > utterly > when given an arbitrary iterator of unknown length. So we punt. > Unfortunately, > what happens then is that asarray() sees an object that it can't interpret > as a > sequence to turn into a real array, so it makes a rank-0 array with the > iterator > object as the value. This evaluates to True. > > It's possible that asarray() should raise an exception for generators, but > it > would be a special case. We wouldn't be able to test for arbitrary > iterables. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > > ------------------------------ > > Message: 4 > Date: Wed, 6 Feb 2008 20:13:04 +0000 (UTC) > From: Chris <listservs(a)mac.com> > Subject: Re: [Numpy-discussion] f2py compiled module not found by > python > To: numpy-discussion(a)scipy.org > Message-ID: <loom.20080206T201205-452(a)post.gmane.org> > Content-Type: text/plain; charset=us-ascii > > Pearu Peterson <pearu <at> cens.ioc.ee> writes: > > > This works fine on Windows and Mac; the problem only seems to > > > happen on Linux: > > > > Can you import flib module directly? That is, what happens if you > > execute > > cd .../PyMC > > PYTHONPATH=. python -c 'import flib' > > It gives a "no module named flib" error. > > > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 06 Feb 2008 14:15:18 -0600 > From: Robert Kern <robert.kern(a)gmail.com> > Subject: Re: [Numpy-discussion] random enhancement > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: <47AA1556.8070708(a)gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Neal Becker wrote: > > One thing missing from random is a mechanism to share a single > underlying > > rng with other code that is not part of numpy.random. > > > > For example, I have code that generates distributions that expect a > mersenne > > twister (the shared, underlying rng) to be passed in as a constructor > > argument. > > > > numpy.random shares a single rng amongst it's own distributions, but I > don't > > see any way to share with others. > > Are you talking about C or Python? > > In Python, just instantiate numpy.random.RandomState() and pass it around. > All > of the functions in numpy.random are just aliases to the methods on a > global > RandomState() instance. > > C is a problem because the module is implemented in Pyrex, and RandomState > is an > extension type. I've tried working on exposing the C API as a PyCObject > like > numpy does, but it is incredibly tedious and, furthermore, is unlikely to > capture the higher-level methods like multivariate_normal(). I believe > that > Cython has a way to automatically expose the C API of a Pyrex/Cython > module, but > I haven't had the time to investigate it. > > For everything but the higher level methods like multivariate_normal(), we > might > be able to expose the pointer to the rk_state struct on the RandomState > object > as a PyCObject and punt on exposing the API. The C user can copy the > randomkit.[ch] and distributions.[ch] files into their own code and > operate on > the rk_state pointer with those functions. We may be thwarted by symbol > conflicts on some platforms, but I'm not sure. > > Contributions are, of course, welcome. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > > ------------------------------ > > Message: 6 > Date: Wed, 6 Feb 2008 15:18:38 -0500 > From: "Anne Archibald" <peridot.faceted(a)gmail.com> > Subject: Re: [Numpy-discussion] Bug in numpy all() function > To: "Discussion of Numerical Python" <numpy-discussion(a)scipy.org> > Message-ID: > <ce557a360802061218o2b7ffabblca5919d1a3b47bb7(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 06/02/2008, Robert Kern <robert.kern(a)gmail.com> wrote: > > > > I guess the all function doesn't know about generators? > > > > Yup. It works on arrays and things it can turn into arrays by calling > the C API > > equivalent of numpy.asarray(). There's a ton of magic and special cases > in > > asarray() in order to interpret nested Python sequences as arrays. That > magic > > works fairly well when we have sequences with known lengths; it fails > utterly > > when given an arbitrary iterator of unknown length. So we punt. > Unfortunately, > > what happens then is that asarray() sees an object that it can't > interpret as a > > sequence to turn into a real array, so it makes a rank-0 array with the > iterator > > object as the value. This evaluates to True. > > > > It's possible that asarray() should raise an exception for generators, > but it > > would be a special case. We wouldn't be able to test for arbitrary > iterables. > > Would it be possible for asarray() to pull out the first element from > the iterable, make an array out of it, then assume that all other > values out of the iterable will have the same shape (raising an error, > of course, when they aren't)? I guess this has high foot-shooting > potential, but is it that much worse than numpy's shpe-guessing > generally? > > It would be handy to be able to use an iterable to fill an array, so > that you'd never need to store the values in anything else first: > > a = N.array((sin(N.pi*x/n) for x in xrange(n))) > > Anne > > > ------------------------------ > > Message: 7 > Date: Wed, 06 Feb 2008 14:51:29 -0600 > From: Robert Kern <robert.kern(a)gmail.com> > Subject: Re: [Numpy-discussion] Bug in numpy all() function > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: <47AA1DD1.7090504(a)gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Anne Archibald wrote: > > On 06/02/2008, Robert Kern <robert.kern(a)gmail.com> wrote: > > > >>> I guess the all function doesn't know about generators? > >> Yup. It works on arrays and things it can turn into arrays by calling > the C API > >> equivalent of numpy.asarray(). There's a ton of magic and special cases > in > >> asarray() in order to interpret nested Python sequences as arrays. That > magic > >> works fairly well when we have sequences with known lengths; it fails > utterly > >> when given an arbitrary iterator of unknown length. So we punt. > Unfortunately, > >> what happens then is that asarray() sees an object that it can't > interpret as a > >> sequence to turn into a real array, so it makes a rank-0 array with the > iterator > >> object as the value. This evaluates to True. > >> > >> It's possible that asarray() should raise an exception for generators, > but it > >> would be a special case. We wouldn't be able to test for arbitrary > iterables. > > > > Would it be possible for asarray() to pull out the first element from > > the iterable, make an array out of it, then assume that all other > > values out of the iterable will have the same shape (raising an error, > > of course, when they aren't)? I guess this has high foot-shooting > > potential, but is it that much worse than numpy's shpe-guessing > > generally? > > I'm skeptical. Personally, it comes down to this: if you provide code that > implements this safely and efficiently without making a confusing API, I'm > more > than happy to consider it for inclusion. But I'm not going to spend time > trying > to write the code. > > > It would be handy to be able to use an iterable to fill an array, so > > that you'd never need to store the values in anything else first: > > > > a = N.array((sin(N.pi*x/n) for x in xrange(n))) > > If n is large enough that storage matters, > > a = N.sin(N.linspace(0, np.pi, n)) > > is always faster, more memory efficient, and more readable. Remember that > the > array will have to be dynamically resized as we go through the iterator. > The > memory movement is going to wipe out much of the benefit of having an > iterator > in the first place. > > For 1D arrays, remember that we have numpy.fromiter() already, so we can > test this. > > > In [39]: import numpy as np > > In [40]: from math import sin > > In [41]: n = 10 > > In [42]: %timeit np.fromiter((sin(np.pi*x/n) for x in xrange(n)), float) > 100000 loops, best of 3: 11.5 ?s per loop > > In [43]: %timeit np.sin(np.linspace(0, np.pi, n)) > 10000 loops, best of 3: 26.1 ?s per loop > > In [44]: n = 100 > > In [45]: %timeit np.fromiter((sin(np.pi*x/n) for x in xrange(n)), float) > 10000 loops, best of 3: 84 ?s per loop > > In [46]: %timeit np.sin(np.linspace(0, np.pi, n)) > 10000 loops, best of 3: 32.3 ?s per loop > > In [47]: n = 1000 > > In [48]: %timeit np.fromiter((sin(np.pi*x/n) for x in xrange(n)), float) > 1000 loops, best of 3: 794 ?s per loop > > In [49]: %timeit np.sin(np.linspace(0, np.pi, n)) > 10000 loops, best of 3: 91.8 ?s per loop > > > So, for n=10, the generator wins, but is n=10 really the case that you > want to > use a generator for? > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > > ------------------------------ > > Message: 8 > Date: Wed, 06 Feb 2008 18:51:10 -0700 > From: "Steven H. Rogers" <steve(a)shrogers.com> > Subject: Re: [Numpy-discussion] Numpy-discussion Digest, Vol 17, Issue > 13 > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: <47AA640E.2030006(a)shrogers.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > matthew yeomans wrote: > > Is it possible to compile numpy with py2exe? > > > > Matthew Yeomans > > > If you mean to generate a Windows executable containing py2exe, the > answer is yes. The process isn't what is usually thought of as > compilation as it just packages the Python interpreter, your application > code, and required libraries for easy distribution. > > # Steve > > > ------------------------------ > > Message: 9 > Date: Thu, 07 Feb 2008 15:41:41 +0200 > From: dmitrey <dmitrey.kroshko(a)scipy.org> > Subject: [Numpy-discussion] isn't it a bug? (matrix multiplication) > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: <47AB0A95.8050809(a)scipy.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > from numpy import array > a = array((1.0, 2.0)) > > b = c = 15 > b = b*a#ok > c *= a#ok > > d = array(15) > e = array(15) > d = d*a#this works ok > e *= a#this intended to be same as prev line, but yields error: > Traceback (innermost last): > File "<stdin>", line 1, in <module> > ValueError: invalid return array shape > > > ------------------------------ > > Message: 10 > Date: Thu, 7 Feb 2008 09:10:59 -0500 > From: Alan G Isaac <aisaac(a)american.edu> > Subject: Re: [Numpy-discussion] isn't it a bug? (matrix > multiplication) > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: <Mahogany-0.67.0-664-20080207-091059.00(a)american.edu> > Content-Type: TEXT/PLAIN; CHARSET=UTF-8 > > On Thu, 07 Feb 2008, dmitrey apparently wrote: > > a = array((1.0, 2.0)) > > e = array(15) > > e *= a # ... yields error: > > You are trying to stuff in two values where > you have only allocated space for 1. > > Cheers, > Alan Isaac > > > > > > ------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion(a)scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > > > End of Numpy-discussion Digest, Vol 17, Issue 15 > ************************************************ > -- Kollox Ghal Xejn

3 2