David Cournapeau cournape at gmail.com writes:
I forgot: another thing which would be helpful since you can reproduce
the bug would be to build a debug version of numpy (python setup.py
build_ext -g), and reproduce the bug under gdb to have a traceback.
David
Ok I have rebuilt
Steven Coutts stevec at couttsnet.com writes:
Ok I have rebuilt numpy-1.3.0 with debugging, and it segfaults as soon as I
import numpy in python2.5
Backtrace -:
http://pastebin.com/d27fbd2a5
Regards
Sorry ignore this, I cleanded out numpy properly, re-installed 1.3.0 and the
tests
Steven Coutts wrote:
Sorry ignore this, I cleanded out numpy properly, re-installed 1.3.0 and the
tests are all running now.
Do you mean that if you build with debug information, everything else
being equal, you cannot reproduce the crashes ?
cheers,
David
David Cournapeau wrote:
Do you mean that if you build with debug information, everything else
being equal, you cannot reproduce the crashes ?
cheers,
David
That does appear to be the case, SciPy 1.7.0 is now also running fine.
Regards
On Mon, Aug 3, 2009 at 6:32 PM, Steven Couttsste...@couttsnet.com wrote:
David Cournapeau wrote:
Do you mean that if you build with debug information, everything else
being equal, you cannot reproduce the crashes ?
cheers,
David
That does appear to be the case, SciPy 1.7.0 is now also
While working on GSoC stuff I came across this weird performance
behavior for sine and cosine -- using float32 is way slower than
float64. On a 2ghz opteron:
sin float32 1.12447786331
sin float64 0.133481025696
cos float32 1.14155912399
cos float64 0.131420135498
The times are in seconds,
Gael Varoquaux wrote:
On Sun, Jul 05, 2009 at 02:47:18PM -0400, Andrew Friedley wrote:
Stéfan van der Walt wrote:
2009/7/5 Andrew Friedley afrie...@indiana.edu:
I found the check that does the type 'upcasting' in
umath_ufunc_object.inc around line 3072 (NumPy 1.3.0). Turns out all I
need to
On Mon, Aug 3, 2009 at 10:32 PM, Andrew Friedleyafrie...@indiana.edu wrote:
While working on GSoC stuff I came across this weird performance behavior
for sine and cosine -- using float32 is way slower than float64. On a 2ghz
opteron:
sin float32 1.12447786331
sin float64 0.133481025696
cos
Hi Andrew,
%timeit is an Ipython magic command that uses the timeit module,
see
http://ipython.scipy.org/doc/stable/html/interactive/reference.html?highlight=timeit
for more information about how to use it. So you were right to suppose
that it is not a normal Python.
Thanks for the quick responses.
David Cournapeau wrote:
On Mon, Aug 3, 2009 at 10:32 PM, Andrew Friedleyafrie...@indiana.edu wrote:
While working on GSoC stuff I came across this weird performance behavior
for sine and cosine -- using float32 is way slower than float64. On a 2ghz
opteron:
Emmanuelle Gouillart wrote:
Hi Andrew,
%timeit is an Ipython magic command that uses the timeit module,
see
http://ipython.scipy.org/doc/stable/html/interactive/reference.html?highlight=timeit
for more information about how to use it. So you were right to suppose
that it is not
import numpy as np
a = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float32)
b = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float64)
%timeit -n 10 np.sin(a)
10 loops, best of 3: 8.67 ms per loop
%timeit -n 10 np.sin(b)
10 loops, best of 3: 9.29 ms per loop
OK, I'm
On Mon, Aug 3, 2009 at 10:21 AM, Emmanuelle
Gouillartemmanuelle.gouill...@normalesup.org wrote:
import numpy as np
a = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float32)
b = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float64)
%timeit -n 10 np.sin(a)
10 loops, best of
On Mon, Aug 3, 2009 at 11:08 PM, Andrew Friedleyafrie...@indiana.edu wrote:
Thanks for the quick responses.
David Cournapeau wrote:
On Mon, Aug 3, 2009 at 10:32 PM, Andrew Friedleyafrie...@indiana.edu wrote:
While working on GSoC stuff I came across this weird performance behavior
for sine
On Mon, Aug 3, 2009 at 7:21 AM, Emmanuelle
Gouillartemmanuelle.gouill...@normalesup.org wrote:
import numpy as np
a = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float32)
b = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float64)
%timeit -n 10 np.sin(a)
10 loops, best of 3:
I get similar results as the OP:
In [1]: import numpy as np
In [2]: a = np.arange(0.0, 1000, (2*3.14159) / 1000, dtype=np.float32)
In [3]: b = np.arange(0.0, 1000, (2*3.14159) / 1000, dtype=np.float64)
In [4]: %timeit -n 10 np.sin(a)
10 loops, best of 3: 63.8 ms per loop
In [5]: %timeit -n
On Mon, Aug 03, 2009 at 08:17:21AM -0700, Keith Goodman wrote:
On Mon, Aug 3, 2009 at 7:21 AM, Emmanuelle
Gouillartemmanuelle.gouill...@normalesup.org wrote:
import numpy as np
a = np.arange(0.0, 1000, (2 * 3.14159) / 1000, dtype=np.float32)
b = np.arange(0.0, 1000, (2 * 3.14159) /
On Mon, Aug 3, 2009 at 10:23 AM, Chris Colbert sccolb...@gmail.com wrote:
I get similar results as the OP:
In [1]: import numpy as np
In [2]: a = np.arange(0.0, 1000, (2*3.14159) / 1000, dtype=np.float32)
In [3]: b = np.arange(0.0, 1000, (2*3.14159) / 1000, dtype=np.float64)
In [4]:
David Cournapeau wrote:
David Cournapeau wrote:
On Mon, Aug 3, 2009 at 10:32 PM, Andrew Friedleyafrie...@indiana.edu
wrote:
While working on GSoC stuff I came across this weird performance behavior
for sine and cosine -- using float32 is way slower than float64. On a 2ghz
opteron:
sin
Charles R Harris wrote:
What compiler versions are folks using? In the slow cases, what is the
timing for converting to double, computing the sin, then casting back to
single?
I did this, is this the right way to do that?
t =
On Mon, Aug 3, 2009 at 11:51 AM, Andrew Friedley afrie...@indiana.eduwrote:
Charles R Harris wrote:
What compiler versions are folks using? In the slow cases, what is the
timing for converting to double, computing the sin, then casting back to
single?
I did this, is this the right way to
On 08/03/2009 12:51 PM, Andrew Friedley wrote:
Charles R Harris wrote:
What compiler versions are folks using? In the slow cases, what is the
timing for converting to double, computing the sin, then casting back to
single?
I did this, is this the right way to do that?
t =
Raymond de Vries wrote:
Thanks for the explanation. After having looked at the documentation, I
decided to do my own plain Python c-api implementation.
That is unlikely to be the best option these days -- it's simply too
easy to make a type checking and or reference counting error.
If SWIG
Is there any interest in a BoF session on implementing numerical
methods for partial differential equations using modules like numpy,
cython, mpi4py, etc.?
Regards,
Chris
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Hi Chris,
Thanks for the explanation. After having looked at the documentation, I
decided to do my own plain Python c-api implementation.
That is unlikely to be the best option these days -- it's simply too
easy to make a type checking and or reference counting error.
If SWIG isn't
Please remind: BoF = ?
DG
--- On Mon, 8/3/09, Chris Kees cek...@gmail.com wrote:
From: Chris Kees cek...@gmail.com
Subject: [Numpy-discussion] PDE BoF at SciPy2009
To: Discussion of Numerical Python numpy-discussion@scipy.org
Date: Monday, August 3, 2009, 12:57 PM
Is there any interest in
On Mon, Aug 03, 2009 at 02:26:17PM -0700, David Goldsmith wrote:
Please remind: BoF = ?
http://conference.scipy.org/bofs
G.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Raymond de Vries wrote:
Oops, I guess I didn't express myself clearly enough: I have used plain
Python c-api (in my case a list of lists for my 2-dimensional arrays)
for my typemaps. Sorry for the unclearness. Actually because NumPy is
not my cup of tea...
Well, for almost any purpose,
Hi,
We are using numpy.distutils, and have run into this odd behavior in windows:
I have XP, Mingw, latest numpy SVN, python.org python 2.6. All the
commands below I am running from within the 'numpy' root directory
(where 'numpy' is a subdirectory).
If I run
python setup.py build
I get the
Hi All,
I (David Cournapeau) and the people at Berkeley (Jarrod Millman,
Fernando Perez, Matthew Brett) have been in discussion so that I could
do some funded work on NumPy/SciPy. Although they are obviously
interested in improvements that help their own projects, they are
willing to make
Matthew Brett wrote:
Hi,
We are using numpy.distutils, and have run into this odd behavior in windows:
I have XP, Mingw, latest numpy SVN, python.org python 2.6. All the
commands below I am running from within the 'numpy' root directory
(where 'numpy' is a subdirectory).
If I run
On Mon, Aug 3, 2009 at 8:42 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Hi All,
I (David Cournapeau) and the people at Berkeley (Jarrod Millman,
Fernando Perez, Matthew Brett) have been in discussion so that I could
do some funded work on NumPy/SciPy. Although they are
32 matches
Mail list logo
