Evaluate adding screamer to ores.analytics

Table of Contents

This page is a capture in the deferred bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.

What

screamer is a Python library, engineered in C++ (~63% C++, ~34% Python), for quantitative-finance time series analysis — "screamingly fast streaming indicators with C++ performance and Python simplicity." Its defining architectural property, per the docs, is that the same function runs unchanged on a static NumPy array or on a live stream: every function is strictly causal (output depends only on current and past inputs, never future ones), which rules out look-ahead bias by construction rather than by convention. Documented building blocks include rolling statistics, polynomial curve fits over sliding windows (e.g. RollingPoly2, fitting a line per window and returning its slope), directional/sign transforms, and general "technical indicators and signal filters." Benchmarks claim it beats NumPy/pandas equivalents "often by factors of two or more." Installs via pip install screamer; actively maintained (332 commits, 46 releases) but small (5 stars, 1 fork) — worth weighing project maturity/bus-factor against the technical fit before committing to it.

Investigate whether ores.analytics (pricing engines, model configuration/products/parameters — see projects/ores.analytics/modeling/component_overview.org) has a concrete need for streaming rolling-window indicators (e.g. for live risk metrics, real-time exposure/PnL rolling stats, or feeding model calibration with online moving-window statistics) where screamer's causal-by-construction streaming/batch duality would be a genuine fit, versus building bespoke rolling-window code or using an existing C++ dependency already in the stack.

Why

ORE Studio's analytics layer computes model outputs (pricing, risk) that could benefit from correct, fast rolling-window statistics if any future feature needs live/streaming recalculation (e.g. real-time market data feeding continuously-updated exposure or volatility estimates) rather than batch-only computation. screamer's core guarantee — identical code path for batch and streaming, with no look-ahead risk — directly targets the class of bugs that plague hand-rolled rolling-window code (accidentally peeking at future data in a window, or diverging behavior between backtest and live code paths). Worth a spike to confirm whether ORE Studio has (or will soon have) a concrete streaming-analytics use case before adopting a new third-party C++/Python dependency.

References

See also

Emacs 29.3 (Org mode 9.6.15)