Contact person: C++ Developer for Stock Backtesting System

Phone:Show

Email:Show

Location: Lublin, Poland

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"We are seeking a skilled C++ developer to modify our existing stock backtesting backend system.
The ideal candidate should have experience with C++ and must be very comfortable with modern c++ (templates, classes, build-systems, etc)

Intro to codebase:
[login to view URL]

High level features needed:
- convert to make build system
- strategy will be fed as a JSON graph (We would need to “compile” the JSON into an Atlas AST made of a few new primitives, then let Eigen do the heavy lifting. )
- build a HistoricalData class/module that caches the stock data both on disk and ram
- graph traversal can be done as multi-threaded
- compile to WASM
- test driven design, excellent unit tests and good coverage (googletest)

---

Milestones:
Atlas Repo (we need to fork this):
[[login to view URL]]([login to view URL])

Work needed to do:

1. Implement [login to view URL] in Atlas, with Tests
- [[login to view URL]]([login to view URL])
-. [Expected Returns]([login to view URL]) (must match exactly)
-. Ensure we have tests to track how fast graph can run
2. Switch to Ninja+Cmake; Get rid of QT/GUI, Python interface, etc
3. Create HistoricalData class to lazy-load sock data at runtime (using DuckDB)
-. we can get data from [yahoofinance-huggingface index]([login to view URL])
-. We need to ensure data is always in RAM for fastest backtest
-. But we should cache on local disk to avoid re-downloads
4. Complete Implementation of all nodes and node-tests
-. [Node Logic]([login to view URL])
-. [Tests]([login to view URL])
5. Implement & Test all remaining tests
-. [login to view URL]
-. [login to view URL]
-. Smoke
-. [etc (all tests)]([login to view URL])
6. Speed up graph backtesting using multi-processing
7. Cross-compile to WASM and ensure we can fetch data and run from browser
1. fetching data via the same HistoricalData

Other requirements:


* all code and features written MUST have unit test, and ensure good code-coverage

* we must have high level integration/smoke tests that cover overall basic usage

* performance is critical; each new PR must provide results on performance. e.g.:

* how long it took to backtest 5 years of data...
* cold start (no stock data on disk, none in ram)
* warm start (stock data on disk, not in ram)
* hot start (stok data in ram)
* etc" (client-provided description)