[SciPy-Dev] Sensitivity analysis module proposal

[Ilhan Polat]

 > 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. 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.

Indeed I find both quite niche. I don't have any strong opinions though I
think stats residents should weigh in. I am also fine with having it
somewhere else since SciPy is feeling like becoming a bit StatsPy lately
:)

> it should be motivated by something other than: it exists elsewhere

It's actually quite the reason for many things we considered before. If we
are not going to provide at least as good as SALib, there is no point in
having a half-baked version of it in SciPy. Note that it is super easy to
add things but incredibly hard to take it out later. So I think there must
be a substantial need for this (which I am not aware of) that requires
SciPy level inclusion.




On Sun, Apr 11, 2021 at 3:07 PM Pamphile Roy <roy.pamphile at gmail.com> wrote:

>
>
> On 09.04.2021, at 19:51, Robert Kern <robert.kern at gmail.com> wrote:
>
> On Fri, Apr 9, 2021 at 1:42 PM Pamphile Roy <roy.pamphile at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> 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.
>>
>
> SALib is actively developed. I recommend contributing there if there are
> any gaps that you think need to be filled.
>
> https://salib.readthedocs.io/en/latest/
>
>
> 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.
> 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.
>
> 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.
>
> 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).
> 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.
> 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.
>
> 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.
> Furthermore, I believe SA matches our scope as we have various types of
> analysis of variance (ANOVA) in the roadmap.
>
> Cheers,
> Pamphile
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210411/ebb7c950/attachment-0001.html>