Uninformative error when running a searchjob with valid.every>train.max_epochs #51
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When running some search job (e. g. toy-complex-ax.yaml) with valid.every > train.max.epochs (e. g. --valid.every=11) this raises
Traceback (most recent call last): File "/home/patrick/Desktop/kge/kge.py", line 234, in <module> job.run() File "/home/patrick/Desktop/kge/kge/job/auto_search.py", line 170, in run (self, trial_no, config, self.num_trials, list(parameters.keys())), File "/home/patrick/Desktop/kge/kge/job/search.py", line 72, in submit_task self.ready_task_results.append(task(task_arg, device=self.free_devices[0])) File "/home/patrick/Desktop/kge/kge/job/search.py", line 179, in _run_train_job best["job"], TypeError: 'NoneType' object does not support item deletion
The error is simply raised because best["job"] is still None. Obviously, this is induced by a nonsensical configuration but it could have some relevance: The user could set up a config and wants to try if it runs by simply setting max_epochs=1 without thinking about valid.every (This is what happened to me). The error might be confusing then. Additionally, in a pure training job the same nonsensical usage does not lead to an error.
Fixing this directly in the line where the error occurs leads to more exceptions in ManualSearch/AutoSearch. That's why I thought maybe an easy config check, as I propose, is the most efficient. Obviously, I'm open for no action should be taken at all. In case my fix idea is alright, I would want to know if it is valid in the constructor, as I do it.