<div dir="ltr"><table cellpadding="0" class="gmail-cf gmail-An" id="gmail-undefined" style="width:1408px;table-layout:fixed;border-spacing:0px"><tbody><tr><td class="gmail-Ap" style="vertical-align:top;width:1408px;height:100px"><div id="gmail-:4ee" class="gmail-Ar gmail-Au" style="border-radius:1px;box-sizing:border-box;padding:0px 0px 16px;zoom:1;border:0px;margin:0px"><div class="gmail-aO7" style=""><div id="gmail-:4hj" class="gmail-Am gmail-aO9 gmail-Al editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" tabindex="1" style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:1.5;font-family:Arial,Helvetica,sans-serif;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;border:0px;overflow:visible hidden;width:1408px;outline:none;direction:ltr;min-height:85px"></div></div></div></td></tr></tbody></table>On Sun, Apr 11, 2021 at 9:07 AM Pamphile Roy <<a href="mailto:roy.pamphile@gmail.com" target="_blank">roy.pamphile@gmail.com</a>> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><br>On 09.04.2021, at 19:51, Robert Kern <<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">On Fri, Apr 9, 2021 at 1:42 PM Pamphile Roy <<a href="mailto:roy.pamphile@gmail.com" target="_blank">roy.pamphile@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi everyone,<div><br></div><div>I would like to propose to add sensitivity analysis (SA/GSA) functions. Also called uncertainty quantification (UQ) or verification and validation (V&V) depending on the field.</div></div></blockquote><div><br></div><div>SALib is actively developed. I recommend contributing there if there are any gaps that you think need to be filled.</div><div><br></div><div><a href="https://salib.readthedocs.io/en/latest/" target="_blank">https://salib.readthedocs.io/en/latest/</a> </div></div></div></div></blockquote></div><div>In my opinion, the fact that a library exists is not contradictory to adding some functionalities in SciPy. We are discussing about including UNU.RAN which is arguably the same.</div><div>SALib is a nice library, but as a user you will only find it and be willing to use it if you already know about SA. Like all niche products.</div></div></blockquote><div><br></div><div>"It exists elsewhere" isn't my argument. While this is obviously a judgement call, and my opinion isn't necessarily that of anyone else's, I do have a rough rubric in mind when I consider things for inclusion in scipy. The main guiding principle is to make important functionality available to the scientific Python community. If including that functionality in scipy advances that, great, that's an argument for inclusion. But sometimes, inclusion inside scipy is just a neutral move, and I think that's the case here. That's not dispositive, but then we have to go to more specific reasons, like wanting to use the functionality inside other parts of scipy (like QMC in SHGO).</div><div><br></div><div>So to take UNU.RAN as an example, it's an old, relatively unmaintained C library. Its important functionality is <i>not</i> currently available to the scientific Python community. Further, we want to <i>use</i> UNU.RAN internally to provide faster implementations of random sampling for our distributions that lack `_rvs()` methods. In contrast, SALib is actively maintained by a multi-developer team; it's a Python library that uses numpy; it's liberally licensed like scipy; it is used by other projects.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Having it in SciPy (or another project with a wider scope like statsmodels) would allow a greater exposure to the whole scientific community to this problematic. Again, this topic is getting more and more traction and SA is now a recurring theme for industrial applications.</div></div></blockquote><div>> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>We should really consider the positive fallback it could have. Taking scipy.stats.qmc for instance. Now that it’s in, a lot of projects will benefit from this inclusion. Not only they can rely on it, but being SciPy, we also took great care about the design and fixed things which were not that obvious nor even really studied (scikit-optimize, optuna, pydoe, and even SALib all had issues with their QMC implementations).</div><div>Thanks to the implementation and review process, 2 articles got written and SciPy will be presented during a conference to a new community, the QMC community.</div><div>And I believe we could have the same impact here and attract people from the SA community. R is still massively used in both cases.</div></div></blockquote><div><br></div><div><div>The existing packages that did just QMC were often just individual-maintained projects that are not very sustainable. So the higher-level packages that <i>needed</i> QMC often rolled their own to varying degrees of effectiveness. Implementing QMC in scipy in the disciplined and thorough manner that you did means that those projects can now rely on that solid building block. The important thing wasn't necessarily "in scipy" per se, it was the discipline and thoroughness. IMO, SALib has done the discipline and thoroughness just fine outside of scipy.</div></div><div><br></div><div>If the SALib developers expressed interest in merging SALib into scipy, that'd be one thing. But if they are interested in maintaining it as an independent project, I would recommend contributing to it to build on their success instead of starting from scratch. As a tentpole project of the scientific Python community, we want to support the efforts of the whole community, not replace them or absorb them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>In the end, if we don’t want any SA in SciPy, it’s fine but it should be motivated by something other than: it exists elsewhere. Because we are at the point where almost everything exists elsewhere.</div><div>Furthermore, I believe SA matches our scope as we have <span style="color:rgb(51,51,51);font-family:"Open Sans",sans-serif;font-size:15px;background-color:rgb(255,255,255)">various types of analysis of variance (ANOVA)</span> in the roadmap.</div></div>
</blockquote></div><div><br></div>I'm not sure that the connection between ANOVA (at least, the specific tools that are on the roadmap) and SA is apt. You use ANOVA and SA to solve different problems on different objects (datasets vs models, respectively). I'm not sure about the comparison being made here. Some SA techniques do use some ANOVA-like analyses internally on specifically-designed sample points, but I think that's as far as the connection goes. In any case, what's on the roadmap for ANOVA is really just implementing a handful of very standard textbook hypothesis tests.<br clear="all"><div><br></div>-- <br><div dir="ltr">Robert Kern</div></div>