This repository was archived by the owner on Nov 9, 2022. It is now read-only.
[in progress] argparse approach #6
Open
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.
All the relevant changes here are in main.py (https://github.com/dronedeploy/dd-ml-segmentation-benchmark/pull/6/files#diff-5bc02cefb3ea9e27f1a6776eabd1935d) -- please ignore the rest.
This is how I wrap my benchmarks for convenience: defaults/hyperparameters are defined in one file and parsed as args (so I can easily modify them from the command line when I run a bunch of experiments, and see them in the run overview--especially for frequently changed params like the model name, the number of epochs, the learning rate...). This config is then passed on to other relevant training/inference steps.
Let me know what you think! I realize this may not be ideal for your setup since you have several different scripts in libs/ that may need different config. I find this strategy the only way to stay sane when running lots of experiments and don't know how other people work without it.
We could extend this approach to cover all the params in libs/training.py at least and do the same for main_keras.py (though then we'd have to consider merging the two main_*.py into one file imo).
Or we could just leave a few of these as an example, so participants can easily create their own command line flags if they choose.