Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread David Cournapeau
Francesc Altet wrote: > > > > So, cProfile is only showing where the time is spent at the > first-level calls in extension level. If we want more introspection on > the C stack, and you are running un Linux, oprofile > (http://oprofile.sourceforge.net) is a very nice profiler. Here are > the output

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread David Cournapeau
John Hunter wrote: >> "David" == David Cournapeau <[EMAIL PROTECTED]> writes: > David> At the end, in the original context (speeding the drawing > David> of spectrogram), this is the problem. Even if multiple > David> backend/toolkits have obviously an impact in performances, >

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread Eric Firing
John, The current version of __call__ already includes substantial speedups prompted by David's profiling, and if I understand correctly the present bottleneck is actually the numpy take function. That is not to say that other improvements can't be made, of course. Eric John Hunter wrote: >>

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread John Hunter
> "David" == David Cournapeau <[EMAIL PROTECTED]> writes: David> At the end, in the original context (speeding the drawing David> of spectrogram), this is the problem. Even if multiple David> backend/toolkits have obviously an impact in performances, David> I really don't see wh

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Charles R Harris
On 12/19/06, David Cournapeau <[EMAIL PROTECTED]> wrote: Travis Oliphant wrote: > Robert Kern wrote: >> David Cournapeau wrote: When I went back to home, I started taking a close look a numpy/core C sources, with the help of the numpy ebook. The huge source files make it really difficult f

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread David Cournapeau
Charles R Harris wrote: > > > > > > My guess is that the real bottleneck is in calling so many times > memmove (once per element in the array). Perhaps the algorithm can be > changed to do a block copy at the beginning and then modify only the > places on which the clip should act (

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread David Cournapeau
Francesc Altet wrote: > A Dimarts 19 Desembre 2006 08:12, David Cournapeau escrigué: >> Hi, >> >>Following the discussion on clip and other functions which *may* be >> slow in numpy, I would like to know if there is a way to easily profile >> numpy, ie functions which are written in C. >>Fo

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Robert Kern
Tim Hochberg wrote: > Robert Kern wrote: >> Travis Oliphant wrote: >> >>> The problem with the copy=True keyword is that it would imply needing to >>> expand the C-API for PyArray_Clip and should not be done until 1.1 IMHO. >>> >> I don't think we have to change the signature of PyArray_Cl

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread David Cournapeau
Travis Oliphant wrote: > Robert Kern wrote: >> David Cournapeau wrote: >> >> >>> Basically, at least from those figures, both versions are pretty >>> similar, and not worth improving much anyway for matplotlib. There is >>> something funny with numpy version, though. >>> >> Looking at the

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Tim Hochberg
Robert Kern wrote: > Travis Oliphant wrote: > >> The problem with the copy=True keyword is that it would imply needing to >> expand the C-API for PyArray_Clip and should not be done until 1.1 IMHO. >> > > I don't think we have to change the signature of PyArray_Clip() at all. > PyArray_Cli

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Robert Kern
Travis Oliphant wrote: > There are a lot of functions that are essentially this. Many things > were done to just get something working. It would seem like a good idea > to re-code many of these to speed them up. Off the top of your head, do you have a list of these? -- Robert Kern "I have

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Robert Kern
Travis Oliphant wrote: > The problem with the copy=True keyword is that it would imply needing to > expand the C-API for PyArray_Clip and should not be done until 1.1 IMHO. I don't think we have to change the signature of PyArray_Clip() at all. PyArray_Clip() takes an "out" argument. Currently, t

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Travis Oliphant
Robert Kern wrote: > David Cournapeau wrote: > > >> Basically, at least from those figures, both versions are pretty >> similar, and not worth improving much anyway for matplotlib. There is >> something funny with numpy version, though. >> > > Looking at the code, it's certainly not surpr

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Travis Oliphant
David Cournapeau wrote: > Robert Kern wrote: > >> Looking at the code, it's certainly not surprising that the current >> implementation of clip() is slow. It is a direct numpy C API translation of >> the >> following (taken from numarray, but it is the same in Numeric): >> >> >> def clip(m, m_m

Re: [Numpy-discussion] (no subject)

2006-12-19 Thread Robert Kern
Bandler, Derek wrote: > Hi, > > I would like to get information on the software licenses for numpy & > numeric. On the sourceforge home for the packages, the listed license > is _OSI-Approved Open Source_ > . Is it possible to get > more information on this? A copy of the document would be usef

Re: [Numpy-discussion] (no subject)

2006-12-19 Thread Greg Willden
Hi Derek, Like all Free & Open Source Software (FOSS) projects the license is distributed with the source code. There is a file called LICENSE.txt in the numpy tar archive. Here are the contents of that file. Copyright (c) 2005, NumPy Developers All rights reserved. Redistribution and use in sou

[Numpy-discussion] (no subject)

2006-12-19 Thread Bandler, Derek
Hi, I would like to get information on the software licenses for numpy & numeric. On the sourceforge home for the packages, the listed license is OSI-Approved Open Source . Is it possible to get more information on this? A copy of the document would be useful. Thank you. Best regards, Derek Ba

[Numpy-discussion] Unexpected output using numpy.ndarray and __radd__

2006-12-19 Thread Mark Hoffmann
Hi, The following issue has puzzled me for a while. I want to add a numpy.ndarray and an instance of my own class. I define this operation by implementing the methods __add__ and __radd__. My programme (including output) looks like: #!/usr/local/bin/python import numpy class Cyclehist: def

[Numpy-discussion] A question about argmax and argsort

2006-12-19 Thread asaf david
Hello Let's say i have an N sized array, and i want to get the positions of the K largest items. for K = 1 this is simply argmax. is there any way to generalize it for k !=1? currently I use argsort and take only K items from it, but I'm paying an additional ~lg(N)... Thanks in advance, asaf

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread Charles R Harris
On 12/19/06, Francesc Altet <[EMAIL PROTECTED]> wrote: A Dimarts 19 Desembre 2006 08:12, David Cournapeau escrigué: > Hi, > My guess is that the real bottleneck is in calling so many times memmove (once per element in the array). Perhaps the algorithm can be changed to do a block copy

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

2006-12-19 Thread Francesc Altet
A Dimarts 19 Desembre 2006 08:12, David Cournapeau escrigué: > Hi, > >Following the discussion on clip and other functions which *may* be > slow in numpy, I would like to know if there is a way to easily profile > numpy, ie functions which are written in C. >For example, I am not sure to un

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Robert Kern
David Cournapeau wrote: > I would be happy to code the function; for new code to be added to > numpy, is there another branch than the current one ? What is the > approach for a 1.1.x version of numpy ? I don't think we've decided on one, yet. > For now, putting the function with a copy (the c

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread David Cournapeau
Robert Kern wrote: > > Looking at the code, it's certainly not surprising that the current > implementation of clip() is slow. It is a direct numpy C API translation of > the > following (taken from numarray, but it is the same in Numeric): > > > def clip(m, m_min, m_max): > """clip() returns

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread Robert Kern
David Cournapeau wrote: > Basically, at least from those figures, both versions are pretty > similar, and not worth improving much anyway for matplotlib. There is > something funny with numpy version, though. Looking at the code, it's certainly not surprising that the current implementation of

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread David Cournapeau
Eric Firing wrote: > David Cournapeau wrote: >> Well, this is something I would be willing to try *if* this is the main >> bottleneck of imshow/show. I am still unsure about the problem, because >> if I change numpy.clip to my function, including a copy, I really get a >> big difference myself:

Re: [Numpy-discussion] slow numpy.clip ?

2006-12-19 Thread David Cournapeau
Gael Varoquaux wrote: > On Tue, Dec 19, 2006 at 02:10:29PM +0900, David Cournapeau wrote: >> I would really like to see the imshow/show calls goes in the range of a >> few hundred ms; for interactive plotting, this really change a lot in my >> opinion. > > I think this is strongly dependant on so