You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like you to give a second thought about the idea of adding the deadline as part of the instance data. I agree that ideally, an instance should contain everything a solver needs to know to solve an instance. However, there is also the issue of replication: we would like to run the same instance later for debugging, backtesting, etc. So having a hardcoded deadline means that the solver will instantly time out because that time will be in the past.
Suggested solution
The idea of going from time limit to deadline is great, but I am not fan of adding it to the json. I think this a good example solved by a query parameter.
Alternatives
Add yet another parameter to the solver --ignore-time-limit-in-the-auction-file, and then another --time-limit to force a time limit.
Bump the time-limit if it is the past. I had some issues with instances arriving at my node already after the time limit, so I don't think this is a good idea.
The text was updated successfully, but these errors were encountered:
Problem
I'd like you to give a second thought about the idea of adding the deadline as part of the instance data. I agree that ideally, an instance should contain everything a solver needs to know to solve an instance. However, there is also the issue of replication: we would like to run the same instance later for debugging, backtesting, etc. So having a hardcoded deadline means that the solver will instantly time out because that time will be in the past.
Suggested solution
The idea of going from time limit to deadline is great, but I am not fan of adding it to the json. I think this a good example solved by a query parameter.
Alternatives
The text was updated successfully, but these errors were encountered: