feat: adding edge-finding for disjunctive #141
Conversation
pumpkin-solver/src/propagators/disjunctive/disjunctive_propagator.rs
Outdated
Show resolved
Hide resolved
|
Also run a benchmark to see the performance implications compared to decomposition |
I have ran benchmarks on some MiniZinc challenge/MiniZinc benchmark repository instances with these results:
It is a limited dataset and, of course, on some instances there is a deterioration but these results indicate that it can be beneficial to make use of the disjunctive propagator. It could also indicate that for other instances we need different reasoning (e.g. detectable precedences) |
github-actions
bot
dismissed
maartenflippo’s stale review
Review re-requested
| use crate::propagators::disjunctive_task::ArgDisjunctiveTask; | ||
|
|
||
| #[test] | ||
| fn propagator_propagates_lower_bound() { |
There was a problem hiding this comment.
Since we use a view to update the upper-bounds!
| /// # Bibliography | ||
| /// \[1\] P. Vilím, ‘Filtering algorithms for the unary resource constraint’, Archives of Control | ||
| /// Sciences, vol. 18, no. 2, pp. 159–202, 2008. | ||
| pub(crate) struct Disjunctive<Var: IntegerVariable + 'static> { |
There was a problem hiding this comment.
Don't specify bounds on struct definitions. Or is there a reason why they exist here? DisjunctiveTask also does not enforce a trait bound.
| /// TODO: this explanation could be lifted and should take into account which subset of tasks was | ||
| /// responsible for the propagation itself. |
There was a problem hiding this comment.
Clarify why this is not done yet
There was a problem hiding this comment.
I have added it now and I am running experiments again to see the impact!
| let reverse_tasks = self | ||
| .tasks | ||
| .iter() | ||
| .map(|task| DisjunctiveTask { | ||
| start_variable: task.start_variable.offset(task.processing_time).scaled(-1), | ||
| processing_time: task.processing_time, | ||
| id: task.id, | ||
| }) | ||
| .collect::<Vec<_>>(); |
There was a problem hiding this comment.
Can this not be done once, in Disjunctive::new?
| /// # Bibliography | ||
| /// \[1\] P. Vilím, ‘Filtering algorithms for the unary resource constraint’, Archives of Control | ||
| /// Sciences, vol. 18, no. 2, pp. 159–202, 2008. | ||
| #[allow(dead_code, reason = "Will be part of the public API")] |
There was a problem hiding this comment.
Which parts are now dead_code? And will this be part of the public API? It seems like an implementation detail of the Disjunctive propagator.
This is enforced by the fact that everything on ThetaTree is pub(super).
There was a problem hiding this comment.
The ThetaTree is currently not constructed since we only create a ThetaLambdaTree.
It depends a bit, currently, it is only used in the Disjunctive but we might consider making a generic ThetaTree which is also applicable for the cumulative
Currently, we decompose the disjunctive
This PR aims to address this by implementing edge-finding based on this PhD thesis. Any feedback would be appreciated!
TODOS