Optional callback after repair and on accept

[n-wouda]

Optional callback after repair and on accept

[N-Wouda]

I've already hacked through the entire ALNS class for my research :-)

😄

[N-Wouda]

I am not opposed to such callbacks, but: what's stopping you from writing your own AcceptanceCriterion that does both?

Minimal example:

from alns.accept import HillClimbing


class MyAcceptanceCriterion(HillClimbing):
    def __call__(..., cand, ...):
        <do after_repair around candidate>

        if accept := super().__call__(..., cand, ...):  # modified candidate was accepted
            <do on_accept around candidate>

        return accept

In both cases you can, as far as I can tell, freely modify the passed-in candidate argument without having to worry about copying anything.

[leonlan]

Nothing is stopping me personally since I've already hacked through the entire ALNS class for my research :-). That's indeed a good suggestion which covers the proposed implementations.

[N-Wouda]

But that's OK. Clearly there's some demand for callbacks and such then - I believed in #30 that there was not. I will leave this issue open to revisit at some point in the near future!

[leonlan]

After some experimenting, I no longer think it's beneficial to have more callbacks in ALNS.

As you said before, the acceptance criterion can be easily modified to apply local search after repair/on accept. This same principle can be also applied directly to destroy/repair operators, e.g., by decorating the operators.

I think it's good to keep the ALNS class as simple as possible. Rather than adding more callbacks to the ALNS class, the current implementation provides enough flexibility for the user to define their own callbacks through the destroy/repair and acceptance criteria interfaces. These use cases can be demonstrated in the documentation/cookbook (#88).

Feel free to close the issue if you agree/have no other remarks.

[N-Wouda]

This same principle can be also applied directly to destroy/repair operators, e.g., by decorating the operators.

I agree. The paper you referenced having a destroy-local search-repair cycle is completely equivalent to (destroy + local search)-repair, or destroy-(local search + repair). I think we are better off not adding all sorts of callbacks for these things into the library, but instead push those ideas off into user code.

These use cases can be demonstrated in the documentation/cookbook (#88).

Sounds like a good idea to me. We can definitely document some common 'callback use cases' there, and the recommended way to do that in the library.

---

I am open to adding new callbacks when something is hard to do currently. But I cannot think of anything right now. So I will wait until there's a concrete use case :-).