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 also.
That
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
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:
We could simply define the
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,
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
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
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 running 1.0.4 from
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.0.4 from Debian
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
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
:
fn()
*** glibc
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():
x = np.random.rand(5,2)
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): 0x08212dc8 ***
I
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 =
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
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 stuff
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
*
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 the data
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.],
[
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
___
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.12678411, 1.],
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.76943981, 1.],
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
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 second.
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 this
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 parameter, I
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 first case and the
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 with
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
with array
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 all
functions
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 writing a Django
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
probably
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 were doing
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 it's safe to
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 to
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
objects
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 equal but
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.linalg.isolve
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
compares equal to
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 the
last
39 matches
Mail list logo
