Closed dreinon closed 3 years ago
I have the feeling that minimizing max_end - min_start or minimizing the distance between a set of tasks is the same problem. I mean, the formalization is not the same, but it is the same complexity. The distance between two tasks is something easy to compute, but the distance between n tasks is much more difficult, because you first have to sort tasks according to their start time.
Right, I understand why they have to be sorted. So, you think the implementation would be the same even if we speak about binary (1 if distance is 0, 0 else) instead of just computing pure distance between tasks, right?
Yes I do. Another possibility would be to add the test If(end_task_i==start_task_j, tasks_i_j_contiguous==True, tasks_i_j_contiguous=False)
for all tasks and all cases. If you have n tasks, this would result in n*(n-1)/2 if/then/else tests. At the end, if you have n True, then all tasks are contiguous. You can force the solver to reach n True in an optimization problem.
Or another possible expression: if all tasks are contiguous then all start times and end_times are the same, except the start of the first task and the end of the last task.
Yes I do. Another possibility would be to add the test
If(end_task_i==start_task_j, tasks_i_j_contiguous==True, tasks_i_j_contiguous=False)
for all tasks and all cases. If you have n tasks, this would result in n*(n-1)/2 if/then/else tests. At the end, if you have n True, then all tasks are contiguous. You can force the solver to reach n True in an optimization problem.
Can I make the solver miximize n instead of forcing reaching n?
No you can't.
Le mar. 15 juin 2021 à 12:01, dreinon @.***> a écrit :
Yes I do. Another possibility would be to add the test If(end_task_i==start_task_j, tasks_i_j_contiguous==True, tasks_i_j_contiguous=False) for all tasks and all cases. If you have n tasks, this would result in n*(n-1)/2 if/then/else tests. At the end, if you have n True, then all tasks are contiguous. You can force the solver to reach n True in an optimization problem.
Can I make the solver miximize n instead of forcing reaching n?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tpaviot/ProcessScheduler/issues/60#issuecomment-861365042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFBFISU36CZW455V7S7F6DTS4QHVANCNFSM46JJ4I2A .
Ok.
We found out that what actually counts for us is that the distance between 2 tasks of a resource is 0, and if the distance is anything but 0, then it wouldn't be good for this objective. Therefore, I have thought of a binary variable where the solver gets penalized if distance is not 0 (or maybe rewarded if distance is 0). Also, maybe it could be a parameter of the single resource flowtime objective, for example, if you set parameter force/binary/... to True, the objective adquires this behaviour.