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

Storing a non-accepted eval on a chain; candidate exchange chains with replacement. #46

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

theloudis
Copy link

  1. Updated set_eval!() to store best value only if eval is accepted. A function evaluation that returns eval.status < 0 will also have eval.value = -1 because of the way the Eval object is initialised. This value is mistakenly saved in the chain if one does not condition on ev.accepted==true, as it is always smaller than anything else on the chain up to that point.

  2. Candidate exchange pairs of chains are chosen WITH replacement according to Baragatti et al (2013) "N pairs of chains are chosen uniformly in all possible pairs with replacement".

A function evaluation that returns eval.status < 0 will also have eval.value = -1 because of the way the Eval object is initialised. This value is mistakenly saved in the chain if one does not condition on ev.accepted==true, as it is always smaller than anything else on the chain up to that point.
According to Baragatti et al (2013), "N pairs of chains are chosen uniformly in all possible pairs with replacement"
@floswald
Copy link
Owner

floswald commented Dec 3, 2019

hi! thanks for the contribution. regarding 1. there is the allAccepted method. I prefer to save all values on the chain. True if you stop after iteration 1, your best value is -1 one. but then you have other problems to deal with :-)

regarding 2., it may be a sensible addition to allow for this to be an option to be set by the user. in my exerpience the algorithm is extremely sensitive to all the related tuning parameters (which I consider this one to be). What worked for them (i.e. resampling) need not work for other applications. i think i set that to false to maximize mixing between chains. if you want to modify the PR to add this as a kw-arg, I'd be happy to accept.

any idea why travis is failing?

@theloudis
Copy link
Author

  1. I see. I adapted the code to my specific application and am not using allAccepted. Nevertheless, in my case, in one chain the objective function returned ev.status < 0 (thus ev.value = -1) in the 200th+ iteration. Then that chain never accepted any other subsequent value (typical ev.value in the range of 10.0-15.0) because -1 was the very best it could get.

  2. I agree, it should be a user-set parameter.

No idea about travis, sorry!

@floswald
Copy link
Owner

floswald commented Dec 3, 2019

then something else seems to be wrong... the algo should not use non-accpepted values to update, that doesn't make much sense:

https://github.com/floswald/SMM.jl/blob/master/src/mopt/AlgoBGP.jl#L312

        eval_old = getLastAccepted(c)

        if eval_new.status < 0
            eval_new.prob = 0.0
            eval_new.accepted = false
        else

@theloudis
Copy link
Author

Thanks Florian.

Regarding 1: Still, if one does not condition on ev.accepted==true, then set_eval!() updates the chain's best value with ev.value even if ev.value is negative, i.e. perhaps from an error in the objective function.

if (ev.value < c.best_val[c.iter-1])
c.best_val[c.iter] = ev.value
c.best_id[c.iter] = c.iter
else
...
end

I would expect that c.curr_val stores ev.value no matter what that is, while c.best_val keeps track of the true best value.

@floswald
Copy link
Owner

floswald commented Dec 4, 2019

I see, that makes sense! There seems to be an issue with this indeed. happy to accept any proposals! :-)

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

Successfully merging this pull request may close these issues.

None yet

2 participants