[Numpy-discussion] Python-to-C compiler : very prelim alpha

Hi. I had announced a project called Spyke earlier on this list. The name has been changed to unPython. unPython is a Python to C compiler. The homepage is at www.cs.ualberta.ca/~garg1/unpython/index.php A very prelim release is available for download. You can also download the manual on the downlo

Re: [Numpy-discussion] List of function-like things with an 'out' parameter

On Wed, May 28, 2008 at 5:46 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 7:26 PM, Anne Archibald > <[EMAIL PROTECTED]> wrote: > > One noticeable absence is all the ufuncs. (Partly this is because it's > > not actually called "out", or on fact anything at all; it's just t

Re: [Numpy-discussion] Is this a bug?

On Wed, May 28, 2008 at 7:52 PM, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Anne Archibald wrote: >> 2008/5/27 Robert Kern <[EMAIL PROTECTED]>: >> >>> Can we make it so that dtype('c') is preserved instead of displaying >>> '|S1'? It does not behave the same as dtype('|S1') although it >>> com

Re: [Numpy-discussion] What does "Ignoring attempt to set 'name' (from ... " mean ?

On Wed, May 28, 2008 at 8:03 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 4:02 AM, Robert Kern <[EMAIL PROTECTED]> wrote: >> >> Please provide the full error message with some context. > > For example, in scipy/sparse: python setup.py config gives > > Appending sparse.l

Re: [Numpy-discussion] What does "Ignoring attempt to set 'name' (from ... " mean ?

On Thu, May 29, 2008 at 4:02 AM, Robert Kern <[EMAIL PROTECTED]> wrote: > > Please provide the full error message with some context. > For example, in scipy/sparse: python setup.py config gives Appending sparse.linalg.isolve configuration to sparse.linalg Ignoring attempt to set 'name' (from 'spa

Re: [Numpy-discussion] Is this a bug?

Anne Archibald wrote: > 2008/5/27 Robert Kern <[EMAIL PROTECTED]>: > > >> Can we make it so that dtype('c') is preserved instead of displaying >> '|S1'? It does not behave the same as dtype('|S1') although it >> compares equal to it. >> > > It seems alarming to me that they should compare e

Re: [Numpy-discussion] List of function-like things with an 'out' parameter

On Wed, May 28, 2008 at 7:26 PM, Anne Archibald <[EMAIL PROTECTED]> wrote: > One noticeable absence is all the ufuncs. (Partly this is because it's > not actually called "out", or on fact anything at all; it's just the > last parameter if there are enough.) You might also check things like > object

Re: [Numpy-discussion] Is this a bug?

2008/5/27 Robert Kern <[EMAIL PROTECTED]>: > Can we make it so that dtype('c') is preserved instead of displaying > '|S1'? It does not behave the same as dtype('|S1') although it > compares equal to it. It seems alarming to me that they should compare equal but behave differently. Is it possible

Re: [Numpy-discussion] List of function-like things with an 'out' parameter

2008/5/28 Alan McIntyre <[EMAIL PROTECTED]>: > On Wed, May 28, 2008 at 3:34 PM, Charles R Harris >> I wonder if this > is something that ought to be looked at for all >>> functions with an "out" parameter? ndarray.compress also had problems >>> with array type mismatch (#789); I can't imagine that

[Numpy-discussion] List of function-like things with an 'out' parameter

On Wed, May 28, 2008 at 3:34 PM, Charles R Harris >> I wonder if this is something that ought to be looked at for all >> functions with an "out" parameter? ndarray.compress also had problems >> with array type mismatch (#789); I can't imagine that it's safe to >> assume only these two functions we

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 5:10 PM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > Yes, we have mechanisms in place to do that. I haven't merged for a > while, because I am hoping that we can move the docstrings over to the > new (web application) system soon. If that doesn't happen, I will > prob

Re: [Numpy-discussion] segmentation fault

Hi Alan 2008/5/28 Alan McIntyre <[EMAIL PROTECTED]>: > On Wed, May 28, 2008 at 4:19 PM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: >> A reminder: if docstrings need to be updated, it is really easy to do: >> >> http://sd-2116.dedibox.fr/doc/Docstrings/ >> >> Pauli has been hard at work at w

Re: [Numpy-discussion] segmentation fault

Charles R Harris wrote: > > > On Wed, May 28, 2008 at 11:22 AM, Stéfan van der Walt > <[EMAIL PROTECTED] > wrote: > > 2008/5/28 Charles R Harris <[EMAIL PROTECTED] > >: > > It's shape related. > > > > In [7]: x = numpy.random.

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 1:55 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 4:19 PM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: >> A reminder: if docstrings need to be updated, it is really easy to do: >> >> http://sd-2116.dedibox.fr/doc/Docstrings/ >> >> Pauli has be

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 4:19 PM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > A reminder: if docstrings need to be updated, it is really easy to do: > > http://sd-2116.dedibox.fr/doc/Docstrings/ > > Pauli has been hard at work at writing a Django app to replace the > current wiki. It has prope

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 1:16 PM, Keith Goodman <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 1:06 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote: >> On Wed, May 28, 2008 at 3:34 PM, Charles R Harris >> <[EMAIL PROTECTED]> wrote: I wonder if this is something that ought to be looked at for

Re: [Numpy-discussion] segmentation fault

2008/5/28 Alan McIntyre <[EMAIL PROTECTED]>: > On Wed, May 28, 2008 at 3:34 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: >>> I wonder if this is something that ought to be looked at for all >>> functions with an "out" parameter? ndarray.compress also had problems >>> with array type mismatch

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 1:06 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 3:34 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: >>> I wonder if this is something that ought to be looked at for all >>> functions with an "out" parameter? ndarray.compress also had problems

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 3:34 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: >> I wonder if this is something that ought to be looked at for all >> functions with an "out" parameter? ndarray.compress also had problems >> with array type mismatch (#789); I can't imagine that it's safe to >> assume

Re: [Numpy-discussion] proposal on ufunc shift operators.

2008/5/28 Charles R Harris <[EMAIL PROTECTED]>: > Hi All, > > Currently we have: > > In [2]: ones(1,dtype=int8) << ones(1,dtype=uint8) > Out[2]: array([2], dtype=int16) > > In [4]: ones(1,dtype=int64) << ones(1,dtype=uint64) > Out[4]: array([2], dtype=object) > > Note the increased size in the firs

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 1:17 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 1:37 PM, Charles R Harris > <[EMAIL PROTECTED]> wrote: > > I think the bug is not raising an error on shape mismatch, the assumption > on > > the first index follows from that. For the out=x paramet

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 1:37 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > I think the bug is not raising an error on shape mismatch, the assumption on > the first index follows from that. For the out=x parameter, I propose the > rules: > > 1) x must have the shape of the expected output (1D in

Re: [Numpy-discussion] What does "Ignoring attempt to set 'name' (from ... " mean ?

On Wed, May 28, 2008 at 4:14 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Hi, > >I encounter this message when I am building a subtree of scipy (for > example scipy/sparsetools). What does it mean exactly ? Is the setup.py > doing something wrong ? Please provide the full error message wi

[Numpy-discussion] proposal on ufunc shift operators.

Hi All, Currently we have: In [2]: ones(1,dtype=int8) << ones(1,dtype=uint8) Out[2]: array([2], dtype=int16) In [4]: ones(1,dtype=int64) << ones(1,dtype=uint64) Out[4]: array([2], dtype=object) Note the increased size in the first case and the return of a Python long integer object in the secon

[Numpy-discussion] proposal on ufunc bit ops

Hi All, I would like to propose that the bit_ops preserve the length of the relevant types. Currently we have: In [1]: ones(1,dtype=int8) & ones(1,dtype=uint8) Out[1]: array([1], dtype=int16) In [3]: ones(1,dtype=int64) & ones(1,dtype=uint64) Out[3]: array([1], dtype=object) Note the increased

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 11:22 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > 2008/5/28 Charles R Harris <[EMAIL PROTECTED]>: > > It's shape related. > > > > In [7]: x = numpy.random.rand(5,2) > > > > In [8]: y = ones((5,2)) > > > > In [9]: x.cumsum(None,out=y) > > Out[9]: > > array([[ 0.7694

Re: [Numpy-discussion] segmentation fault

2008/5/28 Stéfan van der Walt <[EMAIL PROTECTED]>: > 2008/5/28 Charles R Harris <[EMAIL PROTECTED]>: >> It's shape related. >> >> In [7]: x = numpy.random.rand(5,2) >> >> In [8]: y = ones((5,2)) >> >> In [9]: x.cumsum(None,out=y) >> Out[9]: >> array([[ 0.76943981, 1.], >>[ 1.126784

Re: [Numpy-discussion] ANN: NumPy 1.1.0

Jarrod, 2008/5/28 Jarrod Millman <[EMAIL PROTECTED]>: > I'm pleased to announce the release of NumPy 1.1.0. Thank you for coordinating the birth of this behemoth release! We appreciate all the time and effort you put into it. Regards Stéfan ___ Numpy-

Re: [Numpy-discussion] segmentation fault

2008/5/28 Charles R Harris <[EMAIL PROTECTED]>: > It's shape related. > > In [7]: x = numpy.random.rand(5,2) > > In [8]: y = ones((5,2)) > > In [9]: x.cumsum(None,out=y) > Out[9]: > array([[ 0.76943981, 1.], >[ 1.12678411, 1.], >[ 1.69498328, 1.], >

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 10:39 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > 2008/5/28 Hoyt Koepke <[EMAIL PROTECTED]>: > > In my experience tracking down these sorts of things, if the effect is > > delayed and detected by glibc, it almost always means that a few bytes > > beyond the end of

[Numpy-discussion] ANN: NumPy 1.1.0

I'm pleased to announce the release of NumPy 1.1.0. NumPy is the fundamental package needed for scientific computing with Python. It contains: * a powerful N-dimensional array object * sophisticated (broadcasting) functions * basic linear algebra functions * basic Fourier transforms *

Re: [Numpy-discussion] segmentation fault

2008/5/28 Hoyt Koepke <[EMAIL PROTECTED]>: > In my experience tracking down these sorts of things, if the effect is > delayed and detected by glibc, it almost always means that a few bytes > beyond the end of the data part of an array have been overwritten. > This causes glibc's memory management s

Re: [Numpy-discussion] segmentation fault

In my experience tracking down these sorts of things, if the effect is delayed and detected by glibc, it almost always means that a few bytes beyond the end of the data part of an array have been overwritten. This causes glibc's memory management stuff to crash later on when the object is deallocat

Re: [Numpy-discussion] segmentation fault

ke, 2008-05-28 kello 10:59 -0400, Scott Ransom kirjoitti: > Hmmm. Interesting. I'm on a 64-bit Debian Unstable system with numpy > 1.0.4 and python 2.5.2 and I don't get this: > > In [1]: import numpy as np > > In [2]: np.__version__ > Out[2]: '1.0.4' > > In [3]: def fn(): >...: x = n

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 7:30 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > Does anyone else get this seg fault? > >>> def fn(): >x = np.random.rand(5,2) >x.cumsum(None, out=x) >return x > : >>> fn() > *** glibc detected *** /usr/bin/python: double free or corruption > (out): 0x08

Re: [Numpy-discussion] segmentation fault

On Wed, 28 May 2008 11:07:16 -0400 Scott Ransom <[EMAIL PROTECTED]> wrote: > > On Wednesday 28 May 2008 10:51:20 am Alan McIntyre >wrote: >> On Wed, May 28, 2008 at 10:30 AM, Keith Goodman >><[EMAIL PROTECTED]> > wrote: >> > Does anyone else get this seg fault? >> > >> >>> def fn(): >> > >> >

Re: [Numpy-discussion] segmentation fault

On Wednesday 28 May 2008 10:51:20 am Alan McIntyre wrote: > On Wed, May 28, 2008 at 10:30 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > > Does anyone else get this seg fault? > > > >>> def fn(): > > > >x = np.random.rand(5,2) > >x.cumsum(None, out=x) > >return x > > > > : > >>>

Re: [Numpy-discussion] segmentation fault

Hmmm. Interesting. I'm on a 64-bit Debian Unstable system with numpy 1.0.4 and python 2.5.2 and I don't get this: In [1]: import numpy as np In [2]: np.__version__ Out[2]: '1.0.4' In [3]: def fn(): ...: x = np.random.rand(5,2) ...: x.cumsum(None, out=x) ...: return x .

Re: [Numpy-discussion] segmentation fault

2008/5/28 Keith Goodman <[EMAIL PROTECTED]>: > Does anyone else get this seg fault? > >>> def fn(): >x = np.random.rand(5,2) >x.cumsum(None, out=x) >return x > : >>> fn() > *** glibc detected *** /usr/bin/python: double free or corruption > (out): 0x08212dc8 *** > > I'm running 1.

Re: [Numpy-discussion] segmentation fault

On Wed, May 28, 2008 at 10:30 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > Does anyone else get this seg fault? > >>> def fn(): >x = np.random.rand(5,2) >x.cumsum(None, out=x) >return x > : >>> fn() > *** glibc detected *** /usr/bin/python: double free or corruption > (out): 0x0

Re: [Numpy-discussion] segmentation fault

On 28 May 2008, at 16:30, Keith Goodman wrote: > Does anyone else get this seg fault? > >>> def fn(): >x = np.random.rand(5,2) >x.cumsum(None, out=x) >return x > : >>> fn() > *** glibc detected *** /usr/bin/python: double free or corruption > (out): 0x08212dc8 *** > > I'm runnin

Re: [Numpy-discussion] logical masking, wrong length mask

2008/5/28 John Hunter <[EMAIL PROTECTED]>: > I initially thought line 24 below should raise an error, or coerce > True to 1 and False to 0 and give me either y[0] or y[1] accordingly, > but neither appear to be happening. Instead, I appear to be getting > y[:len(mask)][mask] This "feature" looks

[Numpy-discussion] segmentation fault

Does anyone else get this seg fault? >> def fn(): x = np.random.rand(5,2) x.cumsum(None, out=x) return x : >> fn() *** glibc detected *** /usr/bin/python: double free or corruption (out): 0x08212dc8 *** I'm running 1.0.4 from Debian Lenny with python 2.5.2 compiled with gcc 4.2

[Numpy-discussion] logical masking, wrong length mask

I just spent a while tracking down a bug in my code, and found out the problem was numpy was letting me get away with using a logical mask of smaller size than the array it was masking. In [19]: x = np.random.rand(10) In [20]: x Out[20]: array([ 0.72253623, 0.8412243 , 0.12835194, 0.01

Re: [Numpy-discussion] Binary ufuncs: minimum

On Wed, May 28, 2008 at 1:08 AM, Chris.Barker <[EMAIL PROTECTED]> wrote: > Keith Goodman wrote: > >> Interestingly, MATLAB (v7.5.0) takes a different approach: > >> ans = > >> 1271 > -A > >> ans = > >> 127 -1 > > can anyone explain that? -- just curious. > > Charles R Harris wrote: >

[Numpy-discussion] What does "Ignoring attempt to set 'name' (from ... " mean ?

Hi, I encounter this message when I am building a subtree of scipy (for example scipy/sparsetools). What does it mean exactly ? Is the setup.py doing something wrong ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy

Re: [Numpy-discussion] Binary ufuncs: minimum

Keith Goodman wrote: >> Interestingly, MATLAB (v7.5.0) takes a different approach: >> ans = >> 1271 -A >> ans = >> 127 -1 can anyone explain that? -- just curious. Charles R Harris wrote: > We could simply define the range of int8 as [-127,127], but that is > somewhat problematical