-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[tune] lazy trials #10802
[tune] lazy trials #10802
Conversation
Open question: Should we remove the |
def next_trials(self): | ||
"""Provides Trial objects to be queued into the TrialRunner. | ||
|
||
Returns: | ||
trials (list): Returns a list of trials. | ||
List[Trial]: A list of trials for the Runner to consume. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah let's remove
# Conflicts: # python/ray/tune/suggest/basic_variant.py # python/ray/tune/suggest/search.py # python/ray/tune/suggest/search_generator.py
…llow infinite samples.
I added the total number of samples to the printout. Also implemented (virtually) infinite samples when |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice! the output looks great too.
Why are these changes needed?
Create Trial objects one by one from search algorithms. This way the scheduled trials get naturally limited by concurrency limits of the searcher (through
ConcurrencyLimiter
) and theTrialRunner
(through resources).Related issue number
#10138
Checks
scripts/format.sh
to lint the changes in this PR.