[Numpy-discussion] Example of numpy cov() not correct?

Hi, all, I am trying out the example here (http://www.scipy.org/Numpy_Example_List_With_Doc#cov) >>> from numpy import * ... >>> T = array([1.3, 4.5, 2.8, 3.9]) >>> P = array([2.7, 8.7, 4.7, 8.2]) >>> cov(T,P) The answer is supposed to be 3.95416

[Numpy-discussion] Why are all fortran compilers looked for when --fcompiler=something is given ?

Hi, While building numpy in wine, I got some errors in distutils when initializing the fortran compilers. I build numpy with: wine python setup.py build -c mingw32 --fcompiler=gnu95 And I got an error in load_all_fcompiler_classes when it tries to load the Compaq visual compiler. I don't thi

Re: [Numpy-discussion] Core dump during numpy.test()

Mathew Yeates wrote: > my set up is similar. Same cpu's. Except I am using atlas 3.9.1 and gcc > 4.2.4 > ATLAS 3.9.1 is a development version, and is not supposed to be used for production use. Please use 3.8.2 if you want to build your own atlas, cheers, David __

Re: [Numpy-discussion] Core dump during numpy.test()

> This smells like an ATLAS problem. You should seed a note to Clint > Whaley (the ATLAS guy). IIRC, ATLAS has some hand coded asm routines and > it seems that support for these very new processors might be broken. I believe the machine is a couple of years old, though it's a fairly high-end wo

Re: [Numpy-discussion] FFT usage / consistency

> Rather than look for errors in the scaling factors or errors in your code, I > think that you should try to expand your understanding of the (subtly) > different > types of Fourier representations. I'd strongly recommend "The Fourier Transform and its Applications" by Bracewell, if that helps.

Re: [Numpy-discussion] Core dump during numpy.test()

On Tue, Jul 29, 2008 at 18:00, Mathew Yeates <[EMAIL PROTECTED]> wrote: > What got fixed? >>>(look at the second one, warnings wasn't imported?) -- 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

Re: [Numpy-discussion] Core dump during numpy.test()

What got fixed? Robert Kern wrote: > On Tue, Jul 29, 2008 at 17:41, Mathew Yeates <[EMAIL PROTECTED]> wrote: > >> Charles R Harris wrote: >> >>> This smells like an ATLAS problem. >>> >> I don't think so. I crash in a call to dsyevd which part of lapack but >> not atlas. Also, when

Re: [Numpy-discussion] Core dump during numpy.test()

On Tue, Jul 29, 2008 at 17:41, Mathew Yeates <[EMAIL PROTECTED]> wrote: > Charles R Harris wrote: >> >> >> This smells like an ATLAS problem. > I don't think so. I crash in a call to dsyevd which part of lapack but > not atlas. Also, when I commented out the call to test_eigh_build I get > zillions

Re: [Numpy-discussion] Core dump during numpy.test()

oops. It is ATLAS. I was able to run with a nonoptimized lapack. Mathew Yeates wrote: > Charles R Harris wrote: > >> This smells like an ATLAS problem. >> > I don't think so. I crash in a call to dsyevd which part of lapack but > not atlas. Also, when I commented out the call to test_eigh

Re: [Numpy-discussion] Core dump during numpy.test()

Charles R Harris wrote: > > > This smells like an ATLAS problem. I don't think so. I crash in a call to dsyevd which part of lapack but not atlas. Also, when I commented out the call to test_eigh_build I get zillions of errors like (look at the second one, warnings wasn't imported?) =

Re: [Numpy-discussion] FFT usage / consistency

Felix Richter physik3.uni-rostock.de> writes: > > > Do your answers differ from the theory by a constant factor, or are > > they completely unrelated? > > No, it's more complicated. Below you'll find my most recent, more stripped > down code. > > - I don't know how to scale in a way that work

Re: [Numpy-discussion] Core dump during numpy.test()

On Tue, Jul 29, 2008 at 2:48 PM, James Turner <[EMAIL PROTECTED]> wrote: > Thanks everyone. I think I might try using the Netlib BLAS, since > it's a server installation... but please let me know if you'd like > me to troubleshoot this some more (the sooner the easier). > This smells like an ATLA

Re: [Numpy-discussion] Core dump during numpy.test()

more info when /linalg.py(872)eigh() calls dsyevd I crash James Turner wrote: > Thanks everyone. I think I might try using the Netlib BLAS, since > it's a server installation... but please let me know if you'd like > me to troubleshoot this some more (the sooner the easier). > > James. > > ___

Re: [Numpy-discussion] Core dump during numpy.test()

Thanks everyone. I think I might try using the Netlib BLAS, since it's a server installation... but please let me know if you'd like me to troubleshoot this some more (the sooner the easier). James. ___ Numpy-discussion mailing list Numpy-discussion@sci

Re: [Numpy-discussion] Core dump during numpy.test()

I am using an ATLAS 64 bit lapack 3.9.1. My cpu (4 cpus) - processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz stepping: 6 cpu MHz

Re: [Numpy-discussion] Core dump during numpy.test()

my set up is similar. Same cpu's. Except I am using atlas 3.9.1 and gcc 4.2.4 James Turner wrote: >> Are you using ATLAS? If so, where did you get it and what cpu do you have? >> > > Yes. I have Atlas 3.8.2. I think I got it from > http://math-atlas.sourceforge.net. I also included Lapack 3.

Re: [Numpy-discussion] Core dump during numpy.test()

> Are you using ATLAS? If so, where did you get it and what cpu do you have? Yes. I have Atlas 3.8.2. I think I got it from http://math-atlas.sourceforge.net. I also included Lapack 3.1.1 from Netlib when building it from source. This worked on another machine. According to /proc/cpuinfo, I have

Re: [Numpy-discussion] Numpy 1.1.0 (+ PIL 1.1.6) crashes on large datasets

> I've managed to crash numpy+PIL when feeding it rather large images. > Please see the URL for a test image, script, and gdb stack trace. This > crashes on my box (Windows XP SP3) as well as on a linux box (the gdb > trace I've been provided with) and a Mac. Windows reports the crash to > happen i

[Numpy-discussion] Core dump during numpy.test()

Thanks, Robert. > Can you do > > numpy.test(verbosity=2) OK. Here is the line that fails: check_matvec (numpy.core.tests.test_numeric.TestDot)Floating exception (core dumped) > A gdb backtrace would also help. OK. I'm pretty ignorant about using debuggers, but I did "gdb python core.23696" a

Re: [Numpy-discussion] Core dump during numpy.test()

On Tue, Jul 29, 2008 at 1:16 PM, James Turner <[EMAIL PROTECTED]> wrote: > I have built NumPy 1.1.0 on RedHat Enterprise 3 (Linux 2.4.21 > with gcc 3.2.3 and glibc 2.3.2) and Python 2.5.1. When I run > numpy.test() I get a core dump, as follows. I haven't noticed > any special errors during the bu

Re: [Numpy-discussion] Core dump during numpy.test()

I'm getting this too Ticket #652 ... ok Ticket 662.Segmentation fault Robert Kern wrote: > On Tue, Jul 29, 2008 at 14:16, James Turner <[EMAIL PROTECTED]> wrote: > >> I have built NumPy 1.1.0 on RedHat Enterprise 3 (Linux 2.4.21 >> with gcc 3.2.3 and glibc 2.3.2) and Python 2.5.1. When I run >

Re: [Numpy-discussion] The date/time dtype and the casting issue

On Tuesday 29 July 2008 15:14:13 Ivan Vilata i Balaguer wrote: > Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir:: > > > Relative time versus relative time > > > -- > > > > > > This case would be the same than the previous one (absolute vs > > > absolute). Our

Re: [Numpy-discussion] Operation over multiple axes? (Or: Partial flattening?)

2008/7/29 Hans Meine <[EMAIL PROTECTED]>: > On Dienstag 29 Juli 2008, Stéfan van der Walt wrote: >> > One way to achieve this is partial flattening, which I did like this: >> > >> > dat.reshape((numpy.prod(dat.shape[:3]), dat.shape[3])).sum(0) >> > >> > Is there a more elegant way to do this? >> >

Re: [Numpy-discussion] Core dump during numpy.test()

On Tue, Jul 29, 2008 at 14:16, James Turner <[EMAIL PROTECTED]> wrote: > I have built NumPy 1.1.0 on RedHat Enterprise 3 (Linux 2.4.21 > with gcc 3.2.3 and glibc 2.3.2) and Python 2.5.1. When I run > numpy.test() I get a core dump, as follows. I haven't noticed > any special errors during the build

[Numpy-discussion] Numpy 1.1.0 (+ PIL 1.1.6) crashes on large datasets

Hi, I've managed to crash numpy+PIL when feeding it rather large images. Please see the URL for a test image, script, and gdb stack trace. This crashes on my box (Windows XP SP3) as well as on a linux box (the gdb trace I've been provided with) and a Mac. Windows reports the crash to happen in "mu

[Numpy-discussion] Core dump during numpy.test()

I have built NumPy 1.1.0 on RedHat Enterprise 3 (Linux 2.4.21 with gcc 3.2.3 and glibc 2.3.2) and Python 2.5.1. When I run numpy.test() I get a core dump, as follows. I haven't noticed any special errors during the build. Should I post the entire terminal output from "python setup.py install"? Mayb

Re: [Numpy-discussion] The date/time dtype and the casting issue

Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir:: > > Relative time versus relative time > > -- > > > > This case would be the same than the previous one (absolute vs > > absolute). Our proposal is to forbid this operation if the time units > > of the operand

Re: [Numpy-discussion] Operation over multiple axes? (Or: Partial flattening?)

On Tue, Jul 29, 2008 at 09:24, Hans Meine <[EMAIL PROTECTED]> wrote: > On Dienstag 29 Juli 2008, Stéfan van der Walt wrote: >> > One way to achieve this is partial flattening, which I did like this: >> > >> > dat.reshape((numpy.prod(dat.shape[:3]), dat.shape[3])).sum(0) >> > >> > Is there a more e

Re: [Numpy-discussion] why isn't libfftw.a being accessed?

On Tue, Jul 29, 2008 at 11:22, Mathew Yeates <[EMAIL PROTECTED]> wrote: > Hi > In my site.cfg I have > > [DEFAULT] > library_dirs = /home/ossetest/lib64:/home/ossetest/lib > include_dirs = /home/ossetest/include > > [fftw] > libraries = fftw3 > > but libfftw3.a isn't being accesed. > ls -lu ~/lib/l

Re: [Numpy-discussion] The date/time dtype and the casting issue

Tom Denniston (el 2008-07-29 a les 12:21:39 -0500) va dir:: > [...] > I think it would be ideal if things like the following worked: > > >>> series = numpy.array(['1970-02-01','1970-09-01'], dtype = 'datetime64[D]') > >>> series == '1970-02-01' > [True, False] > > I view this as similar to: > >

Re: [Numpy-discussion] The date/time dtype and the casting issue

A Tuesday 29 July 2008, Tom Denniston escrigué: > Francesc, > > The datetime proposal is very impressive in its depth and thought. > For me as well as many other people this would be a massive > improvement to numpy and allow numpy to get a foothold in areas like > econometrics where R/S is now dom

Re: [Numpy-discussion] The date/time dtype and the casting issue

David Huard (el 2008-07-29 a les 12:31:54 -0400) va dir:: > Silent casting is often a source of bugs and I appreciate the strict > rules you want to enforce. However, I think there should be a simpler > mechanism for operations between different types than creating a copy > of a variable with the

Re: [Numpy-discussion] The date/time dtype and the casting issue

On Tuesday 29 July 2008 14:08:28 Francesc Alted wrote: > A Tuesday 29 July 2008, David Huard escrigué: > Hmm, the idea of the ``.add()`` and ``.subtract()`` methods is tempting, > but I not sure it is a good idea to add new methods to the ndarray > object that are meant to be used with just the da

Re: [Numpy-discussion] The date/time dtype and the casting issue

A Tuesday 29 July 2008, David Huard escrigué: > Hi, > > Silent casting is often a source of bugs and I appreciate the strict > rules you want to enforce. > However, I think there should be a simpler mechanism for operations > between different types > than creating a copy of a variable with the cor

Re: [Numpy-discussion] The date/time dtype and the casting issue

Francesc, The datetime proposal is very impressive in its depth and thought. For me as well as many other people this would be a massive improvement to numpy and allow numpy to get a foothold in areas like econometrics where R/S is now dominant. I had one question regarding casting of strings: I

Re: [Numpy-discussion] FFT usage / consistency

On Tue, Jul 29, 2008 at 8:56 AM, Felix Richter <[EMAIL PROTECTED] > wrote: > > I quickly copy-pasted and ran your code; it looks to me like the results > > you calculated analytically oscillate too fast to be represented > > discretely. Did you try to transform different, simpler signals? (e.g.

Re: [Numpy-discussion] The date/time dtype and the casting issue

Francesc, > Absolute time versus relative time > -- > > We think that in this case the absolute time should have priority for > determining the time unit of the outcome. +1 > Absolute time versus absolute time > -- > > When operat

Re: [Numpy-discussion] The date/time dtype and the casting issue

Hi, Silent casting is often a source of bugs and I appreciate the strict rules you want to enforce. However, I think there should be a simpler mechanism for operations between different types than creating a copy of a variable with the correct type. My suggestion is to have a dtype argument for m

[Numpy-discussion] why isn't libfftw.a being accessed?

Hi In my site.cfg I have [DEFAULT] library_dirs = /home/ossetest/lib64:/home/ossetest/lib include_dirs = /home/ossetest/include [fftw] libraries = fftw3 but libfftw3.a isn't being accesed. ls -lu ~/lib/libfftw3.a -rw-r--r-- 1 ossetest ossetest 1572628 Jul 26 15:02 /home/ossetest/lib/libfftw3.a

Re: [Numpy-discussion] The date/time dtype and the casting issue

Ops, after reviewing this document, I've discovered a couple of typos. A Tuesday 29 July 2008, Francesc Alted escrigué: [snip] > >>> series = numpy.array(['1970-01-01', '1970-02-01', '1970-09-01'], > dtype='datetime64[D]') > >>> series2 = series + numpy.timedelta(1, 'Y') # Add 2 years

Re: [Numpy-discussion] No Copy Reduce Operations

Travis E. Oliphant wrote: > Your approach using C++ templates is interesting, and I'm very glad for > your explanation and your releasing of the code as open source.I'm > not prepared to start using C++ in NumPy, however, so your code will > have to serve as an example only. I will keep th

Re: [Numpy-discussion] FFT usage / consistency

> I quickly copy-pasted and ran your code; it looks to me like the results > you calculated analytically oscillate too fast to be represented > discretely. Did you try to transform different, simpler signals? (e.g. a > Gaussian?) Yes, I run into the same problem. Since the oscillation frequency

Re: [Numpy-discussion] Recent work for branch cuts / C99 complex maths: problems on mingw

On Tue, Jul 29, 2008 at 8:38 AM, Pauli Virtanen <[EMAIL PROTECTED]> wrote: > Tue, 29 Jul 2008 08:13:23 -0600, Charles R Harris wrote: > [clip] > > We also need speed. I think we just say behaviour on the branch cuts is > > undefined, which is numerically true in any case, and try to get the > > na

Re: [Numpy-discussion] Recent work for branch cuts / C99 complex maths: problems on mingw

Tue, 29 Jul 2008 08:13:23 -0600, Charles R Harris wrote: [clip] > We also need speed. I think we just say behaviour on the branch cuts is > undefined, which is numerically true in any case, and try to get the > nan's and infs sorted out. But only if the costs are reasonable. Well, the branch cut t

Re: [Numpy-discussion] Operation over multiple axes? (Or: Partial flattening?)

On Dienstag 29 Juli 2008, Stéfan van der Walt wrote: > > One way to achieve this is partial flattening, which I did like this: > > > > dat.reshape((numpy.prod(dat.shape[:3]), dat.shape[3])).sum(0) > > > > Is there a more elegant way to do this? > > That looks like a good way to do it. You can cle

Re: [Numpy-discussion] FFT usage / consistency

Hi Felix, I quickly copy-pasted and ran your code; it looks to me like the results you calculated analytically oscillate too fast to be represented discretely. Did you try to transform different, simpler signals? (e.g. a Gaussian?) Ciao, / /

Re: [Numpy-discussion] svn numpy selftests fail on Solaris

On Tue, Jul 29, 2008 at 7:36 AM, Christopher Hanley <[EMAIL PROTECTED]>wrote: > This has apparently been occurring for a few days. My apologizes but I > have been away on vacation. > > FAILED (failures=5) > Running unit tests for numpy > NumPy version 1.2.0.dev5565 > NumPy is installed in /usr/ra

Re: [Numpy-discussion] Recent work for branch cuts / C99 complex maths: problems on mingw

On Tue, Jul 29, 2008 at 5:59 AM, Pauli Virtanen <[EMAIL PROTECTED]> wrote: > Tue, 29 Jul 2008 20:16:36 +0900, David Cournapeau wrote: > [clip] > > Is there a clear explanation about C99 features related to complex math > > somewhere ? The problem with C99 is that few compilers implement it > > The

[Numpy-discussion] svn numpy selftests fail on Solaris

This has apparently been occurring for a few days. My apologizes but I have been away on vacation. FAILED (failures=5) Running unit tests for numpy NumPy version 1.2.0.dev5565 NumPy is installed in /usr/ra/pyssg/2.5.1/numpy Python version 2.5.1 (r251:54863, Jun 4 2008, 15:48:19) [C] nose versio

Re: [Numpy-discussion] Operation over multiple axes? (Or: Partial flattening?)

2008/7/29 Hans Meine <[EMAIL PROTECTED]>: > with a multidimensional array (say, 4-dimensional), I often want to project > this onto one single dimension, i.e.. let "dat" be a 4D array, I am > interested in > > dat.sum(0).sum(0).sum(0) # equals dat.sum(2).sum(1).sum(0) > > However, creating interme

[Numpy-discussion] The date/time dtype and the casting issue

Hi, During the making of the date/time proposals and the subsequent discussions in this list, we have changed a couple of times our point of view about the way how the castings would work between different date/time types and the different time units (previously called resolutions). So I'd li

Re: [Numpy-discussion] FFT usage / consistency

> Do your answers differ from the theory by a constant factor, or are > they completely unrelated? No, it's more complicated. Below you'll find my most recent, more stripped down code. - I don't know how to scale in a way that works for any n. - I don't know how to get the oscillations to match.

[Numpy-discussion] Operation over multiple axes? (Or: Partial flattening?)

Hi, with a multidimensional array (say, 4-dimensional), I often want to project this onto one single dimension, i.e.. let "dat" be a 4D array, I am interested in dat.sum(0).sum(0).sum(0) # equals dat.sum(2).sum(1).sum(0) However, creating intermediate results looks more expensive than necess

Re: [Numpy-discussion] FFT usage / consistency

2008/7/29 Felix Richter <[EMAIL PROTECTED]>: > I learned a few things in the meantime: > > In my installation, NumPy uses fftpack_lite while SciPy uses FFTW3. There are > more test cases in SciPy which all pass. So I am confirmed my problem is a > pure usage problem. > One thing I was confused abou

Re: [Numpy-discussion] FFT usage / consistency

I learned a few things in the meantime: In my installation, NumPy uses fftpack_lite while SciPy uses FFTW3. There are more test cases in SciPy which all pass. So I am confirmed my problem is a pure usage problem. One thing I was confused about is the fact that even if I calculate the function o

Re: [Numpy-discussion] Recent work for branch cuts / C99 complex maths: problems on mingw

Tue, 29 Jul 2008 20:16:36 +0900, David Cournapeau wrote: [clip] > Is there a clear explanation about C99 features related to complex math > somewhere ? The problem with C99 is that few compilers implement it The C99 standard (or more precisely its draft but this is probably mostly the same thing)

Re: [Numpy-discussion] RFC: A (second) proposal for implementing some date/time types in NumPy

A Tuesday 29 July 2008, Francesc Alted escrigué: [snip] > > > In [12]: t[0] > > > Out[12]: 24 # representation as an int64 > > > > why not a "pretty" representation of timedelta64 too? I'd like that > > better (at least for __str__, perhaps __repr__ should be the raw > > numbers. > > That

Re: [Numpy-discussion] Recent work for branch cuts / C99 complex maths: problems on mingw

Pauli Virtanen wrote: > > I'm not sure whether it makes sense to keep the C99 tests in SVN, even if > marked as skipped, before the C code is fixed. Right now, it seems that > we are far from C99 compliance with regard to corner-case value inf-nan > behavior. (The branch cuts are mostly OK, thou

Re: [Numpy-discussion] Recent work for branch cuts / C99 complex maths: problems on mingw

Tue, 29 Jul 2008 15:17:01 +0900, David Cournapeau wrote: > Charles R Harris wrote: >> >> >> On Mon, Jul 28, 2008 at 10:29 PM, David Cournapeau >> <[EMAIL PROTECTED] > >> wrote: >> >> Hi, >> >>I was away during the discussion on the updated complex >>fu

Re: [Numpy-discussion] RFC: A (second) proposal for i mplementing some date/time types in NumPy

A Monday 28 July 2008, Pierre GM escrigué: > On Monday 28 July 2008 12:17:41 Francesc Alted wrote: > > So, for allowing this to happen, we have concluded that a > > conceptual change in our second proposal is needed: instead of > > a 'resolution', we can introduce the 'time unit' concept. > > I'm a

Re: [Numpy-discussion] RFC: A (second) proposal for implementing some date/time types in NumPy

A Monday 28 July 2008, Christopher Barker escrigué: > Hi, > > Sorry for the very long delay in commenting on this. Don't worry, we are still in time to receive more comments (but if there is people willing to contribute more comments, hurry up, please!). > In short, it > looks great, and thanks