Boundary Conditions

[jolayfield]

High-dimensional searches with the current bounds conditions result in a lot of lost optimization steps where many particles do not move.

Multiple solutions exist to deal with these issues. We want to implement reflective boundary conditions that will keep the particle within the bounds in a way that still samples the whole parameter space.

[ljvmiranda921]

Hi @jolayfield , welcome!

Ok, interesting. I’ve been reading about reflective boundary conditions and it seems a nice feature to have. Looking forward to your pull request! :) Don’t hesitate to ask questions if you’re stuck :)

[jolayfield]

Thanks. I would like to ask a few questions:

1. Is it possible/advisable for us to add a third option to the tuple for bounds so that it would look like (lb, up, bound_type)? Can we make these kinds of decisions as they seem best to us or is it better to ask first so that we don't conflict with other ongoing work?

2. I am not exactly sure how to run/make the test suite. I tried to run the options found on the contributions page, but was not sure whether I implemented them properly. Is it better to hash this out now or wait until we are ready to merge the code?

3. Is this the appropriate place to ask these questions?

Thanks

[ljvmiranda921]

Is it possible/advisable for us to add a third option to the tuple for bounds so that it would look like (lb, up, bound_type)?

1. What is the data type of bound_type? A string? What are the possible options for bound_type? I suggest adding a new parameter during initialization instead of extending the bound tuple. Thus you have:

optimizer = GlobalBestPSO(n_particles=10, dimensions=2, bounds=(lb, ub), bound_type='reflective')

Can we make these kinds of decisions as they seem best to us or is it better to ask first so that we don't conflict with other ongoing work?

It really depends if it breaks the whole API or anything. If you would change something up, better report it here so we can see and test these changes 👍

I am not exactly sure how to run/make the test suite.

2. To run the test suite, simply go inside the pyswarms directory, and in your console, type pytest -v. For example, in your command-line:

$ cd pyswarms # goes inside pyswarms directory
$ pytest -v # runs all tests

Is it better to hash this out now or wait until we are ready to merge the code?

Yes, it's advisable to do tests before opening up a PR so we can just focus on reviewing the code than putting out fires 👍 But if you need help, feel free to ask questions here.

Is this the appropriate place to ask these questions?

3. Yup, just ask questions here!

You're welcome!

[ljvmiranda921]

Hi @jolayfield ! Any updates on this?

We're planning a v.0.3.0 release by the end of August. If this feature won't make it next month, we'll just insert this feature on v.0.4.0. There's no rush, what you just need to do is to update your own master branch.

We're here to help you anytime!

[jolayfield]

Thanks. We just got a working implementation yesterday with my research student. I think there is still some testing to do and we will need to cleanup the input but it is coming along. We will followup when we are sure that things are working properly (hopefully in the next few weeks).

[ljvmiranda921]

This has been a bit stale, closing this for now. I'll open this up again if there are already updates 👍