Developer Guidelines#
This section provides guidelines for developers contributing to the hidimstat project.
Repository folder architecture#
Here is the general organization of the repository`s folders:
Folder name
What the folder contains
.circleci
The configuration file for the Continuous Integration tool CircleCI.
.github
All configuration files for Github Actions.
docs
All files about the API, User guide, the examples gallery, glossary and notations.
examples
Python files that run for the examples gallery.
src/hidimstat
The Python files of the HiDimStat library.
test
The Python files that run tests on the library.
tools
The developer documentation files.
We give more details about the organization of the src/hidimstat folder:
Folder name
What the folder contains
base
Base variable importance (VI) and perturbation classes, all derived VI and perturbation methods as classes, as well as inference classes.
samplers
Sampling classes.
statistical_tools
Statistical tools for tests, compute p-values, aggregation methods.
visualization
Visualization methods to produce graphs.
_utils
Private folder that contains utility functions and classes for internal usage only.
Writing Conventions#
Naming#
Files should follow the snake case convention, and classes should follow the upper camel case convention. Names should not contain acronyms and should instead include the full version, except for really long names, such as Distilled Conditional Randomization Test abbreviated as D0CRT, or names that are standard in the scientific community, such as LOCO which stands for Leave One Covariate Out. Functions should be written in snake case, and should not contain acronyms similarly to classes.
Classes#
While we do not provide any template for the classes, we try to follow the conventions on
developing scikit-learn estimators.
We recommend that you follow the general style of the BaseVariableImportance class when
implementing other classes. The main addition from scikit-learn’s sklearn.base.BaseEstimator is the
addition of importance and selection methods that allow the selection of variables based on
different criteria.
Citations#
When introducing citations in code documentation, please use the following format:
# :footcite:t: \`nameofthecitation\`
Make sure that the citation name is included in the bibliography and that it is listed in alphabetical order.
Reproducibility and Randomness#
Design choice: numpy.random.Generator#
Hidimstat uses numpy.random.Generator for all randomness because it provides a reliable way to manage separate, reproducible streams of random numbers. The key benefit is the ability to spawn new, independent Generator instances from a single parent.
This is particularly useful for our methods that employ parallel samplers or other algorithms requiring multiple, distinct random streams. Spawning ensures that each parallel process has its own unique sequence of random numbers, preventing interference and guaranteeing that the overall result remains reproducible.
The Generator object for any given method is instantiated by the internal
check_random_state utility function, which handles the logic based on the user’s
input.
The random_state Parameter#
The behavior of a method’s randomness is exclusively controlled by the random_state parameter. It accepts three types of input:
int: An integer input ensures both reproducibility: running the script twice produces identical results, and repeatability: calling the method twice within the same script, such as<method>.importance(), yields the exact same output.numpy.random.Generator: Passing a Generator object provides reproducibility but not repeatability. The stream of random numbers is reproducible if the user seeds their Generator object, but subsequent calls to the method will advance the generator’s state, leading to different results.None: This input provides neither reproducibility nor repeatability. The random numbers are generated from a non-deterministic source, resulting in different outcomes on each run and each call.
Testing#
All methods that involve randomness must include a dedicated test suite. The following test patterns help to ensure consistent behavior:
test_<method>_repeatabilitytest_<method>_randomness_with_nonetest_<method>_reproducibility_with_integertest_<method>_reproducibility_with_rng
Writing Conventions#
Naming#
Files should follow the snake case convention, and classes should follow the upper camel case convention. Names should not contain acronyms and should instead include the full version, except for really long names, such as Distilled Conditional Randomization Test abbreviated as D0CRT, or names that are standard in the scientific community, such as LOCO which stands for Leave One Covariate Out. Functions should be written in snake case, and should not contain acronyms similarly to classes.
Citations#
When introducing citations in code documentation, please use the following format:
# :footcite:t: \`nameofthecitation\`
Make sure that the citation name is included in the bibliography and that it is listed in alphabetical order.