<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Apr 21, 2018 02:41, "Matthew Brett" <<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail-m_8554979976141623864quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<div class="gmail-m_8554979976141623864quoted-text"><br>
<br>
On Sat, Apr 21, 2018 at 1:12 AM, Warren Weckesser<br>
<<a href="mailto:warren.weckesser@gmail.com" rel="noreferrer" target="_blank">warren.weckesser@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Apr 20, 2018 at 9:22 AM, Eric Larson <<a href="mailto:larson.eric.d@gmail.com" rel="noreferrer" target="_blank">larson.eric.d@gmail.com</a>><br>
> wrote:<br>
>>><br>
>>> Do any of you have suggestions for issues we could work on?   I'd love<br>
>>> to hear any suggestions.<br>
>><br>
>><br>
>> One option would be to suggest that each interested participant open the<br>
>> SciPy issues and PRs list, and then sub-select based on the `label`<br>
>> corresponding to a submodule they might be interested in. That way people<br>
>> will gravitate toward domains where they have knowledge and feel<br>
>> comfortable, and it cuts down on the number of issues they need to look at<br>
>> (because we have so many).<br>
>><br>
>> And of course there is also the "good first issue" label, which can be<br>
>> useful even if it's inconsistently applied.<br>
>><br>
><br>
><br>
> One of those issues is <a href="https://github.com/scipy/scipy/issues/7168" rel="noreferrer noreferrer" target="_blank">https://github.com/scipy/<wbr>scipy/issues/7168</a>.  There<br>
> are hundreds of function in the library that do not have an "Examples"<br>
> section.  It would be great to bring that number down.  Adding some examples<br>
> could be a good way to get folks started with the SciPy development work<br>
> flow (building the library, building the docs, and making pull requests).<br>
> If you pursue this, be sure that everyone is aware of PEP 8<br>
> (<a href="https://www.python.org/dev/peps/pep-0008/" rel="noreferrer noreferrer" target="_blank">https://www.python.org/dev/<wbr>peps/pep-0008/</a>) and knows where to find the<br>
> docstring standard<br>
> (<a href="https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard" rel="noreferrer noreferrer" target="_blank">https://numpydoc.readthedocs.<wbr>io/en/latest/format.html#<wbr>docstring-standard</a>).<br>
<br></div>
Excellent suggestion, thanks.  I'll offer that as a fall-back, and<br>
maybe as a first hurdle, before trying something with more meat.<br>
<br>
Cheers,<br>
<br>
Matthew</blockquote></div><br><div dir="auto">A pet peeve of mine, but I know there has been some work
 on getting the scipy.signal.fftconvolve function to broadcast across 
dimensions [1], instead of only working with vectors.  However, it has 
never been completed.  <div dir="auto"><br></div><div dir="auto">This is
 a particularly important case because it is a necessary prerequisite 
for an implementation of the overlap-add convolution algorithm [2], one 
of the more critical basic signal processing algorithms that scipy still
 lacks.  It \provides a massive performance boost when you have two 
large (both >= ~500 samples) but different-sized vectors.<br><br></div><div>So
 although getting the overlap-add method implemented is probably too 
much, just allowing applying the 1D fftconvolve across dimensions might 
be within in reason.  The advantage for the hackathon is that it provides the groundwork for a big improvement, but shouldn't require any serious signal-processing knowledge, since the actual algorithm is already implemented.  This just requires implement the dimension-handling logic.<br></div></div><div class="gmail_extra"><br>[1] <a href="https://github.com/scipy/scipy/issues/3525">https://github.com/scipy/scipy/issues/3525</a><br>[2] <a href="https://en.wikipedia.org/wiki/Overlap-add_method">https://en.wikipedia.org/wiki/Overlap-add_method</a></div><br></div></div>