<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 28, 2018 at 6:05 AM, Lars G. <span dir="ltr"><<a href="mailto:lagru@mailbox.org" target="_blank">lagru@mailbox.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear SciPy devs,<br>
<span class=""><br>
>> - argrelmax doesn't catch peaks that are wider than one sample. Decide<br>
>> how to deal with this. I have implemented an alternative here which may<br>
>> even be faster. But I plan to make a performance comparison to confirm<br>
>> this. I have a feeling this should be addressed (if wanted) in a new<br>
>> pull request.<br>
<br>
</span><span class="">On 26.01.2018 20:59, Eric Larson wrote:<br>
> Another PR is fine, but we should merge that one before this find_peaks<br>
> PR to avoid creating backward compatibility problems. <br>
<br>
</span>I have prepared a performance evaluation for you to review here:<br>
<a href="http://nbviewer.jupyter.org/urls/gitlab.com/snippets/1695752/raw" rel="noreferrer" target="_blank">http://nbviewer.jupyter.org/<wbr>urls/gitlab.com/snippets/<wbr>1695752/raw</a></blockquote><div><br></div><div>Thanks, such easy to read comparisons are very helpful to evaluate proposed new functionality. </div><div><br></div><div>Regarding the flat peaks issue, I'd have a preference for only a single index being returned. Rationale: </div><div>- whether a peak is considered flat or not can be determined by small amount of noise (either numerical or real)</div><div>- behavior of the function for different inputs should be consistent, changing the number of returned indices will be annoying for users</div><div>Regarding the execution time: that should be only a secondary concern here.</div><div><br></div><div>Ralf</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
You can download the notebook here:<br>
<a href="https://gitlab.com/snippets/1695752" rel="noreferrer" target="_blank">https://gitlab.com/snippets/<wbr>1695752</a><br>
<br>
I hope my approach & evaluation is not to naive. Please let me know</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
whether you think this approach would be a viable alternative to use in<br>
find_peaks. In that case I'd start a new PR to add this functionality<br>
before merging the one we are currently discussing.<br>
<div class="HOEnZb"><div class="h5"><br>
Best regards,<br>
Lars<br>
______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
</div></div></blockquote></div><br></div></div>