[SciPy-Dev] GSoC'21 participation SciPy

Pamphile Roy roy.pamphile at gmail.com
Mon Feb 15 15:51:37 EST 2021


> I'm assuming you mean something like standard multiprocessing, or using a
> custom Pool object, for code that's trivially parallelizable. Both are
> covered by the `workers` pattern. If you're thinking about something else,
> can you elaborate?
Yes the first step would be to do some simple multiprocessing. But IMO we should still try to have something flexible enough
so that we could plug (or the user) something else like a job scheduler. I would not see any scheduling per say in SciPy (totally out of scope and too many options: bash, slurm, kubernetes world, etc.),
but being able to access a queue would be nice. This way you could wrap anything to go take a job form a queue and return a result.

This would need some experiments, but I think that we could achieve something like this just with some simple queue from std lib.
Because I am not sure we would want to introduce, even optionally, a dependency to something like RabbitMQ. (Or maybe…).

> Not sure about EGO in particular (I'm not familiar with it), gaussian
> processes sounds a little out of scope - that's scikit-learn territory
> probably.
True. I am using scikit-optimize for that currently. It just seemed EGO was getting more and more tractions and so I though that maybe
having this in SciPy could be justified. But definitely, other famous algorithms from the list you posted would be good candidates.

> I'm not 100% sure, let's see if someone more familiar with this topic has
> an opinion. In general for new stats functionality we try to figure out if
> it fits better in scipy.stats or in statsmodels. The latter doesn't have
> much either right now, only:
> https://www.statsmodels.org/stable/generated/statsmodels.genmod.generalized_estimating_equations.GEEResults.sensitivity_params.html

I posted several time the suggestion to statsmodels mailing list but so far did get a clear answer.
Hopefully we will have more luck here :)

Agreed for the response surface part. It would be a big undertaking.

Cheers,

Pamphile
@tupui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210215/4cf5fdad/attachment-0001.html>


More information about the SciPy-Dev mailing list