3 ms·
We decided in the end for a custom implementation, although that wasn't the plan at first. A key requirement for us was that the same code had to run in the br
by Sentralis 19d ago
We decided in the end for a custom implementation, although that wasn't the plan at first.
A key requirement for us was that the same code had to run in the browser as well as in a Node worker behind the API and the MCP server and get exactly the same results (i.e. byte equivalence, not just being "close")
So numpy/scipy as the core were out from day one, and every JS dependency became something that could drift between the two builds. Easiest way to stop worrying about that was to have no runtime imports in the engine code at all.
It's less math than it sounds (in particular the system does not yet support derivatives). We just needed Cholesky plus a repair step for near-singular matrices, VaR/CVaR, drawdown, an inverse normal CDF, matrix times vector. Less than a thousand lines for the quant stuff.
The one library we did use was d3-random for the normal draws in the Monte
Carlo. Then it turned out v3 is ESM-only and the backend is CommonJS, and
after a frustrating few days we just copied the Marsaglia polar function
into the repo and wrote a test that checks it against the real package. Seeded with mulberry32, seed is required, no Date.now fallback.
Where libraries do the heavy lifting is upstream: the covariance matrices
(Ledoit-Wolf shrinkage) are precomputed in Python with numpy and
scikit-learn and handed to the engines as inputs.