The estimators in the
anomaly module have a slightly different API. Instead of a
method, each anomaly detector has a
score_one. The latter returns an anomaly score for a given
set of features. High scores indicate anomalies, whereas low scores indicate normal observations.
Note that the range of the scores is relative to each estimator.
Every estimator in
river is a class, and as such inherits from at least one base interface.
These are used to categorize, organize, and standardize the many estimators that
This module contains mixin classes, which are all suffixed by
Mixin. Their purpose is to
provide additional functionality to an estimator, and thus need to be used in conjunction with a
non-mixin base class.
This module also contains utilities for type hinting and tagging estimators.
This module contains adapters for making
river estimators compatible with other libraries, and
vice-versa whenever possible. The relevant adapters will only be usable if you have installed the
necessary library. For instance, you have to install scikit-learn in order to use the
This module contains utilities for merging multiple modeling steps into a single pipeline. Although pipelines are not the only way to process a stream of data, we highly encourage you to use them.
This module contains a collection of datasets for multiple tasks: classification, regression, etc.
The data corresponds to popular datasets and are conveniently wrapped to easily iterate over
the data in a stream fashion. All datasets have fixed size. Please refer to
river.synth if you
are interested in infinite synthetic data generators.
Concept Drift Detection.
This module contains concept drift detection methods. The purpose of a drift detector is to raise an alarm if the data distribution changes. A good drift detector method is the one that maximizes the true positives while keeping the number of false positives to a minimum.
This module is here for testing purposes, as well as providing baseline performances.
This module includes ensemble methods. This kind of methods improve predictive performance by combining the prediction of their members.
This module provides utilities to evaluate an online model. The goal is to reproduce a real-world
scenario with high fidelity. The core function of this module is
allows to evaluate a model via progressive validation.
This module also exposes "tracks". A track is a predefined combination of a dataset and one or more
metrics. This allows a principled manner to compare models with each other. For instance,
load_binary_clf_tracks returns tracks that are to be used to evaluate the performance of
a binary classification model.
benchmarks directory at the root of the River repository uses these tracks.
This module regroups a variety of methods that may be used for performing model selection. An expert learner is provided with a list of models, which are also called experts, and is tasked with performing at least as well as the best expert. Indeed, initially the best model is not known. The performance of each model becomes more apparent as time goes by. Different strategies are possible, each one offering a different tradeoff in terms of accuracy and computational performance.
Expert learning can be used for tuning the hyperparameters of a model. This may be done by creating
a copy of the model for each set of hyperparameters, and treating each copy as a separate model.
utils.expand_param_grid function can be used for this purpose.
Note that this differs from the
ensemble module in that methods from the latter are designed to
improve the performance of a single model. Both modules may thus be used in conjunction with one
This module can be used to extract information from raw features. This includes encoding
categorical data as well as looking at interactions between existing features. This differs from
processing module in that the latter's purpose is rather to clean the data so that it may
be processed by a particular machine learning algorithm.
All the metrics are updated one sample at a time. This way we can track performance of predictive methods over time.
Internal clustering metrics
This submodule includes all internal clustering metrics that are updated with one sample, its label and the current cluster centers at a time. Using this, we can track the performance of the clustering algorithm without having to store information of all previously passed points.
Naive Bayes algorithms.
Also known as lazy methods. In these methods, generalisation of the training data is delayed until a query is received.
Each loss function is intended to work with both single values as well as numpy vectors.
Learning rate schedulers.
The purpose of this module is to modify an existing set of features so that they can be processed
by a machine learning algorithm. This may be done by scaling numeric parts of the data or by
one-hot encoding categorical features. The difference with the
feature_extraction module is that
the latter extracts new information from the data
The module includes tools to iterate over data streams.
Each synthetic dataset is a stream generator. The benefit of using a generator is that they do not store the data and each data sample is generated on the fly. Except for a couple of methods, the majority of these methods are infinite data generators.
Time series forecasting.
This module implements incremental Decision Tree (iDT) algorithms for handling classification and regression tasks.
Each family of iDT will be presented in a dedicated section.
At any moment, iDT might face situations where an input feature previously used to make a split decision is missing in an incoming sample. In this case, the river's trees follow the conventions:
- Learning: choose the subtree branch most traversed so far to pass the instance on.
- In case of nominal features, a new branch is created to accommodate the new category.
- Predicting: Use the last "reachable" decision node to provide responses.
1. Hoeffding Trees
This family of iDT algorithms use the Hoeffding Bound to determine whether or not the incrementally computed best split candidates would be equivalent to the ones obtained in a batch-processing fashion.
All the available Hoeffding Tree (HT) implementation share some common functionalities:
Set the maximum tree depth allowed (
Handle Active and Inactive nodes: Active learning nodes update their own internal state to improve predictions and monitor input features to perform split attempts. Inactive learning nodes do not update their internal state and only keep the predictors; they are used to save memory in the tree (
Enable/disable memory management.
Define strategies to sort leaves according to how likely they are going to be split. This enables deactivating non-promising leaves to save memory.
Disabling ‘poor’ attributes to save memory and speed up tree construction. A poor attribute is an input feature whose split merit is much smaller than the current best candidate. Once a feature is disabled, the tree stops saving statistics necessary to split such a feature.
Define properties to access leaf prediction strategies, split criteria, and other relevant characteristics.
All HTs have the following parameters, in addition to their own, that can be selected
**kwargs. The following default values are used, unless otherwise explicitly stated
in the tree documentation.
||The maximum depth a tree can reach. If
||If True, only allow binary splits.||
||The maximum size the tree can reach, in Megabytes (MB).||
||Interval (number of processed instances) between memory consumption checks.||
||If True, stop growing as soon as memory limit is hit.||
||If True, disable poorly descriptive attributes to reduce memory usage.||
||If True, enable merit-based tree pre-pruning.||
This module implements the Attribute Observers (AO) (or tree splitters) that are used by the iDTs. AOs are a core aspect of the iDT construction, and might represent one of the major bottlenecks when building the trees. The correct choice and setup of a splitter might result in significant differences in the running time and memory usage of the iDTs.
Splitters for classification and regression trees can be differentiated by using the property
True for splitters designed to classification tasks). An error will be raised
if one tries to use a classification splitter in a regression tree and vice-versa.
Utility classes and functions.
Mathematical utility functions (intended for internal purposes).
A lot of this is experimental and has a high probability of changing in the future.
Helper functions for making things readable by humans.