Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] gaco hangs when initial population is outside bounds #493

Closed
jschueller opened this issue Dec 7, 2021 · 7 comments
Closed

[BUG] gaco hangs when initial population is outside bounds #493

jschueller opened this issue Dec 7, 2021 · 7 comments
Labels

Comments

@jschueller
Copy link
Contributor

jschueller commented Dec 7, 2021

when some points of the initial population are outside the bounds and the objective tend to make it go outside,
gaco can hang:

#include <pagmo/algorithms/gaco.hpp>
#include <pagmo/population.hpp>
#include <pagmo/problems/rosenbrock.hpp>

using namespace pagmo;

struct problem1 {
    vector_double fitness(const vector_double &x) const
    {
        return {x[1]};
    }
    std::pair<vector_double, vector_double> get_bounds() const
    {
        return {{-1.5, -1.5}, {1.5, 1.5}};
    }
    vector_double::size_type get_nobj() const
    {
        return 1;
    }
};

int main()
{
  try {
    problem prob{problem1{}};

    population pop1{prob, 0, 0};
    int size = 100;
//     std::uniform_real_distribution<double> unif(-1.5, 1.5); // OK
    std::uniform_real_distribution<double> unif(-3., 3.);  // FREEZE
    std::default_random_engine re;
    for (int i=0; i<size; ++i)
    {
      vector_double x(2);
      x[0] = unif(re);
      x[1] = unif(re);
      pop1.push_back(x);
    }

    gaco user_algo1{10u};
    pop1 = user_algo1.evolve(pop1);

	}
	catch(const std::exception & exc) {
		std::cout << "ex="<<exc.what() <<std::endl;
		return 2;
	}
	return 0;
}

more generally, do we have to check is the population is inside the bounds before calling pagmo, or do the algorithms will manage to "jump" inside the bounds ?

@jschueller jschueller added the bug label Dec 7, 2021
@bluescarni
Copy link
Member

Any idea @Sceki ?

more generally, do we have to check is the population is inside the bounds before calling pagmo, or do the algorithms will manage to "jump" inside the bounds ?

As I wrote in the other thread, what happens with out-of-bounds conditions is algorithm-dependent. But in any case it should never lead to a hang/crash, and if it does it's a bug.

@Sceki
Copy link
Member

Sceki commented Dec 8, 2021

I believe that the problem is that this while loop can be endless in case the initial population is out of bounds: https://github.com/esa/pagmo2/blob/master/src/algorithms/gaco.cpp#L855.

I think there are two possibilities: either we avoid the while loop (i.e., the re-sampling until we satisfy the bounds) for the case in which the user decides that out-of-bounds solutions are acceptable, or we simply do not accept initial populations that are out of bounds.
In the former case, we would need to add a boolean flag (similar to the cmaes force_boundsone) and skip that while loop (i.e., the re-sampling) in case that is set to true.

I am a bit busy these days, but I will try to fix it with a PR as soon as possible..

@jschueller
Copy link
Contributor Author

jschueller commented Dec 8, 2021

yes, a simple throw to reject initial populations out of bounds would be the simplest

@bluescarni
Copy link
Member

I believe that the problem is that this while loop can be endless in case the initial population is out of bounds: https://github.com/esa/pagmo2/blob/master/src/algorithms/gaco.cpp#L855.

I think there are two possibilities: either we avoid the while loop (i.e., the re-sampling until we satisfy the bounds) for the case in which the user decides that out-of-bounds solutions are acceptable, or we simply do not accept initial populations that are out of bounds. In the former case, we would need to add a boolean flag (similar to the cmaes force_boundsone) and skip that while loop (i.e., the re-sampling) in case that is set to true.

I am a bit busy these days, but I will try to fix it with a PR as soon as possible..

Cheers!

Do you think it helps algorithmic performance to allow for out-of-bounds individuals? If you think it does not, then I'd personally be more in favour of throwing, rather than adding another configuration parameter.

@Sceki
Copy link
Member

Sceki commented Dec 9, 2021

Indeed, another configuration parameter seems a bit too much, and if the bounds are chosen wide enough the performance should be the same, so I will just throw I guess :)

@jschueller
Copy link
Contributor Author

@Sceki any progress on this ?

@Sceki Sceki mentioned this issue Jul 29, 2024
@Sceki
Copy link
Member

Sceki commented Jul 29, 2024

@bluescarni we can close this.. done in #576 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants