David Cournapeau wrote:
Andrew Jaffe wrote:
Hi All,
I have just switched from RHEL to debian, and all of a sudden I started
getting floating point exception errors in various contexts.
Apparently, this has to do with some faulty error stuff in glibc,
specifically related to the sse. I
Hi All,
I'm finding myself dealing with n-dimensional grids quite a lot, and
trying to do some 'tricky' index manipulation. The main problem is
manipulating arrays when I don't know a priori the number of dimensions;
in essence I need to be able to iterate across dimensions.
first, I've got
Hi-
On PPC Mac OSX universal build 2.4.3, gcc 4.0,
In [1]: import numpy as N
In [2]: print N.__version__
1.0.2897
In [3]: N.random.uniform(0,1)
Segmentation fault
(This originally showed up in the Ticket 83 regression test during
numpy.test()...)
Andrew
Hi-
Darren Dale wrote:
I just updated from svn; test_regression looks good. Unfortunately, I need to
report a new error:
==
ERROR: check_singleton (numpy.lib.tests.test_getlimits.test_longdouble)
Hi all,
the current implementation of fftfreq (which is meant to return the
appropriate frequencies for an FFT) does the following:
k = range(0,(n-1)/2+1)+range(-(n/2),0)
return array(k,'d')/(n*d)
I have tried this with very long (2**24) arrays, and it is ridiculously
slow. Should
[copied to the scipy list since rfftfreq is only in scipy]
Andrew Jaffe wrote:
Hi all,
the current implementation of fftfreq (which is meant to return the
appropriate frequencies for an FFT) does the following:
k = range(0,(n-1)/2+1)+range(-(n/2),0)
return array(k,'d')/(n*d
Hi all,
It seems that scipy and numpy define rfft differently.
numpy returns n/2+1 complex numbers (so the first and last numbers are
actually real) with the frequencies equivalent to the positive part of
the fftfreq, whereas scipy returns n real numbers with the frequencies
as in rfftfreq
Hi Charles,
Charles R Harris wrote:
On 9/7/06, *Andrew Jaffe* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi all,
It seems that scipy and numpy define rfft differently.
numpy returns n/2+1 complex numbers (so the first and last numbers are
actually real
Steven G. Johnson wrote:
Andrew Jaffe wrote:
numpy returns n/2+1 complex numbers (so the first and last numbers are
actually real) with the frequencies equivalent to the positive part of
the fftfreq, whereas scipy returns n real numbers with the frequencies
as in rfftfreq (i.e., two real
Tim Hochberg wrote:
Travis Oliphant wrote:
Tim Hochberg wrote:
With python 2.5 out now, perhaps it's time to come up with a with
statement context manager. Something like:
a = numpy.arange(10)
a/a # ignores divide by zero
with errstate(divide='raise'):
a/a # raise
OS X 10.4, PPC
In [5]: import numpy as N
In [6]: N.__version__
Out[6]: '1.0.1.dev3399'
In [7]: print N.longfloat(0).itemsize
16
In [8]: a = N.exp(N.array([1000],dtype=N.longfloat))
In [9]: print str(a)
[inf]
In [10]: print str(a[0])
inf
In [11]: print a.itemsize
16
Andrew Jaffe wrote:
OS X 10.4, PPC
In [5]: import numpy as N
In [6]: N.__version__
Out[6]: '1.0.1.dev3399'
In [7]: print N.longfloat(0).itemsize
16
In [8]: a = N.exp(N.array([1000],dtype=N.longfloat))
In [9]: print str(a)
[inf]
In [10]: print str(a[0])
inf
In [11]: print
12 matches
Mail list logo
