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.