लेख की विषय-सूची
- साक्ष्य और दायरा
- चित्रण
- प्रक्रिया
- कई स्केल और कई टाइमफ्रेम अलग-अलग डिज़ाइन हैं
- उपलब्धता के आधार पर जुड़ें, ओरिजिनल एक्सट्रीम के आधार पर नहीं
- न्यूमेरिकल टाइमिंग और एक वैलिड सेटअप जो फिर भी हार जाता है
- हर स्केल की भूमिका और एंकर को फ़्रीज़ करें
- एक ही वॉल्यूम को बार-बार न गिनें
- हायर-टाइमफ़्रेम कॉन्टेक्स्ट की इंक्रीमेंटल वैल्यू को मापें
- आम गलतियाँ
- व्यावहारिक जाँच सूची
- अक्सर पूछे जाने वाले प्रश्न
- शोध स्रोत
साक्ष्य और दायरा
टेक्निकल रेफरेंस टाइमफ्रेम, हायर-टाइमफ्रेम डेटा और टेम्पोरल जॉइन के बारे में बताते हैं। वे यह साबित नहीं करते कि ज़्यादा टाइमफ्रेम जोड़ने से अपने आप विन रेट या प्रॉफिटेबिलिटी बेहतर होती है।
व्यावहारिक कार्यप्रवाह
- अलग से गणना करेंहर टाइमफ्रेम के अपने बार, पिवट और कैलेंडर होते हैं।
- रिकॉर्ड उपलब्धताकन्फर्मेशन और डिलीवरी में देरी शामिल करें।
- पीछे की ओर जुड़ेंसबसे नए कॉन्टेक्स्ट का इस्तेमाल करें जो पहले से पता हो।
- उम्मीदवार को फ़्रीज़ करेंबड़ा स्ट्रक्चर ज़ोन को बताता है; छोटा स्ट्रक्चर टाइमिंग को बताता है।
- अतिरिक्त मूल्य मापेंसिर्फ़ कम टाइमफ़्रेम वाले बेसलाइन से तुलना करें।
कई स्केल और कई टाइमफ्रेम अलग-अलग डिज़ाइन हैं
मल्टीपल स्केल का मतलब हो सकता है कि एक ही H=1 सीरीज़ पर 2, 5 और 10 के पिवट रेडियस चल रहे हों। मल्टीपल टाइमफ्रेम का मतलब है H=1, H=4 या डेली बार को अलग-अलग कैलकुलेट करना। ये एक जैसे नहीं हैं: चार H=1 बार को H=4 में जोड़ने से उनका अंदरूनी सीक्वेंस खत्म हो जाता है। आठ रेडियस वाले H=1 पिवट का दो रेडियस वाले H=4 पिवट से मैच होना ज़रूरी नहीं है।
TradingView बार टाइमफ्रेम [1] को बताता है और कन्फर्म्ड हायर-टाइमफ्रेम रिक्वेस्ट [2] को समझाता है। प्रस्तावित प्रोटोकॉल H=4 को सिर्फ़ कॉन्टेक्स्ट के लिए और H=1 को सिर्फ़ ट्रिगरिंग के लिए असाइन करता है। कोई ट्रेड ऐसा टाइमफ्रेम नहीं चुन सकता जो उसके हिस्टॉरिकल नतीजे को सबसे ज़्यादा भरोसेमंद लगे।
तय करें कि कॉन्टेक्स्ट का क्या योगदान होना चाहिए। यह एक दिशा, एक रेफरेंस ज़ोन या एक वोलैटिलिटी रिजीम की पहचान कर सकता है। तीनों को तुरंत मिलाने से यह पता लगाना मुश्किल हो जाता है कि कौन सा हिस्सा मदद करता है। एक रोल से शुरू करें, कम-टाइमफ्रेम बेसलाइन से तुलना करें और सिर्फ़ एक रजिस्टर्ड एक्सपेरिमेंट के तौर पर कॉम्प्लेक्सिटी जोड़ें।
उपलब्धता के आधार पर जुड़ें, ओरिजिनल एक्सट्रीम के आधार पर नहीं
हर पिवट को occurred_at, confirmed_at और available_at की ज़रूरत होती है। आखिरी फ़ील्ड में ज़रूरी होने पर डेटा-डिलीवरी और प्रोसेसिंग में देरी शामिल होती है। H=1 डिसीजन टाइम t पर, सिर्फ़ H=4 स्टेट का इस्तेमाल करें जिसका available_at≤t हो। H=4 पिवट के लिए r=2 की ज़रूरत होने पर, एक्सट्रीम बार क्लोजिंग काफ़ी नहीं है: दो और H=4 बार भी क्लोज होने चाहिए।
pandas का backward merge_asof दाएं का सबसे नया रिकॉर्ड चुनता है जिसका समय बाएं की कुंजी से बाद का न हो, यानी बराबर समय भी शामिल है। [3] available_at पर जोड़ें, इंस्ट्रूमेंट और वेन्यू से समूह बनाएं, समय क्रम में छांटें और अधिकतम संदर्भ आयु लगाएं। निकटतम मिलान भविष्य का अवलोकन चुन सकता है, इसलिए इस कारणानुसार खोज के लिए उचित नहीं है।
बराबर टाइमस्टैम्प के लिए एक साफ़ इवेंट ऑर्डर की ज़रूरत होती है। या तो H=4 अपडेट H=1 के फ़ैसले से पहले पूरा हो जाता है, या प्रोसेसिंग में देरी की वजह से यह बाद में ही उपलब्ध होता है। वॉल-क्लॉक इक्वलिटी यह साबित नहीं करती कि डेटा इस्तेमाल करने लायक था। साथ ही, लेटेस्ट रॉ H=4 पिवट अपडेट को ज़रूरी कन्फ़र्म्ड हाई और लो वाली पूरी स्ट्रक्चरल स्टेट से अलग करें।
for each closed H1 bar t:
h4 = latest_state(where available_at <= t, same_instrument=True)
if h4 is None or h4.age > max_context_age: continue
up = h4.H2 > h4.H1 + eps and h4.L2 > h4.L1 + eps
near_support = abs(H1.low[t] - h4.last_low) <= zone_width
if up and near_support: create_frozen_candidate(h4.anchor_ids, t)
if candidate and H1.close[t] > candidate.micro_high + buffer:
emit(signal_at=t, context_available_at=h4.available_at)
# Use only a micro_high confirmed before the trigger.
न्यूमेरिकल टाइमिंग और एक वैलिड सेटअप जो फिर भी हार जाता है
मान लीजिए कि H=4 बार जिसमें लो है, 12:00 पर बंद होता है और पिवट को दो राइट-साइड बार की ज़रूरत है जो 16:00 और 20:00 पर बंद होते हैं। वह लो 13:00 पर H=1 ऑर्डर को सपोर्ट नहीं कर सकता है। यह 20:00 डेटा उपलब्ध होने के बाद ही कॉन्टेक्स्ट में आता है। अगर डिलीवरी में दो सेकंड लगते हैं, तो 20:00:00 पर फ़ैसला अभी भी पुरानी स्थिति का इस्तेमाल करना होगा।
सिंथेटिक वैलिड सेटअप: पहले से पता H=4 का हाई 110→116 और लो 100→105 है। एक प्रपोज़्ड सपोर्ट ज़ोन 104.7–105.3 है। H=1, 105.1 को टच करता है और बाद में 106.2 पर बंद होता है, जो पहले से कन्फर्म्ड माइक्रो हाई 106 से ऊपर है। 106.3 पर एंट्री, स्टॉप 104.7 के साथ, प्लान्ड रिस्क के 1.6 पॉइंट हैं; 109.5 पर रिसर्च टारगेट कॉस्ट से पहले 2R है।
विफलता पथ: H=1 ब्रेकआउट होता है लेकिन बाद में कीमत104.7से नीचे निकल जाती है। H=4 अपट्रेंड ज्ञात इतिहास का वर्णन था,105टिकने की गारंटी नहीं। नुकसान के बाद H=8चुनकर संदर्भ मंदी का बताना परिणाम देखकर नियम बदलना होगा।
एक टाइमिंग फिक्स्चर को H=4 available_at टाइमस्टैम्प से कुछ सेकंड पहले और बाद में उसी H=1 ट्रिगर को मूव करना चाहिए। अलाउड कॉन्टेक्स्ट सिर्फ़ डिक्लेयर्ड बाउंड्री पर ही बदलना चाहिए। एक और फिक्स्चर जिसमें H=4 बार मिसिंग है, उसे गैप रिकॉर्ड किए बिना बाद में पूरे किए गए बार को सब्स्टीट्यूट करने के बजाय नए पिवट को अनकन्फर्म रखना चाहिए।
हर स्केल की भूमिका और एंकर को फ़्रीज़ करें
एक पूरा कॉन्फ़िगरेशन बड़े स्केल को एक ज़ोन, छोटे स्केल को एक ट्रिगर और एक पहले से तय स्टॉप पॉलिसी देता है। एक छोटे स्केल का स्टॉप एक कम शुरुआती रिस्क डिस्टेंस बना सकता है लेकिन बड़े स्ट्रक्चर के अंदर आम मूवमेंट के लिए कमज़ोर हो सकता है। एक बड़े स्केल का स्टॉप पोजीशन का साइज़ और अक्सर होल्डिंग टाइम बदलता है। इनमें से किसी को भी हर ट्रेड के लिए पीछे से नहीं चुनना चाहिए।
उम्मीदवार बनाते समय संदर्भ एंकर ID, कीमत, ज़ोन चौड़ाई, संदर्भ उपलब्धता और उसी समय तक पुष्ट छोटे टाइमफ्रेम का माइक्रो हाई सहेजें। तय नियम के अनुसार नया संदर्भ ऐसे उम्मीदवार को रद्द कर सकता है जिसका आदेश अभी निष्पादित नहीं हुआ, लेकिन पुराने सिग्नल के कारण नहीं लिख सकता।
स्यूडोकोड संरचना का खाका है: उम्मीदवार सक्रियण और ट्रिगर मूल्यांकन के अलग समय हों। सख्त बाद-के-बार संस्करण में t>candidate.created_at और निर्माण समय तक पुष्ट माइक्रो हाई चाहिए। यदि निर्माण बार पहले ही उस हाई को पार कर चुका है तो नियम तय करें: पुराने उम्मीदवार को अस्वीकार करें या तत्काल सक्रियण का अलग संस्करण दर्ज करें।
बीते हुए ट्रेडिंग टाइम या H=1 बार में TTL सेट करें। बहुत पुराना H=4 स्टेट नया सबूत नहीं है, क्योंकि यह अभी भी लेटेस्ट रिकॉर्ड है। कॉन्टेक्स्ट एक्सपायरी, मिसिंग डेटा और असली बेयरिश ट्रांज़िशन के लिए अलग-अलग रीज़न कोड होने चाहिए ताकि हर पॉलिसी से होने वाले अपॉर्चुनिटी लॉस को मापा जा सके।
एक ही वॉल्यूम को बार-बार न गिनें
H=4 वॉल्यूम में उसके भीतर के H=1 बार की गतिविधि शामिल है। इसलिए H=1और H=4 वॉल्यूम की वृद्धि दो स्वतंत्र अवलोकन नहीं हैं। स्कोर पूरी शर्तें गिन सकता है, लेकिन मनमाने भार उसे जीत की कैलिब्रेटेड संभावना नहीं बना देते।
एक ज़्यादा फोकस्ड फ़ीचर H=1 पुलबैक एक्टिविटी की तुलना उसी समय के H=1 बेसलाइन से करता है, जबकि H=4 स्ट्रक्चर को फ़्रीज़ छोड़ देता है। अगर पार्शियल H=4 वॉल्यूम इस्तेमाल किया जाता है, तो इसे उसी बीते हुए मिनटों के बाद हिस्टॉरिकल पार्शियल वॉल्यूम से कम्पेयर करें। पूरे हिस्टॉरिकल H=4 वॉल्यूम की तुलना अभी खुले हुए H=4 बार से ठीक से नहीं की जा सकती।
इनपुट शेड्यूल उतना ही मायने रखता है जितना फ़ॉर्मूला। वॉल्यूम रिपेयर, डिलेड बार और अलग-अलग सेशन डेफ़िनिशन के कारण एक ही नॉमिनल H=4 पीरियड चार लोकल H=1 बार से अलग तरह से एग्रीगेट हो सकता है। किसी भी कन्फ़र्मेशन को इवैल्यूएट करने से पहले एग्रीगेशन प्रोवेंस को रखें और टोटल को इंटीग्रिटी चेक के तौर पर कम्पेयर करें।
एब्लेशन में समान उम्मीदवार और निष्पादन नियम रखकर एक समय पर एक वॉल्यूम विशेषता जोड़ें। जांचें कि दिन के समय, अस्थिरता और तरलता का नियंत्रण करने पर सुधार रहता है या नहीं। कई हरी वॉल्यूम स्थितियों को स्वतंत्र पुष्टि देने वाला मानकर न चलें।
हायर-टाइमफ़्रेम कॉन्टेक्स्ट की इंक्रीमेंटल वैल्यू को मापें
एक जैसे H=1 डिटेक्टर की तीन ब्रांच में तुलना करें: कोई कॉन्टेक्स्ट फ़िल्टर नहीं, सिर्फ़ H=4 डायरेक्शन, और H=4 डायरेक्शन प्लस उसके ज़ोन से नज़दीकी। रिस्क, एग्ज़िक्यूशन और टेस्ट की तारीखें एक जैसी रखें। रिजेक्ट हुए सिग्नल काउंट, एक्सपोज़र और नेट एक्सपेक्टेंसी की रिपोर्ट करें क्योंकि फ़िल्टर सिर्फ़ ट्रेड के सबसेट को बदलकर विन रेट को बेहतर बना सकता है।
H=4 बाउंड्री, शेड्यूल्ड क्लोजर, डेलाइट-सेविंग चेंज और मिसिंग ऑब्जर्वेशन पर फिक्स्चर चलाएं। डेटा-रिसीप्ट ऑर्डर में रीप्ले करें और बैच टेम्पोरल जॉइन से तुलना करें। अगर बैच प्रोसेसिंग रीप्ले से पहले H=4 स्ट्रक्चर की पहचान करती है, तो दूसरा इंडिकेटर जोड़ने से पहले जॉइन को रिपेयर करें।
सिंगल-टाइमफ्रेम, मल्टीपल-स्केल बेसलाइन की भी तुलना करें। इसका आसान सिंक्रोनाइज़ेशन दूसरे बार कैलेंडर की ज़रूरत के बिना ज़्यादातर साफ़ फ़ायदों को समझा सकता है। टाइमफ्रेम पेयर और मैक्सिमम-एज सेटिंग्स को रिसर्च ट्रायल के तौर पर रजिस्टर करें, और फ़ाइनल टेस्ट से पहले उन्हें फ़्रीज़ करें।
पुराने कॉन्टेक्स्ट फेलियर को वैलिड-कॉन्टेक्स्ट लॉस वाले ट्रेड से अलग रिपोर्ट करें। पहले वाले में सिंक्रोनाइज़ेशन या एक्सपायरी पॉलिसी की समस्या दिख सकती है; दूसरे वाले में हाइपोथीसिस की प्रेडिक्टिव वैल्यू की चिंता होती है। क्लियर क्लासिफिकेशन हर नुकसान को दूसरा स्केल चुनकर समझाने से रोकता है।
आम गलतियाँ
H1 को अंतिम H4 क्लोज समय से पहले देना
पूरी हुई H=4 वैल्यू को उसके सभी हिस्से H=1 बार में आगे भरने से जानकारी लीक हो जाती है।
पिवट विलंब को अनदेखा करना
एक H=4 बार बंद होने पर भी वह चरम पिवट पुष्ट नहीं होता जिसे दाईं ओर अतिरिक्त बार चाहिए।
घाटे वाले ट्रेड के बाद संदर्भ बदलना
इवैल्यूएशन पीरियड से पहले का कॉन्टेक्स्चुअल टाइमफ्रेम चुनें और फेल हुए कॉन्फ़िगरेशन को बनाए रखें।
इस विधि का उपयोग करने से पहले जाँच सूची
अपने डेटा पर सत्यापन के बाद प्रत्येक मद पर निशान लगाएँ। प्रगति इसी ब्राउज़र में सहेजी जाती है; यह रणनीति के लाभदायक होने का प्रमाणपत्र नहीं है।
अक्सर पूछे जाने वाले प्रश्न
क्या तीन बुलिश टाइमफ्रेम किसी सिग्नल को तीन गुना ज़्यादा मज़बूत बनाते हैं?
नहीं। वे एक ही अंडरलाइंग प्राइस पाथ शेयर करते हैं। इंक्रीमेंटल जानकारी और किसी भी प्रोबेबिलिटी कैलिब्रेशन को सैंपल से बाहर मापा जाना चाहिए।
क्या आसानी के लिए एक टाइमफ्रेम बेहतर है?
कई स्केल वाला एक सिंगल टाइमफ्रेम एक उपयोगी बेसलाइन है। सिर्फ़ एक तय मकसद के लिए एक और टाइमफ्रेम जोड़ें और टेस्ट करें कि क्या इससे संबंधित नतीजे बेहतर होते हैं।
शोध स्रोत
हर स्रोत अपने साथ दिए गए विवरण में परिभाषा या साक्ष्य का समर्थन करता है। छद्मकोड, कृत्रिम उदाहरण और प्रस्तावित पैरामीटर अलग सत्यापन माँगते हैं।
- Pine Script: TimeframesTradingView. टाइमफ्रेम की परिभाषाएं और इकाइयां पढ़ी गईं। जाँच की तारीख: .
- Other timeframes and dataTradingView. पुष्ट ऊंचे टाइमफ्रेम का डेटा मांगने के उदाहरण पढ़े गए। जाँच की तारीख: .
- pandas.merge_asofpandas. बैकवर्ड मिलान, सहनशीलता और समान समय के मिलान का व्यवहार पढ़ा गया। जाँच की तारीख: .
संबंधित विधियाँ
जोखिम संबंधी सूचना
यह सामग्री शिक्षा और शोध की योजना बनाने के लिए है, वित्तीय सलाह नहीं। Backtest ऐतिहासिक डेटा का सिमुलेशन है, भविष्य के प्रदर्शन की गारंटी नहीं देता और वास्तविक ट्रेड नहीं करता। इस संग्रह की विधियाँ अपने-आप ऐप में उपलब्ध सुविधाएँ नहीं हैं। देखें कार्यपद्धति और शिक्षण केंद्र.
वास्तविक पूँजी जोखिम में डालने से पहले नियमों का सत्यापन करें
ऐप की क्षमताओं, डेटा और प्रत्येक सिमुलेटेड ट्रेड की जाँच करें; उन्नत डिटेक्टरों के लिए अलग कार्यान्वयन की आवश्यकता हो सकती है।
App Store से Backtest डाउनलोड करें