# [Numpy-discussion] Functions for finding the relative extrema of numeric data

Jacob Silterra jsilter at gmail.com
Thu Sep 15 09:32:06 EDT 2011

```>What is your application?

The most common case is looking at Fourier transforms and identifying
spectral peaks. I've also analyzed images looking at 1D slices (usually very
regular data) and looked for peaks there.

That stackoverflow page had a nice link to a comparison of different
algorithms here: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2631518/. That
paper is focused on mass-spectrometry data, but the approach would
generalize to any 1D data set. Unless somebody feels otherwise, I'll close
this pull request and start working on an implementation of peak finding via
continuous wavelet transform (the best and most computationally intensive
approach of those described above).

-Jacob

------------------------------
>
> Message: 4
> Date: Tue, 13 Sep 2011 22:34:01 +0200
> From: Ralf Gommers <ralf.gommers at googlemail.com>
> Subject: Re: [Numpy-discussion] Functions for finding the relative
>        extrema of numeric data
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>        <CABL7CQhxCX0LKFENMW6-4ZSbdieGxz04zbsrnY4bXYVxVL78Dw at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Jacob,
>
> On Fri, Sep 9, 2011 at 11:57 PM, Jacob Silterra <jsilter at gmail.com> wrote:
>
> > Hello all,
> >
> > I'd like to see functions for calculating the relative extrema in a set
> of
> > data included in numpy. I use that functionality frequently, and always
> seem
> > to be writing my own version. It seems like this functionality would be
> > useful to the community at large, as it's a fairly common operation.
> >
>
>
> >
> > For numeric data (which is presumably noisy), the definition of a
> relative
> > extrema isn't completely obvious. The implementation I am proposing finds
> a
> > point in an ndarray along an axis which is larger (or smaller) than it's
> > `order` nearest neighbors (`order` being an optional parameter, default
> 1).
> > This is likely to find more points than may be desired,  which I believe
> is
> > preferable to the alternative. The output is formatted the same as
> > numpy.where.
> >
> > Code available here: https://github.com/numpy/numpy/pull/154
> >
> > I'm not sure whether this belongs in numpy or scipy, that question is
> > somewhat debatable. More sophisticated peak-finding functions (in N
> > dimensions, as opposed to 1) may also be useful to the community, and
> those
> > would definitely belong in scipy.
> >
>
> I have the feeling this belongs in scipy. Although if it's just these two
> functions I'm not sure where exactly to put them. Looking at the
> functionality, this is quite a simple approach. For any data of the type
> I'm
> usually working with it will not be able to find the right local extrema.
> The same is true for your alternative definition below.
>
> A more powerful peak detection function would be a very good addition to
>
> http://stackoverflow.com/questions/1713335/peak-finding-algorithm-for-python-scipy
>
> Cheers,
> Ralf
>
>
> > An alternative implementation would be to require that function be
> > continuously descending (or ascending) for `order` points, which would
> > enforce a minimum width on a peak.
> >
> > -Jacob Silterra
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110913/8bb2e1a5/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Tue, 13 Sep 2011 15:44:03 -0500
> From: Benjamin Root <ben.root at ou.edu>
> Subject: Re: [Numpy-discussion] Functions for finding the relative
>        extrema of numeric data
> To: Discussion of Numerical Python <numpy-discussion at scipy.org>
> Message-ID:
>        <CANNq6Fk973UWz7+uXWc55p3iRcUam36cUbFC_NUPxqdi0r7+Hg at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Sep 13, 2011 at 3:34 PM, Ralf Gommers
>
> > Hi Jacob,
> >
> > On Fri, Sep 9, 2011 at 11:57 PM, Jacob Silterra <jsilter at gmail.com>
> wrote:
> >
> >> Hello all,
> >>
> >> I'd like to see functions for calculating the relative extrema in a set
> of
> >> data included in numpy. I use that functionality frequently, and always
> seem
> >> to be writing my own version. It seems like this functionality would be
> >> useful to the community at large, as it's a fairly common operation.
> >>
> >
> > What is your application?
> >
> >>
> >> For numeric data (which is presumably noisy), the definition of a
> relative
> >> extrema isn't completely obvious. The implementation I am proposing
> finds a
> >> point in an ndarray along an axis which is larger (or smaller) than it's
> >> `order` nearest neighbors (`order` being an optional parameter, default
> 1).
> >> This is likely to find more points than may be desired,  which I believe
> is
> >> preferable to the alternative. The output is formatted the same as
> >> numpy.where.
> >>
> >> Code available here: https://github.com/numpy/numpy/pull/154
> >>
> >> I'm not sure whether this belongs in numpy or scipy, that question is
> >> somewhat debatable. More sophisticated peak-finding functions (in N
> >> dimensions, as opposed to 1) may also be useful to the community, and
> those
> >> would definitely belong in scipy.
> >>
> >
> > I have the feeling this belongs in scipy. Although if it's just these two
> > functions I'm not sure where exactly to put them. Looking at the
> > functionality, this is quite a simple approach. For any data of the type
> I'm
> > usually working with it will not be able to find the right local extrema.
> > The same is true for your alternative definition below.
> >
> > A more powerful peak detection function would be a very good addition to
> >
> http://stackoverflow.com/questions/1713335/peak-finding-algorithm-for-python-scipy
> >
> > Cheers,
> > Ralf
> >
> >
> Actually, such an algorithm would be great to partner with the watershed
> clustering implementation in ndimage.
>
> Ben Root
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110915/779f183f/attachment.html>
```