These are chat archives for bluescarni/pagmo_reborn

16th
May 2016
Dario Izzo
@darioizzo
May 16 2016 17:22
Pensieri sull' algoritmo:
In PaGMO legacy we "learned" two main things concerning the use of algorithms:
  • The need to somehow register the algorithm performances as function evaluations are spent
  • The need to have stopping criteria that allow algorithms to determine their converged state
    The response of PaGMO legacy to these needs where:
  • When possible call the algorithm in a loop with gen=1 or max_iter=1 and record the outcome. Be careful as algorithm may have a state, in which case memory=True was provided as a flag to allow continuation between successive call
  • No uniform stopping criteria was provided and it was left to each algorithm to define his.
In PaGMO reborn we are about to "clone" this behaviour. Is there anything we can improve?
Marcus Märtens
@CoolRunning
May 16 2016 19:07
It could be interesting to give the algorithm a "computational budget" from the beginning. In that case I would not need to manually check if fevals have reached a certain value.
Dario Izzo
@darioizzo
May 16 2016 19:20
Thats in any case going only to be approximated. If I have a generational algorithm I will be enable to stop only after each generation, that is pop.size evaluations. But I agree that this thing of undrstanding how many fevals are made is annoying........
Take DE. gen is a parameter. If we also add a second (a maxfeval budget) these two parameters will essentially have the same effect .... so I guess we have to choose? Or we leave both? Or we make sure that the maxfeval is exact also for pop based algos (requiring some deviation from the normal code .... )
I will soon have a first pop based version of an algorithm, we can then play with the API there and make concrete proposals
Marcus Märtens
@CoolRunning
May 16 2016 19:33
I know it is problematic. More thinking loud here than making proper suggestions.
Francesco Biscani
@bluescarni
May 16 2016 19:45
I think it would be good to have a few stopping criteria defined by default in pagmo. I guess the algorithms would be free to implement them or not, but from a strictly API point of view I would be for something like pagmo::stopping_criteria::max_fevals, pagmo::stopping_criteria::tol, etc. (probably as enums)
regarding the number of objective function evaluations, can't we just query the population problem? how granular/precise does it need to be? can we code the algorithms so that they query the number of fevals every once in a while?
the gen=1 max_iter=1 thing sounds like a hack, with the extra complication of the memory parameter... I hope we can do better than that in the redesign
anyway I have spent the weekend with pybind11 and it has not been pleasant
Francesco Biscani
@bluescarni
May 16 2016 19:50
my takeaway right now is that we should switch back to Boost Python
to be honest the experience with pybind and (to a lesser extent, cereal) makes me appreciate more how good the Boost libraries are
Marcus Märtens
@CoolRunning
May 16 2016 20:01
The comeback of Boost?
Francesco Biscani
@bluescarni
May 16 2016 20:04
it never went away :)