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
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,
>
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:
>>
> "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
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
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 (
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
26 matches
Mail list logo