-
Notifications
You must be signed in to change notification settings - Fork 862
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
respect time_limits better #30
Comments
Maybe we can do this
|
I think we should try to primarily control everything based on time_limits (so assume most users do not specify num_trials). Something like this:
|
Currently the user has to explicitly be aware of both time_limits and num_trials. When I don't specify num_trials, it seems to default to 2 beneath the hood. This is very confusing for me, since when I set time_limits = big number, I expect task.fit() to run lots of trials. Currently task.fit() is basically running for min{ num_trials, time_limits} which is not very intuitive behavior. I think the default behavior outlined in my code above would be much more natural, where whichever of num_trials or time_limits is specified is the one that dictates the behavior of task.fit() |
Why not leveraging soft time limits as previously implemented? |
can you explain soft time limits? |
Ok, I agree that the users only need to specify what they want and the remaining should stay as the default. Soft time limit is different, it means that for the trials already scheduled, we let them run to the end, similar to what we have. |
Resolved in current version |
For num_trials default:
if time_limits < THRESHOLD:
num_trials = 1
where THRESHOLD is something small, say = 1 or 10
The text was updated successfully, but these errors were encountered: