I think everybody would be happy if .sum() were as fast as possible, and
patches for review are always welcome. There are distinct things that could
be done to improve the performance of ufuncs and their methods as several
people have shown.In fact, there is a lot of low-hanging fruit ins
Hi Sturla,
On Sat, Feb 12, 2011 at 5:38 PM, Sturla Molden wrote:
> Den 10.02.2011 16:29, skrev eat:
> > One would expect sum to outperform dot with a clear marginal. Does
> > there exixts any 'tricks' to increase the performance of sum?
>
First of all, thanks for you still replying. Well, I'm st
Hi,
If someone with commit access has the chance, could they take a
look at ticket 1603:
http://projects.scipy.org/numpy/ticket/1603
and apply it if it looks ok? It speeds up in1d(a, b) a lot for
the common use case where len(b) << len(a).
Thanks,
Neil
___
Hello All,
I have been toying with OpenMP through f2py and ctypes. On the whole,
the results of my efforts have been very encouraging. That said, some
results are a bit perplexing.
I have written identical routines that I run directly as a C-derived
executable, and through ctypes as a shared li
Den 10.02.2011 16:29, skrev eat:
> One would expect sum to outperform dot with a clear marginal. Does
> there exixts any 'tricks' to increase the performance of sum?
I see that others have ansvered already. The ufunc np.sum is not going
going to beat np.dot. You are racing the heavy machinery of
Hi Barry,
On Fri, Feb 11, 2011 at 1:22 AM, Barry Warsaw wrote:
> I hope this message is on-topic for this mailing list!
>
> I'm working on the packaging for python-numpy 1.5 in the next version of
> Ubuntu (11.04 - Natty), and I'm hitting an issue that I'm hoping you can
> help
> me with.
>
> No
On Sat, Feb 12, 2011 at 12:07 AM, Pauli Virtanen wrote:
> Fri, 11 Feb 2011 10:40:57 -0500, Barry Warsaw wrote:
> [clip]
> > Neither will be acceptable I think. Prebuilt by upstream won't fly
> > for Debian because they'd want the source and build process, and I
> > don't see a feasible way for t
