Skip to content
This repository has been archived by the owner on Mar 5, 2019. It is now read-only.

add heuristic callbacks #3

Closed
mlubin opened this issue Jun 12, 2016 · 6 comments
Closed

add heuristic callbacks #3

mlubin opened this issue Jun 12, 2016 · 6 comments
Assignees
Labels
Milestone

Comments

@mlubin
Copy link
Collaborator

mlubin commented Jun 12, 2016

No description provided.

@rschwarz rschwarz changed the title add heuristic and user cut callbacks add heuristic callbacks Jun 13, 2016
@rschwarz
Copy link
Collaborator

Let's split up heuristics and user cuts. I'll be working on heuristics first.

I'm not familiar with heuristic callbacks in the major solvers, but from my experience with SCIP, there's typically three different "locations" where a heuristic might be applied:

  • before the actual solving starts (construction heuristics)
  • after the LP is solved in every node (rounding heuristics etc.)
  • after some solutions was found (improving heuristics, local search)

Should we support all of these use cases?

@rschwarz rschwarz self-assigned this Jun 13, 2016
@mlubin
Copy link
Collaborator Author

mlubin commented Jun 13, 2016

Why are callbacks needed for before the solve starts? Shouldn't the user
just provide the best known starting point?

For the other two cases I'd say there should be a single callback where we
gove some information about the current state and users can choose to run
their heuristic or not.
On Jun 13, 2016 17:40, "Robert Schwarz" notifications@github.com wrote:

Let's split up heuristics and user cuts. I'll be working on heuristics
first.

I'm not familiar with heuristic callbacks in the major solvers, but from my
experience with SCIP, there's typically three different "locations" where a
heuristic might be applied:

  • before the actual solving starts (construction heuristics)
  • after the LP is solved in every node (rounding heuristics etc.)
  • after some solutions was found (improving heuristics, local search)

Should we support all of these use cases?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABp0M4271nn3XEPmw76_K4QO4I5qylgkks5qLcBQgaJpZM4Izzoo
.

@rschwarz
Copy link
Collaborator

rschwarz commented Jun 14, 2016

Good point, setting the initial values. The difference between the other two situations is that the solution available to the solution is known to be feasible, or not (LP relaxation).

However, initial values are not supported by our current interface, I'll open an issue for it.

@mlubin
Copy link
Collaborator Author

mlubin commented Jun 14, 2016

Ok, what about a single heuristic callback that lets the user know if the solution came from an LP relaxation or from a feasible solution?

@rschwarz
Copy link
Collaborator

Yes, that's what I was thinking, too.

@rschwarz rschwarz added this to the 0.1 milestone Jun 16, 2016
@rschwarz
Copy link
Collaborator

I thought that we could distinguish the two cases easily with some HEUR_TIMING
in SCIP. But in fact, we'd probably have to catch some EVENTTYPE_SOLFOUND in order to be called
whenever an improving solution is discovered. Surprisingly no heuristic implemented in SCIP uses that at the moment.

So, for the first iteration, we only support heuristic callbacks that are called on every MIP node.

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

No branches or pull requests

2 participants