Good practices in developing a code base apply in every Pull Request. The Good Scientific Code Workshop is worth checking out for this.
- Decide on the outcome space and how the estimator will map probabilities to outcomes.
- Define your type and make it subtype
ProbabilitiesEstimator. - Add a docstring to your type following the style of the docstrings of other estimators.
- If suitable, the estimator may be able to operate based on [
Encoding]s. If so, it is preferred to implement anEncodingsubtype and extend the methodsencodeanddecode. This will allow your probabilities estimator to be used with a larger span of entropy and complexity methods without additional effort. - Implement dispatch for
probabilities_and_outcomesand your probabilities estimator type. - Implement dispatch for
outcome_spaceand your probabilities estimator type. - Add your probabilities estimator type to the table list in the documentation page of probabilities. If you made an encoding, also add it to corresponding table in the encodings section.
You may extend any of the following functions if there are potential performance benefits in doing so:
probabilities. By default it callsprobabilities_and_outcomesand returns the first value.outcomes. By default callsprobabilities_and_outcomesand returns the second value.total_outcomes. By default it returns thelengthofoutcome_space. This is the function that most typically has performance benefits if implemented explicitly, so most existing estimators extend it by default.
You also need to add tests for all functions that you explicitly extended. Not extended functions do not need to be tested.