ENH: Update GFDL to accept random states as inputs
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- numpy, python, scikit-learn
- Domain
- machine-learning
Research direction
The payload names no file, so begin by finding where GFDL takes its random seed argument and where it draws the weights and biases. The issue points to scikit-learn's random state handling, including the linked PR, as the model. Done means an integer seed still gives identical results across fits, and a numpy RandomState gives fresh weights and biases on each fit. No test file is named, so check the existing tests for seeding before adding new ones.
Written by the indexing model from the issue text.
Description
The current implementation of GFDL only accepts integers as random seeds. I am proposing we also allow GFDL to accept random states. This is standard for sklearn and it is a feature that has already been implemented in @eiviani-lanl's sklearn PR.
Effect: If multiple iterations of GFDL are initialized and fit on the same data with the same integer random seed, they should return the same results. If multiple iterations of GFDL are initialized with the same numpy random state and then fit on the same data, the weights and biases should be resampled every time GFDL is called.
Motivation: To cross-validate GFDL, it is a recommended practice to resample the weights and biases with each fold (see sklearn documentation). This can be accomplished by initializing a GFDL estimator with a random seed, then feeding it into any of sklearn's cross-validation methods (see here).
This will also be useful during our hyperopt runs; if our cross-validation checks sample over multiple sampled biases/weights, then they will be more robust to changes in the random seed.
- Dominant language
- Python
- Stars
- 3
- Forks
- 6
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lanl/GFDL
-
BUG: `IndexError` when `hidden_layer_sizes` is a scalarPossibly taken @Ashu56376 claimed this 16 days ago. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
MAINT: remove/update cruft in `dependabot.yml`Possibly taken @tylerjereddy claimed this 11 days ago. Openmaintenance
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
continuous integration testing
Difficulty 3/5 1-2 days Newbie friendliness 57/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
pytest-dev/pyfakefs#1367 · 1 comment ·
Maintainers usually reply within 2 days
-
IFEvalG exclude_word_harder misses the keyword next to punctuation, at the start or end of the text, and in other letter casePossibly taken @damienen claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
allenai/open-instruct#2151 ·
Maintainers usually reply within 1 day
-
feat(plan): support convertorLabels and convertorAffinity in Plan resourcePossibly taken @AmenB claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
RedHatQE/openshift-python-wrapper#2849 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 25 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
libnativeapi/nativeapi#21 ·