Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 6:30 PM, Ralf Gommers wrote: > > > > On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers > wrote: >> >> >> >> >> On Thu, May 2, 2013 at 9:54 PM, Charles R Harris >> wrote: >>> >>> >>> >>> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers >>> wrote: On Thu,

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers wrote: > > > > On Thu, May 2, 2013 at 9:54 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers wrote: >> >>> >>> >>> >>> On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen wrote: >>> Cha

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 9:54 PM, Charles R Harris wrote: > > > On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers wrote: > >> >> >> >> On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen wrote: >> >>> Charles R Harris gmail.com> writes: >>> [clip] >>> > * Did you notice this line on the requirements page?

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers wrote: > > > > On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen wrote: > >> Charles R Harris gmail.com> writes: >> [clip] >> > * Did you notice this line on the requirements page? "Having your >> > first pull request merged before the GSoC application

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen wrote: > Charles R Harris gmail.com> writes: > [clip] > > * Did you notice this line on the requirements page? "Having your > > first pull request merged before the GSoC application deadline (May 3) > > is required for your application to be accepte

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

Charles R Harris gmail.com> writes: [clip] > * Did you notice this line on the requirements page? "Having your > first pull request merged before the GSoC application deadline (May 3) > is required for your application to be accepted." > > Where is that last requirement? It seems out of line to m

Re: [Numpy-discussion] numPy not imported into Python

On Wed, May 1, 2013 at 6:52 PM, Mark Micklich wrote: > Oh! I imported numpy and that worked. I probably should have mentioned > I'm working through the 2005 "*Numerical Methods in Engineering with > Python*" textbook from the school library. The examples are still good, > but the Import statem

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

For the sake of completeness, I don't think I ever mentioned what I used to profile when I was working on speeding up the scalars. I used AQTime 7. It is commercial and only for Windows (as far as I know). It works great and it gave me fairly accurate timings and all sorts of visual navigation

Re: [Numpy-discussion] Profiling (was GSoC : Performance parity between numpy arrays and Python scalars)

On Thu, May 2, 2013 at 10:51 AM, Francesc Alted wrote: > On 5/2/13 3:58 PM, Nathaniel Smith wrote: >> callgrind has the *fabulous* kcachegrind front-end, but it only >> measures memory access performance on a simulated machine, which is >> very useful sometimes (if you're trying to optimize cache

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 3:57 PM, Charles R Harris wrote: > > On Thu, May 2, 2013 at 8:40 AM, Robert Kern wrote: >> >> On Thu, May 2, 2013 at 3:28 PM, Charles R Harris >> wrote: >> > >> > >> > On Thu, May 2, 2013 at 7:47 AM, Robert Kern >> > wrote: >> >> >> >> On Thu, May 2, 2013 at 2:38 PM, Char

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 7:14 AM, Nathaniel Smith wrote: > On Thu, May 2, 2013 at 6:26 AM, Arink Verma > wrote: > > Yes, we need to ensure that.. > > Code generator can be made, which can create code for table of registered > > dtype during build time itself. > > I'd probably just generate it at r

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 8:40 AM, Robert Kern wrote: > On Thu, May 2, 2013 at 3:28 PM, Charles R Harris > wrote: > > > > > > On Thu, May 2, 2013 at 7:47 AM, Robert Kern > wrote: > >> > >> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris > >> wrote: > >> > > >> > On Thu, May 2, 2013 at 7:28 AM, R

Re: [Numpy-discussion] Profiling (was GSoC : Performance parity between numpy arrays and Python scalars)

On 5/2/13 3:58 PM, Nathaniel Smith wrote: > callgrind has the *fabulous* kcachegrind front-end, but it only > measures memory access performance on a simulated machine, which is > very useful sometimes (if you're trying to optimize cache locality), > but there's no guarantee that the bottlenecks on

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 3:28 PM, Charles R Harris wrote: > > > On Thu, May 2, 2013 at 7:47 AM, Robert Kern wrote: >> >> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris >> wrote: >> > >> > On Thu, May 2, 2013 at 7:28 AM, Robert Kern >> > wrote: >> >> >> >> On Thu, May 2, 2013 at 12:03 PM, Nathan

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 7:47 AM, Robert Kern wrote: > On Thu, May 2, 2013 at 2:38 PM, Charles R Harris > wrote: > > > > On Thu, May 2, 2013 at 7:28 AM, Robert Kern > wrote: > >> > >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: > >> > On 1 May 2013 23:12, "Charles R Harris" > >> > w

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

Updating table at runtime, seems a good option. But then we have maintain separate file for caching and storing. I will see, op2calltree.py and gperftools both. >* Instead of making a giant table of everything that needs to be done >to make stuff fast firs

Re: [Numpy-discussion] Profiling (was GSoC : Performance parity between numpy arrays and Python scalars)

On Thu, May 2, 2013 at 9:25 AM, David Cournapeau wrote: >> * Re: the profiling, I wrote a full oprofile->callgrind format script >> years ago: http://vorpus.org/~njs/op2calltree.py >> Haven't used it in years either but neither oprofile nor kcachegrind >> are terribly fast-moving projects so it's

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 2:38 PM, Charles R Harris wrote: > > On Thu, May 2, 2013 at 7:28 AM, Robert Kern wrote: >> >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: >> > On 1 May 2013 23:12, "Charles R Harris" >> > wrote: >> >> >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root wrote:

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 7:28 AM, Robert Kern wrote: > On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: > > On 1 May 2013 23:12, "Charles R Harris" > wrote: > >> > >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root wrote: > >>> > >>> So, to summarize the thread so far: > >>> > >>> Consensus

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: > On 1 May 2013 23:12, "Charles R Harris" wrote: >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root wrote: >>> >>> So, to summarize the thread so far: >>> >>> Consensus: >>> np.nanmean() >>> np.nanstd() >>> np.minmax() >>> np.argminmax() >

[Numpy-discussion] Profiling (was GSoC : Performance parity between numpy arrays and Python scalars)

> * Re: the profiling, I wrote a full oprofile->callgrind format script > years ago: http://vorpus.org/~njs/op2calltree.py > Haven't used it in years either but neither oprofile nor kcachegrind > are terribly fast-moving projects so it's probably still working, or > could be made so without much wo

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 6:26 AM, Arink Verma wrote: > Yes, we need to ensure that.. > Code generator can be made, which can create code for table of registered > dtype during build time itself. I'd probably just generate it at run-time on an as-needed basis. (I.e., use the full lookup logic the fi

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

On Thu, May 2, 2013 at 11:26 AM, Arink Verma wrote: > Yes, we need to ensure that.. > Code generator can be made, which can create code for table of registered > dtype during build time itself. So dtypes can be registered at runtime as well. In an ideal world, 'native' numpy types would not be sp

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On Thu, 2013-05-02 at 07:03 -0400, Nathaniel Smith wrote: > On 1 May 2013 23:12, "Charles R Harris" > wrote: > > > > > > > > On Wed, May 1, 2013 at 7:10 PM, Benjamin Root > wrote: > >> > >> So, to summarize the thread so far: > >> > >> Consensus: > >> np.nanmean() > >> np.nanstd() > >> np.minmax(

Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

On 1 May 2013 23:12, "Charles R Harris" wrote: > > > > On Wed, May 1, 2013 at 7:10 PM, Benjamin Root wrote: >> >> So, to summarize the thread so far: >> >> Consensus: >> np.nanmean() >> np.nanstd() >> np.minmax() >> np.argminmax() >> >> Vague Consensus: >> np.sincos() >> > > If the return of sinc

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

Yes, we need to ensure that.. Code generator can be made, which can create code for table of registered dtype during build time itself. Also at present there lot of duplicate code that attempts to work around these slow paths, simplification of that code is also required. On Thu, May 2, 2013 at