Coverage

A green check means the data is available for the selected measure; a yellow cell lists the measures that the package supports with that approach instead; and a red cross means the approach is not offered at all. Full details per package are in the "Packages" section below.

Packages and limitations

Excluded packages

Considered for the comparison but not benchmarked, with the reason:

Methodology & fairness

Every implementation is timed on the same pre-generated, byte-identical datasets, so no per-language random number generator can influence the comparison. Only the estimator call itself is measured, which means that reading the data from disk happens before the timer starts and is therefore excluded from the result. Each run discards warm-up calls and then records several timed repetitions, and the mean and standard deviation are pooled across seeds so that the error bars are meaningful. The representative variants use four seeds together with a per-seed time budget, while the remaining parameter sweeps use a single seed.

To keep the comparison fair, the runtimes are pinned to a single thread everywhere. On the Java side JIDT is configured with NUM_THREADS=1, and the numerical libraries in the other languages are restricted through OMP_NUM_THREADS=1, OPENBLAS_NUM_THREADS=1, MKL_NUM_THREADS=1, NUMEXPR_NUM_THREADS=1, RAYON_NUM_THREADS=1 and VECLIB_MAXIMUM_THREADS=1. The Python implementations additionally run with workers=1. All packages use the same seeds, the same input sizes and the same estimator parameters.

With GPU numbers on, infomeasure-rs kernel estimators at the sizes where its GPU path is active use GPU timings on the benchmark adapter (the CI GPU); every other line — other packages and every non-eligible size — keeps its CPU number. So the toggle contrasts infomeasure-rs GPU against the CPU baseline, not a GPU-vs-GPU run: no other profiled toolkit has a comparable single-estimate GPU path (JIDT's CUDA path accelerates surrogate significance testing, not one estimate).

On this page, "discrete" refers to the maximum-likelihood (MLE) estimator only. The full detailed comparison covers all bias-corrected estimators, ordinal patterns, several kernel bandwidths, the KL and KSG families, and the Rényi and Tsallis entropies across parameter scalings, and it is available in the detailed view.

Go to the infomeasure detailed view →

These are the detailed infomeasure-native numbers (Rust vs Python) across every estimator family. Representative variants (discrete MLE, kernel bw=0.5, kNN k=4) use 4 seeds; the remaining parameter sweeps use one seed.

Want to compare infomeasure against the other packages? Go to the cross-package comparison →

Packages and limitations

Discrete MLE runtime vs sample size N at a fixed alphabet size (number of states, alphabet = …). A line ends where that package stopped: its dense table hit the memory cap, or a size exceeded the time budget and larger N was skipped. infomeasure-rs counts into a dense table sized states2 for MI, states3 for CMI/TE and states4 for CTE; above about 10⁶ cells (2²⁰) it switches to a hash-map engine, and those points are marked ▲. There its cost grows with N rather than the alphabet, whereas JIDT stays dense (roughly flat in N, but growing with the alphabet).