[Numpy-discussion] Bug in numpy all() function
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? Dan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy and C++ integration...
How does Instant compare to scipy.weave !? -Sebastian Haase On Feb 5, 2008 11:26 PM, Glen W. Mabey [EMAIL PROTECTED] wrote: On Tue, Feb 05, 2008 at 12:16:02PM -0600, Kent-Andre Mardal wrote: We have created a small Python module Instant (www.fenics.org/instant) on top of SWIG, which makes integration of C/C++ and NumPy arrays easy in some cases. Hello, Thank you for posting about instant. I think it looks like a great idea and hope to try it out soon. I noticed that you are distributing under the GPL. Would you consider releasing it under a more permissive license? Some rationale is given here: http://www.scipy.org/License_Compatibility Best Regards, Glen mabey ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [ANN] Blas-LAPACK superpack, 2nd alpha
Hi, I have finished a second alpha of the BLAS/LAPACK superpack for windows: http://www.ar.media.kyoto-u.ac.jp/members/david/archives/blas-lapack-superpack.exe (~ 9 Mb). Changes from first alpha - Both SSE3 and SSE2 are supported. - custom installation possible: you can choose to install .a, .dll, .def and .lib for any target, atlas or netlib. The super pack is an installer which by default install the most optimized blas/lapack possible to compile numpy/scipy with. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] random enhancement
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. Ideally, I believe this is the preferred design: rng1 = mersenne_twister (seed = 0) poisson (rng1, lambda=4) uniform (rng1, min=0, max=4) It would be best if numpy.random adopted this approach. Since I understand that's not likely, the alternative is for numpy.random to add some API that would allow direct access to the shared rng object. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy and C++ integration...
On Wed, Feb 06, 2008 at 03:23:43AM -0600, Kent-Andre Mardal wrote: No problem, it is now under BSD. OK? Perfect. Thank you. Glen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy all() function
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? That's likely the problem. However, as of Python 2.5, there's a built in function that will do what you want. However, you would mask that builtin with the from numpy import *. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy-discussion Digest, Vol 17, Issue 13
Is it possible to compile numpy with py2exe?
Matthew Yeomans
On 2/6/08, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Send Numpy-discussion mailing list submissions to
numpy-discussion@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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of Numpy-discussion digest...
Today's Topics:
1. Re: Problem accessing elements of an array of dtype=O from
C (Travis E. Oliphant)
2. [Bug] important bug in method sum ([EMAIL PROTECTED])
3. Re: [Bug] important bug in method sum ([EMAIL PROTECTED])
4. Re: [Bug] important bug in method sum (Keith Goodman)
5. Re: [Bug] important bug in method sum (Charles R Harris)
6. Bug in numpy all() function (Dan Goodman)
7. Re: Numpy and C++ integration... (Sebastian Haase)
8. [ANN] Blas-LAPACK superpack, 2nd alpha (David Cournapeau)
9. random enhancement (Neal Becker)
10. Re: Numpy and C++ integration... (Glen W. Mabey)
11. Re: Bug in numpy all() function (Ryan May)
--
Message: 1
Date: Tue, 05 Feb 2008 18:32:37 -0600
From: Travis E. Oliphant [EMAIL PROTECTED]
Subject: Re: [Numpy-discussion] Problem accessing elements of an array
of dtype=O from C
To: Discussion of Numerical Python numpy-discussion@scipy.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Chris Ball wrote:
Hi,
I'm having some trouble accessing elements in an array of dtype=O
from C code; I hope someone on the list could give me some advice
(because I might be doing something stupid).
I have an array of simple objects, created as follows:
class CF(object):
def __init__(self,num=0.0):
self.num=num
from numpy import array
objs = array([[CF(0.0),CF(0.1),CF(0.2)],
[CF(1.0),CF(1.1),CF(1.2)]],dtype=object)
I'd like to loop through this array and access the 'num' attribute of
each CF object - but using C.
I have a C function (based on an example in the numpy book - 'Basic
Iteration', page 312):
double loop(PyObject* a_){
PyArrayIterObject *iter;
iter = (PyArrayIterObject *)PyArray_IterNew(a_);
while (iter-index iter-size) {
PyObject *cf = (PyObject *)(iter-dataptr);
PyObject *num_obj = PyObject_GetAttrString(cf,num);
PyArray_ITER_NEXT(iter);
}
return 0.0;
}
The problem here is that iter-dataptr should be re-cast to a PyObject
** because what is contained at the memory location is a *pointer* to
the PyObject. Thus, you have to de-reference iter-dataptr to get the
PyObject * that you want:
PyObject **cf = (PyObject **)PyArray_ITER_DATA(iter);
PyObject *num_obj = PyObject_GetAttrString(*cf, num);
PyArray_ITER_NEXT(iter);
should do what you want.
-Travis O.
--
Message: 2
Date: Tue, 5 Feb 2008 14:58:40 -0500
From: [EMAIL PROTECTED]
Subject: [Numpy-discussion] [Bug] important bug in method sum
To: Discussion of Numerical Python numpy-discussion@scipy.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Hello,
when doing some test I saw a very important bug in numpy (at least on the
svn
version and 1.0.3 (ubuntu package)).
I'm using a svn version of numpy:
In [31]: numpy.__version__
Out[31]: '1.0.5.dev4767'
The problem is for an array larger than 256*256 the sum is going crazy.
In [45]: numpy.arange(256*256)
Out[45]: array([0, 1, 2, ..., 65533, 65534, 65535])
In [46]: numpy.arange(256*256).sum()
Out[46]: 2147450880
In [47]: numpy.arange(257*257)
Out[47]: array([0, 1, 2, ..., 66046, 66047, 66048])
In [48]: numpy.arange(257*257).sum()
Out[48]: -2113765120
import numpy
numpy.arange(256*256).sum()
2147450880
numpy.arange(257*257).sum()
-2113765120
numpy.__version__
'1.0.3'
Sorry for this bad news.
N.
ps: my system is an ubuntu linux 32
--
Message: 3
Date: Tue, 5 Feb 2008 15:20:09 -0500
From: [EMAIL PROTECTED]
Subject: Re: [Numpy-discussion] [Bug] important bug in method sum
To: Discussion of Numerical Python numpy-discussion@scipy.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Sorry its not really a bug. I understood why . It's an integer and I'm
doing
an overflow. Perhaps an error message can be printed or an automatic
change
(with a warning) can be done. I think that I prefer to loose the type but
keep the value correct.
N.
--
Message: 4
Date: Tue, 5 Feb 2008 20:27:46 -0800
From: Keith Goodman [EMAIL PROTECTED]
[Numpy-discussion] f2py compiled module not found by python
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 root259 2008-02-03 17:14 __init__.py -rw-r--r-- 1 root root473 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy all() function
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py compiled module not found by python
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. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random enhancement
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy all() function
On 06/02/2008, Robert Kern [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy all() function
Anne Archibald wrote: On 06/02/2008, Robert Kern [EMAIL PROTECTED] 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) 10 loops, best of 3: 11.5 µs per loop In [43]: %timeit np.sin(np.linspace(0, np.pi, n)) 1 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) 1 loops, best of 3: 84 µs per loop In [46]: %timeit np.sin(np.linspace(0, np.pi, n)) 1 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)) 1 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy-discussion Digest, Vol 17, Issue 13
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
