Open echo66 opened 6 years ago
Hi @echo66 , Welcome to PySwarms!
I think this would be a great addition to the project! Just a few comments/questions:
pyswarms.backend
? But must also be exposed in our high-level optimizers? (pyswarms.single.base
, pyswarms.single.global_best
). This might also affect our topology classes whenever some neighbors are determined. Any thoughts on which part/s of the codebase this will be implemented?check_random_state
method can be part of the pyswarms.backend.operators
module@ljvmiranda921
random_state
in all methods that use, directly or indirectly, np.random
.Hi @echo66 ,
I haven't studied pyswarms architecture yet. As such, I'm not entirely sure what to answer. I did a quick search for "np.random" and, besides unit test modules/files, these are the...
Looks manageable! Since most operations are happening in the backend
, we just need to change that for the most part. No need to change tests I guess :+1:
Are you saying we should "copy & paste" the method? Or import it from scikit-learn?
I think it's better if we write our own in operators.py
(probably just copying what scikit-learn did). Exposing means that we also add a random_state
option in our optimizers such as in pyswarms.single.GlobalBestPSO
, pyswarms.single.LocalBestPSO
, since they rely to our backend
modules.
I would love to but I can only start it two weeks from now..
No problem! If you're up to it, we'll be waiting, and we'll guide you so don't worry and don't hesitate if you have any questions etc. :tada:
@echo66 , are you still working on it?
How about we fix the random state for a generated swarm? So all the operators can access it. I think this would also make it great for pickling. You could then pickle a swarm and it has the same behaviour regardless of the optimizer used (with the same parameters of course). But you could also argue, that the random state maybe makes more sense to be an attribute of the optimizers as it kind of is a property of the optimization.
A question: Would it be sensible to have separate random seeds for every function/method that uses np.random
? I feel like it wouldn't from a technical point of view but that's just a feeling, maybe there is a software development reason.
What do you think @ljvmiranda921?
What surely has to be implemented is the check_random_state
function.
Is your feature request related to a problem? Please describe. In order to find the exact same minima and to generate the exact same set of particles, right now, we need to use
numpy.random.seed(<INSERT YOUR FAVORITE INTEGER>)
. But this will set the global seed, not just the seed for our (stochastic) procedure.Describe the solution you'd like For every method that uses
numpy.random
or any pseudo-random numbers generator, includerandom_state
as a parameter. To validaderandom_state
, you can use something similar to check_random_state.Describe alternatives you've considered See the first two sections of this issue.
Additional context The current architecture is a leaky abstraction regarding pseudo-random numbers generator. This can be fixed by following the same design used in scikit learn, numpy and scipy.