Pythonमध्ये API key शिवाय पुनरुत्पादनीय Backtest
Pythonमध्ये API key शिवाय reproducible backtest चालवा: pinned install आणि deterministic sample data वापरून, एका equity curveच्या मर्यादा प्रामाणिकपणे समजून घ्या.
Pythonमधील पुनरुत्पादित करता येणारा backtest असा असतो की, अनोळखी व्यक्ती तो स्वच्छ मशीनवर पुन्हा चालवू शकते आणि कोणतेही खाते किंवा API key अडथळा न ठरता तुमचे अचूक आकडे पुन्हा मिळवू शकते. बहुतेक tutorials पहिल्याच ओळीवर या कसोटीवर अपयशी ठरतात. कारण live downloadमधून पुढील वाचकाला लेखकाला मिळालेल्या price historyपेक्षा किंचित वेगळा price history मिळतो. या मार्गदर्शकात एक open-source engine, quantjourney-bt आवृत्ती 0.12.4 वर निश्चित केले आहे. त्यानंतर कोणत्याही credentialsशिवाय त्यातील bundled example चालवला आहे. शेवटी real market data वापरून दाखवले आहे की एकच स्वच्छ run तरीही काय सांगू शकत नाही.
बॅकटेस्ट पुनरुत्पादनीय कशामुळे ठरते?
येथे पुनरुत्पादनीयतेचा अर्थ नेमका आणि तपासता येण्यासारखा आहे: दुसरी व्यक्ती स्वच्छ मशीनवर एक command चालवते आणि तुमचे आकडे दशांशापर्यंत पुन्हा मिळवते. दोन सामान्य गोष्टी ही पुनरुत्पादनीयता बिघडवतात.
पहिली गोष्ट म्हणजे code. 0.x आवृत्तीतील library minor releasesमधील compatibilityची कोणतीही हमी देत नाही. एखादे नाव बदलले, default बदलला किंवा columnचा क्रम बदलला, तरी तुमची script चालू राहू शकते आणि नकळत वेगळे परिणाम दाखवू शकते.
दुसरी गोष्ट म्हणजे data. ज्याच्या पहिल्याच ओळीत live download आहे असे tutorial कधीही पुनरुत्पादनीय नव्हते. Vendors इतिहासात बदल करतात, splitsनुसार समायोजन करतात आणि उणिवा नंतर भरून काढतात. त्यामुळे महिनाभरानंतर तीच script वेगळे आकडे दाखवू शकते. बदल codeमध्ये झाला की dataमध्ये, हे नंतर वेगळे ओळखता येत नाही.
या projectमधून अनुकरण करण्यासारखी पद्धत म्हणजे fixed engine version आणि packageमध्येच समाविष्ट असलेल्या छोट्या bundled datasetची सांगड घालणे.
इन्स्टॉलेशनची आवृत्ती निश्चित करा: pip install quantjourney-bt==0.12.4
quantjourney-bt हा Apache License 2.0 अंतर्गत प्रकाशित केलेला QuantJourney backtester आहे आणि त्यासाठी Python 3.11 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. आवृत्ती 0.12.4 ही 21 July 2026 रोजी प्रकाशित झाली. August 2026 मध्ये दस्तऐवजीकरण केलेल्या खालील प्रत्येक commandमध्ये हीच आवृत्ती अभिप्रेत आहे.
Isolated environmentमध्ये काम करा. python3 -m venv .venv ते तयार करते, source .venv/bin/activate त्यात प्रवेश करते आणि python -m pip install -U pip त्यातील installer अपडेट करते. त्यानंतर अचूक आवृत्ती घ्या: pip install quantjourney-bt==0.12.4.
प्रकल्पाच्या दस्तऐवजीकरणात unpinned स्वरूप pip install quantjourney-bt दिले आहे. ==0.12.4 हा भाग तुमची जबाबदारी आहे आणि 0.x आवृत्त्यांमध्ये त्याचे महत्त्व विशेष आहे. पुढील व्यक्तीला सहज सापडेल अशा ठिकाणी ही pin नोंदवा: pip freeze > requirements.txt तुम्ही स्पष्टपणे नमूद न केलेल्या dependencyसह प्रत्येक resolved dependency नोंदवते.
दोन optional extras उपलब्ध आहेत. pip install "quantjourney-bt[wf]" walk-forward आणि optimization उदाहरणांसाठी Optuna जोडते. pip install "quantjourney-bt[data]" benchmarksसाठी वापरला जाणारा yfinance fallback जोडते.
Apache-2.0 परवानगी देणारा licence आहे. तुम्ही code व्यावसायिक वापरासाठी वापरू आणि बदलू शकता. मात्र redistribution करताना licence आणि notice files सोबत ठेवणे आवश्यक आहे. Contributors patent rights स्पष्टपणे प्रदान करतात.
API key शिवाय समाविष्ट SMA उदाहरण कसे चालवावे
या repositoryमध्ये पन्नास चालवता येण्याजोग्या उदाहरण strategiesसोबत launcher script दिली आहे. त्या weight-based path आणि order-based path अशा दोन मार्गांमध्ये विभागलेल्या आहेत. त्यापैकी पाच walk-forward workflows आहेत. ./strategy.sh --list catalog दाखवते. ./strategy.sh example_weights_01_sma_daily --check एकच strategy import करते आणि कोणत्याही dataला स्पर्श करत नाही. Install योग्य असल्याची खात्री करण्याचा हा सर्वात जलद मार्ग आहे.
Demo runसाठी एकच ओळ पुरेशी आहे: ./strategy.sh example_weights_01_sma_daily --sample-data --output /tmp/qj-sample
--sample-data flag हाच मुख्य मुद्दा स्पष्ट करतो. त्यामागील datasetचे projectमध्ये पुढीलप्रमाणे वर्णन केले आहे:
Sample dataset जाणीवपूर्वक लहान आणि पुनरुत्पादित करता येण्याजोगा आहे. Account तयार न करता install checks, report generation आणि engine flow समजून घेण्यासाठी तो उपयुक्त आहे.
Source: quantjourney-bt README, version 0.12.4, 6 August 2026 रोजी वाचलेले.
Run consoleवर निकाल दाखवण्याऐवजी एक directory तयार करतो: summary.txt आणि summary.json, एक metrics.csv, त्याच्या equity_curve.pngसोबत equity_curve.csv, एक dashboard.html, plots/ folder आणि runची configuration नोंदवणारी run_metadata.json file. शेवटची file बहुतेक जण वगळतात. मात्र एक वर्षानंतर निकालाचे audit करता येण्यासाठी तीच सर्वाधिक महत्त्वाची असते.
तयार झालेली metrics प्रामाणिकपणे वाचा. Bundled dataset लहान आणि illustrative आहे. त्यामुळे summary.txtमध्ये छापलेला Sharpe ratio आणि maximum drawdown हे sample fileचे वर्णन करतात. ते कोणत्याही strategyबाबत पुरावा देत नाहीत. त्यांना strategyचा निकाल समजणे ही पहिली चूक ठरते.
या runमधून एक महत्त्वाची खात्री मिळते: install योग्यरीत्या काम करते. Signalपासून target weights आणि reconstructed portfolio valueपर्यंतचा पूर्ण engine flow कोणतेही credential न वापरता तुमच्या machineवर artifacts तयार करतो. वास्तविक historical dataवर backtests करण्यासाठी projectच्या स्वतःच्या data serviceचा credentialed path उपलब्ध आहे. त्या pathचे documentation दिलेले आहे. या walkthroughचा शेवट इथेच होतो—ज्या भागासाठी कोणाकडूनही काहीही आवश्यक नाही.
एकाच in-sample equity curveमधून काय समजत नाही
Sample runमधून एक equity curve तयार होते. प्रत्यक्ष market dataवर मोजल्यास त्या curveमधून काय समजत नाही, ते खाली दिले आहे. हे demo fileवर आधारित नाही.
खालील panelमध्ये example strategyमधील तीच कल्पना वापरली आहे. 20-session moving averageने 50-session moving averageला cross केल्यावर signal घेतला जातो. ही पद्धत SPYवर लागू करून 2017 ते 2025 या कालावधीतील प्रत्येक calendar yearचा निकाल स्वतंत्रपणे दाखवला आहे. प्रत्येक sessionमधील position ही मागील sessionच्या closeवर निश्चित केली जाते. त्यामुळे ruleला त्या वेळी उपलब्ध नसलेल्या संख्येवर trade करावा लागत नाही.
प्रत्येक आकड्यामागील अचूक SQL
WITH daily AS
(
SELECT
toDate(toTimeZone(window_start, 'America/New_York')) AS d,
toFloat64(argMax(close, window_start)) AS px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'SPY'
AND window_start >= '2016-01-01 00:00:00'
AND window_start < '2026-01-01 05:00:00'
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) >= 570
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) < 960
GROUP BY d
),
averaged AS
(
SELECT
d,
px,
avg(px) OVER (ORDER BY d ROWS BETWEEN 19 PRECEDING AND CURRENT ROW) AS fast_ma,
avg(px) OVER (ORDER BY d ROWS BETWEEN 49 PRECEDING AND CURRENT ROW) AS slow_ma,
row_number() OVER (ORDER BY d) AS session_no
FROM daily
),
positioned AS
(
SELECT
d,
px,
if(session_no >= 50 AND fast_ma > slow_ma, 1, 0) AS long_today,
lagInFrame(if(session_no >= 50 AND fast_ma > slow_ma, 1, 0), 1)
OVER (ORDER BY d ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS long_prior,
lagInFrame(px, 1)
OVER (ORDER BY d ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS px_prior
FROM averaged
)
SELECT
toYear(d) AS year,
round((exp(sum(log(if(long_prior = 1, px / px_prior, 1.0)))) - 1) * 100, 1) AS rule_pct,
round((exp(sum(log(px / px_prior))) - 1) * 100, 1) AS hold_pct,
countIf(long_today != long_prior) AS crossover_count
FROM positioned
WHERE px_prior > 0
AND toYear(d) >= 2017
GROUP BY year
ORDER BY yearएकही बदल न केलेला rule, 9 स्वतंत्र वेळा मोजला आहे. इतर काहीही वाचण्यापूर्वी दोन percent columns वरून खाली वाचा. 2017मध्ये ruleने वर्षअखेरीस 16% परतावा नोंदवला, तर त्याच कालावधीत SPY hold केल्यावर 19.4% परतावा मिळाला. 2025मध्ये हेच दोन columns अनुक्रमे 10.4% आणि 16.4% दाखवतात. दोन्ही rowsमधील code एकसारखाच आहे. फक्त window बदलली आहे.
Crossover columnमधून उपलब्ध underlying evidence किती मर्यादित आहे, हे दिसते. 4 position changes 2025मध्ये झाल्याने संपूर्ण वर्षाची equity curve मोजक्या निर्णयांवर अवलंबून असते. त्यामुळे त्याला ठोस result म्हणण्यासाठी हा sample फार लहान आहे.
हेच नियम इतर शेअर्सवरही त्याच प्रकारे काम करतात का?
तारीखांची विंडो बदलणे हा एका वक्राचे विश्लेषण करण्याचा एक मार्ग आहे. दुसरा मार्ग म्हणजे गुंतवणुकीचे विश्व बदलणे. खालील पॅनेलमध्ये मापदंड स्थिर ठेवून 2021 ते 2025 या पाच कॅलेंडर वर्षांत पाच उच्च-तरलता असलेल्या शेअर्सवर हाच नियम लागू केला आहे.
प्रत्येक आकड्यामागील अचूक SQL
WITH daily AS
(
SELECT
ticker,
toDate(toTimeZone(window_start, 'America/New_York')) AS d,
toFloat64(argMax(close, window_start)) AS px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('SPY', 'QQQ', 'AAPL', 'MSFT', 'KO')
AND window_start >= '2020-07-01 00:00:00'
AND window_start < '2026-01-01 05:00:00'
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) >= 570
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) < 960
GROUP BY ticker, d
),
averaged AS
(
SELECT
ticker,
d,
px,
avg(px) OVER (PARTITION BY ticker ORDER BY d ROWS BETWEEN 19 PRECEDING AND CURRENT ROW) AS fast_ma,
avg(px) OVER (PARTITION BY ticker ORDER BY d ROWS BETWEEN 49 PRECEDING AND CURRENT ROW) AS slow_ma,
row_number() OVER (PARTITION BY ticker ORDER BY d) AS session_no
FROM daily
),
positioned AS
(
SELECT
ticker,
d,
px,
lagInFrame(if(session_no >= 50 AND fast_ma > slow_ma, 1, 0), 1)
OVER (PARTITION BY ticker ORDER BY d ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS long_prior,
lagInFrame(px, 1)
OVER (PARTITION BY ticker ORDER BY d ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS px_prior
FROM averaged
)
SELECT
ticker AS symbol,
round((exp(sum(log(if(long_prior = 1, px / px_prior, 1.0)))) - 1) * 100, 1) AS rule_pct,
round((exp(sum(log(px / px_prior))) - 1) * 100, 1) AS hold_pct,
round(avg(long_prior) * 100, 0) AS days_long_pct
FROM positioned
WHERE px_prior > 0
AND d >= toDate('2021-01-01')
GROUP BY symbol
ORDER BY rule_pct DESCQQQ पॅनेलच्या शीर्षस्थानी 40.2% वर आहे, तर तळाच्या ओळीत असलेले KO 3.8% वर येते. days_long_pct स्तंभात प्रत्येक आवृत्तीने संपूर्ण विंडोपैकी किती काळ कोणतीही पोझिशन धारण केली, हे दाखवले आहे; शीर्षस्थानील ओळीसाठी हा आकडा 67% आहे. एकच मापदंड-संच, पाच गुंतवणूक-विश्वे आणि इतका मोठा फरक—म्हणून नंतर विजेता निवडणे, अद्याप न केलेल्या व्यवहाराबद्दल काहीही सांगत नाही.
यापैकी कोणतीही गोष्ट crossoverमध्ये व्यवहार करण्याची शिफारस नाही. Backtestसाठी crossover हे मोजमापाचे साधन आहे आणि आपण मोजत आहोत ते backtestच आहे.
वेट्स बॅकटेस्टमध्ये look-ahead bias कुठे शिरतो
Weights-based engine signalचे रूपांतर target weightsमध्ये करतो, त्या weightsच्या आधारे fillsचे simulation करतो आणि त्यातून मिळालेल्या positionsवरून पोर्टफोलिओचे मूल्य पुन्हा मोजतो. त्रुटी signal आणि weight यांच्यातील जोडणीमध्ये लपलेली असते. आजचा weight आजच्या closeवरून घेतला आणि त्यावर आजचा return मिळवला, तर order दिला गेला असता त्या वेळी उपलब्ध नसलेल्या माहितीवर बॅकटेस्टने व्यवहार केला आहे. यालाच look-ahead bias म्हणतात. यामुळे कोणतीही error दिसत नाही. फक्त सर्व परिणाम अधिक चांगले दिसतात.
खालील panelमध्ये समान SPY इतिहासावर एका नियमाच्या दोन्ही आवृत्त्या चालवल्या आहेत.
प्रत्येक आकड्यामागील अचूक SQL
WITH daily AS
(
SELECT
toDate(toTimeZone(window_start, 'America/New_York')) AS d,
toFloat64(argMax(close, window_start)) AS px
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker = 'SPY'
AND window_start >= '2016-01-01 00:00:00'
AND window_start < '2026-01-01 05:00:00'
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) >= 570
AND (toHour(toTimeZone(window_start, 'America/New_York')) * 60
+ toMinute(toTimeZone(window_start, 'America/New_York'))) < 960
GROUP BY d
),
averaged AS
(
SELECT
d,
px,
avg(px) OVER (ORDER BY d ROWS BETWEEN 19 PRECEDING AND CURRENT ROW) AS fast_ma,
avg(px) OVER (ORDER BY d ROWS BETWEEN 49 PRECEDING AND CURRENT ROW) AS slow_ma,
row_number() OVER (ORDER BY d) AS session_no
FROM daily
),
positioned AS
(
SELECT
d,
px,
if(session_no >= 50 AND fast_ma > slow_ma, 1, 0) AS long_today,
lagInFrame(if(session_no >= 50 AND fast_ma > slow_ma, 1, 0), 1)
OVER (ORDER BY d ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS long_prior,
lagInFrame(px, 1)
OVER (ORDER BY d ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) AS px_prior
FROM averaged
)
SELECT
toYear(d) AS year,
round((exp(sum(log(if(long_prior = 1, px / px_prior, 1.0)))) - 1) * 100, 1) AS next_bar_pct,
round((exp(sum(log(if(long_today = 1, px / px_prior, 1.0)))) - 1) * 100, 1) AS same_bar_pct,
round(abs(exp(sum(log(if(long_today = 1, px / px_prior, 1.0))))
- exp(sum(log(if(long_prior = 1, px / px_prior, 1.0))))) * 100, 1) AS gap_pp
FROM positioned
WHERE px_prior > 0
AND toYear(d) >= 2017
GROUP BY year
ORDER BY year2017 मध्ये prior-session आवृत्तीने 16% नोंदवले, तर same-session आवृत्तीने 17.1% नोंदवले; दोन्हीमध्ये 1.1 percentage pointsचा फरक होता. 2025 मध्ये हे अंतर 1.6 percentage points इतके मोजले गेले. Session कुठे बंद झाला हे आधीच माहीत नसलेल्या machineकडून यापैकी केवळ एकाच columnची निर्मिती होऊ शकते. त्यांच्यातील फरक हा निव्वळ accountingचा परिणाम आहे; त्यामागे कोणतीही कल्पना, कौशल्य किंवा प्रत्यक्ष trade नाही.
Timingच्या प्रश्नावर या engineने स्वतःची भूमिका स्पष्ट केली आहे. ती केवळ आश्वासनापेक्षा अधिक विश्वसनीय आहे:
Openवर fills होताना range-sensitive slippageमध्ये केवळ मागील पूर्ण झालेला bar वापरला जातो आणि volume capacityचा अंदाज lagged observationsवरून घेतला जातो; engine त्या दिवसाचा नंतरचा high, low, close किंवा संपूर्ण दिवसाचा volume वापरत नाही.
स्रोत: quantjourney-bt README, version 0.12.4; 6 August 2026 रोजी पाहिले.
दस्तऐवजीकरण केलेल्या गृहितकाची पडताळणी तुम्ही आधीच install केलेल्या sourceविरुद्ध करता येते. दस्तऐवजीकरण नसलेले गृहितक म्हणजे केवळ अंदाज.
वॉक-फॉरवर्ड अतिरिक्त भाग का उद्देश
WF01 ते WF05 ही वॉक-फॉरवर्ड उदाहरणे [wf] अतिरिक्त भागासह आणि त्याच्या Optuna dependencyसह येतात. वॉक-फॉरवर्ड पद्धतीत इतिहासाच्या एका भागावर parameters बसवले जातात आणि त्यानंतरच्या भागावर त्यांची मोजणी केली जाते. मग ही दोन्ही windows पुढे सरकवून प्रक्रिया पुन्हा केली जाते. Rolling आणि expanding variantsमध्ये फरक असा असतो की fitting window पुढे जाताना सुरुवातीचा जुना data काढून टाकते की नाही. आणखी एका उदाहरणात प्रत्येक boundaryवर purge आणि embargo लागू केले जातात. Seamजवळची observations काढून टाकली जातात. त्यामुळे ज्या sliceवर मोजणी केली जात आहे, त्यात fitted sliceमधील dataची गळती होऊ शकत नाही.
यापैकी कोणतीही पद्धत कमकुवत कल्पनेचे कार्यक्षम trading systemमध्ये रूपांतर करत नाही. ती एका आकड्याऐवजी अनेक आकड्यांचे distribution देते, ज्यावर तुम्ही चर्चा आणि परीक्षण करू शकता. हाच तिचा मुख्य फायदा आहे. त्यानंतरची पायरी अजून live moneyशी संबंधित नाही: प्रत्यक्ष पैशांपूर्वी paper trading backtest संरचनात्मकदृष्ट्या पाहू शकत नाही अशा बाबी मोजते. त्यात सर्वप्रथम simulatorने गृहीत धरलेल्या किमतीजवळ तुमचा order प्रत्यक्षात भरतो का, हे तपासले जाते. तसेच, ज्या दिवशी तुमचा code अपेक्षेप्रमाणे काम करत नाही, त्या दिवशी तो काय करतो यासाठी trading botsसाठी circuit breakers आवश्यक असतात. या सर्वांच्या पायाभूत statisticsसाठी open-source quant trading bookवरील आमच्या notesमध्ये अधिक सखोल माहिती दिली आहे.
वारंवार विचारले जाणारे प्रश्न
API key शिवाय strategyचे backtest करता येते का?
होय. quantjourney-bt --sample-data flagमागे bundled sample dataset देते. त्यातील example strategies कोणतेही account किंवा credentials नसतानाही चालतात. Dataset लहान आणि प्रातिनिधिक आहे. त्यामुळे हा run strategyविषयी पुरावा म्हणून नव्हे, तर install आणि pipeline तपासणी म्हणून पाहा.
Python backtesting packageची version pin का करावी?
0.x versionमधील package minor releasesमधील compatibilityची हमी देत नाही. बदललेला default किंवा नव्याने दिलेले metric याची स्वतंत्र सूचना मिळेलच असे नाही. pip install quantjourney-bt==0.12.4 वापरून version pin करणे आणि requirements fileमध्ये environment नोंदवणे यामुळे आज तयार केलेला result पुढील वर्षीही तो result निर्माण करणाऱ्या engineवर पुन्हा तयार करता येतो.
quantjourney-bt कोणत्या licenceअंतर्गत प्रकाशित केले आहे?
Apache License 2.0. ही licence commercial use आणि modificationला परवानगी देते. Redistribution करताना licence आणि notice files जतन करणे आवश्यक आहे. Contributorsकडून स्पष्ट patent grantही यात समाविष्ट आहे. Version 0.12.4 21 July 2026 रोजी प्रकाशित करण्यात आली असून Python 3.11 किंवा त्यानंतरची आवृत्ती आवश्यक आहे.
मजबूत backtest result म्हणजे strategy काम करते असे म्हणता येते का?
नाही. Backtest हा एका windowमध्ये, एका universeवर केलेला एक measurement असतो. वरील panelsमध्ये एकही बदल न केलेला rule एका tickerवर वेगवेगळे yearly figures आणि पाच namesमध्येही वेगवेगळे figures निर्माण करतो. Walk-forward validation आणि out-of-sample testing याच फरकाचे परीक्षण करण्यासाठी वापरले जातात.
वरील panelsची गणना कशी करण्यात आली
Daily closes हे प्रत्येक तारखेच्या regular sessionमधील शेवटचे minute print आहेत. ते New York clock timeनुसार 9:30 a.m. ते 4:00 p.m. दरम्यान घेतले आहेत. त्यामुळे session length hardcode न करताही लवकर बंद होणारे half days योग्यरीत्या समाविष्ट होतात. Fast averageमध्ये 20 sessions आणि slow averageमध्ये 50 sessions आहेत. दोन्ही simple averages आहेत. प्रत्येक seriesमधील पहिल्या 49 sessionsना warm-up period मानले असून त्या काळात कोणतीही position घेतलेली नाही. Yearly figuresमध्ये rule long असलेल्या sessionsसाठी प्रत्येक sessionमधील close-to-close move compound केला आहे. तुलनेसाठी hold columnमध्ये त्याच वर्षातील प्रत्येक session compound केला आहे. Cross-sectionमधील पाच names सतत history असलेल्या आणि windowमध्ये split नसलेल्या namesमधून निवडली आहेत. त्यामुळे close seriesमध्ये adjustmentची आवश्यकता नाही. Windows भूतकाळात निश्चित केलेली आहेत. त्यामुळे प्रत्येक regenerationवेळी ही panels समान numbers दाखवतात.
येथील प्रत्येक panelखाली त्याचा exact SQL दिलेला आहे. त्यामुळे pinned installप्रमाणे या pageवरील numbersही पुन्हा run करता येतात. स्वतःच्या windowवर एखादा rule मोजण्यासाठी backtest code लिहिण्यापूर्वी Strasmore terminalवर plain Englishमध्ये प्रश्न विचारा.