request.security Pine Script-ში: როგორ მივიღოთ სხვა სიმბოლოსა და ტაიმფრეიმის მონაცემები

რას აკეთებს request.security და როდის არის ის საჭირო?

ნაგულისხმევად სკრიპტი სანთლების ზუსტად ერთ ნაკრებს ხედავს — იმას, რომელიც ეკრანზეა გახსნილი. როგორ გადის ის მათ და რატომ ითვლის მნიშვნელობებს ბარიდან ბარამდე, განხილულია მასალაში იმის შესახებ, როგორ ითვლის Pine Script მნიშვნელობებს ბარების მიხედვით. იქვე გულწრფელად იყო აღნიშნული გამოტოვებაც: მინიმალური მაგალითი განზრახ არაფერს ითხოვდა გარედან. ახლა სწორედ ამ გამოტოვებას შევავსებთ.

request.security-ის მეშვეობით მოთხოვნა სრულიად კონკრეტულ ამოცანებს წყვეტს. თხუთმეტწუთიან გრაფიკზე მუშაობისას შესვლის გაფილტვრა დღიური ტრენდის მიმართულებით. ალტკოინის გრაფიკზე ბიტკოინის ქცევის დატანა. ინდიკატორის ერთდროულად ოთხ ინსტრუმენტზე გამოთვლა და გასაშუალოება. ყველა ამ შემთხვევაში გამოთვლა სწორედ იქ, სხვა კონტექსტში უნდა შესრულდეს, თქვენამდე კი უკვე მზა რიცხვი უნდა მოვიდეს.

ცალკე უნდა დაიმახსოვროთ შემთხვევებიც, როდესაც მონაცემების მოთხოვნა საჭირო არ არის. თუ გამოსახულება თქვენი გრაფიკის სანთლების მიხედვით ითვლება, არავითარი მოთხოვნა არ გჭირდებათ: დაწერეთ ჩვეულებრივი ფორმულა. TradingView-ის ოფიციალურ FAQ-ში პირდაპირ წერია, რომ საკუთარი სიმბოლოსა და საკუთარი ტაიმფრეიმის მოთხოვნას, როგორც წესი, აზრი არ აქვს: უფრო მარტივია, საკუთარი გრაფიკის მნიშვნელობებს მიმართოთ.

როგორ არის მოწყობილი სამი არგუმენტი: symbol, timeframe და expression?

ოფიციალურ დოკუმენტაციაში სრული სიგნატურა ასეა ჩაწერილი:

request.security(symbol, timeframe, expression, gaps, lookahead, ignore_invalid_symbol, currency, calc_bars_count)

პირველი სამი ნაწილი სამუშაო მინიმუმია. სიმბოლო ტიკერის შემცველი სტრიქონია, სასურველია სავაჭრო პლატფორმასთან ერთად: დოკუმენტაცია ბირჟის პრეფიქსის მითითებას გვირჩევს, რადგან სხვაგვარად სისტემა მას თავად შეარჩევს და შედეგი შესაძლოა მოსალოდნელისგან განსხვავდებოდეს. მიმდინარე ინსტრუმენტისთვის არსებობს მზა ცვლადი syminfo.tickerid; ორაზროვნების თავიდან ასაცილებლად სწორედ მის გამოყენებას გვირჩევენ.

ტაიმფრეიმის სტრიქონს უკავშირდება შეცდომა, რომელსაც თითქმის ყველა აწყდება. ფორმატი შედგება მამრავლისა და ერთეულის ასოსგან, თუმცა წუთებს ასო საერთოდ არ აქვს: "15" თხუთმეტი წუთია, "1D" — დღე, "1W" — კვირა. ამ ნაკრებში საათი უბრალოდ არ არსებობს. დოკუმენტაცია ცალსახად ამბობს: "1H" არავალიდურია, საათის სწორი ჩანაწერია "60".

მესამე ნაწილი — გამოსახულება — ყველაზე მეტად დაუფასებელია. ის გამოთვლილი სახით არ გადაიტანება; ხელახლა გამოითვლება იქ, მოთხოვნილი სიმბოლოს კონტექსტში. თუ დაწერთ ta.sma(close, 20), საშუალო სხვა სიმბოლოს დახურვის ფასების მიხედვით გამოითვლება და არა თქვენის მიხედვით. სწორედ ეს არის საჭირო და სწორედ ეს უკვირს ადამიანს, რომელიც მზა მნიშვნელობის გადატანას ელოდა.

როგორ მოვითხოვოთ სხვა სიმბოლოს მონაცემები?

მინიმალური სამუშაო მაგალითი ფაქტობრივად ერთ ხაზში ეტევა. შემდეგ ის შეიძლება გრაფიკზე გამოიტანოთ ან საკუთარ ფასს შეადაროთ:

//@version=6
indicator("სხვა სიმბოლო საკუთარ ტაიმფრეიმზე")
float otherClose = request.security("NASDAQ:AAPL", timeframe.period, close)
plot(otherClose)

სად უნდა ჩასვათ ეს კოდი და როგორ შეინახოთ, ახსნილია ცალკე ინსტრუქციაში იმის შესახებ, როგორ გავხსნათ Pine Editor და შევინახოთ სკრიპტი. აქ ღილაკებზე უფრო მნიშვნელოვანი ქცევაა.

ოფიციალური FAQ დამწყების მთავარ შიშს აქარწყლებს: გრაფიკის ტაიმფრეიმზე სხვა სიმბოლოს მონაცემების მოთხოვნა გადახატვას არ იწვევს. ამ შემთხვევაში მნიშვნელობის გადაადგილება და არასავალდებულო არგუმენტების შეცვლა საჭირო არ არის.

თუმცა დროის ღერძი კვლავ თქვენია. დოკუმენტაციაში მოყვანილია თვალსაჩინო მაგალითი: SPY-ის გრაფიკზე BTCUSD-ის მონაცემები ახალ მნიშვნელობას მხოლოდ მაშინ აჩვენებს, როცა ახალი ბარი თავად SPY-ზე გაჩნდება. უქმეებიანი ინსტრუმენტის გრაფიკზე სადღეღამისო ინსტრუმენტი მთელი შაბათის განმავლობაში ერთ ადგილზე დარჩება. ეს შეფერხება კი არა, მონაცემთა ორი მწკრივის დაკავშირების თვისებაა.

როგორ მივიღოთ უფროსი ტაიმფრეიმის მონაცემები request.security-ის მეშვეობით?

კლასიკური ამოცანა ასე ჟღერს: ვვაჭრობ თხუთმეტწუთიან გრაფიკზე, შესვლას კი მხოლოდ დღიური ტრენდის მიმართულებით ვუშვებ. თავად ფილტრი შეიძლება ნებისმიერი იყოს; ტრენდის ინდიკატორის მორგების გარეშე არჩევა ცალკე სამუშაოა. მოთხოვნის მექანიკა კი ყოველთვის ერთნაირია.

ასეთი სკრიპტი ეტაპობრივად ასე ეწყობა:

1. ტაიმფრეიმისთვის შემავალი პარამეტრი შექმენით, რათა მასშტაბი კოდში სამუდამოდ არ ჩაიკეროს.
2. დაამატეთ შემოწმება: თუ არჩეული მასშტაბი გრაფიკის მასშტაბზე დაბალია, გამოიძახეთ runtime.error() ადამიანისთვის გასაგები ტექსტით.
3. დაწერეთ თავად მოთხოვნა უფროსი ტაიმფრეიმის სტრიქონით.
4. შედეგი გრაფიკზე გამოიტანეთ, რათა საფეხურები თვალით დაინახოთ.

//@version=6
indicator("დღიური საშუალო უმცროს გრაფიკზე", overlay = true)

string htf = input.timeframe("1D", "უფროსი ტაიმფრეიმი")

if timeframe.in_seconds() > timeframe.in_seconds(htf)
    runtime.error("არჩეული ტაიმფრეიმი გრაფიკის ტაიმფრეიმზე დაბალია. აირჩიეთ უფროსი.")

float htfMa = request.security(syminfo.tickerid, htf, ta.sma(close, 20))
plot(htfMa)

ხაზი საფეხუროვანი გამოვა და ეს ნორმალურია: მნიშვნელობა თითო დღიურ ბარზე ერთხელ ახლდება და არა ყოველ თხუთმეტ წუთში. კითხვა „როგორ გავასწოროთ საფეხურები“ ფორუმებზე წლებია მეორდება, მაგრამ აქ გასასწორებელი არაფერია — უმცროს მასშტაბზე განახლებებს შორის დღიური მნიშვნელობა უბრალოდ არ არსებობს.

რატომ იცვლება უფროსი ტაიმფრეიმის მნიშვნელობა დაუხურავ ბარზე?

ამ ქცევას თავისი სახელი აქვს — გადახატვა. TradingView მას ფართოდ განსაზღვრავს: სკრიპტის ქცევა, როდესაც ისტორიულ მონაცემებსა და რეალურ დროში გამოთვლები განსხვავებულად მუშაობს. იქვე პანიკას შეფასებითაც აქარწყლებენ: მათი ვარაუდით, არსებული ინდიკატორების ოთხმოცდათხუთმეტ პროცენტზე მეტი ამა თუ იმ ფორმით გადაიხატება, მათ შორის MACD და RSI დაუხურავ სანთელზე.

დოკუმენტაცია მექანიკას პირდაპირ აღწერს. ისტორიულ ბარებზე ფუნქცია მოთხოვნილი კონტექსტიდან მხოლოდ დადასტურებულ მნიშვნელობებს აბრუნებს, რეალური დროის ბარებზე კი შეიძლება დაუდასტურებელი მნიშვნელობებიც დააბრუნოს. როდესაც სკრიპტი ხელახლა იშვება, გუშინდელი რეალური ბარები ისტორიული ხდება და მათზე მნიშვნელობები დადასტურებულით იცვლება.

პრაქტიკული დასკვნა უსიამოვნო, მაგრამ გულწრფელია. სანამ ცოცხალ გრაფიკს უყურებთ, ხედავთ არა იმას, რასაც ხვალ სკრიპტი იმავე ისტორიულ მონაკვეთზე დაინახავს. სწორედ აქედან წარმოიშობა სხვაობა ლამაზ სურათსა და სავაჭრო ალგორითმის შემოწმების შედეგს შორის.

როგორ მივიღოთ უფროსი ტაიმფრეიმის დადასტურებული მნიშვნელობა მომავალში გახედვის გარეშე?

დოკუმენტაციაში ფორმულირება ასეთია: გადახატვის არმქონე შედეგის მისაღებად ყველაზე საიმედო გზა არის მხოლოდ წარსულ ბარებზე მიმთითებელი გამოსახულების გადაცემა და ამავე დროს lookahead = barmerge.lookahead_on-ის დაყენება. იქვე ამ კავშირზე მკაცრადაა ნათქვამი: გადაადგილება და lookahead ურთიერთდამოკიდებულია და ერთ-ერთის ამოღება მეორისთვის ზიანის მიუყენებლად შეუძლებელია.

//@version=6
indicator("დადასტურებული დღიური დახურვის ფასი", overlay = true)
float dailyClose = request.security(syminfo.tickerid, "1D", close[1], lookahead = barmerge.lookahead_on)
plot(dailyClose)

ლოგიკა ისეთი რთული არ არის, როგორიც ჩანს. on მდგომარეობაში ჩართული lookahead არგუმენტი ფუნქციას საშუალებას აძლევს, მნიშვნელობა იმ უფროსი ბარიდან აიღოს, რომელიც თქვენი ბარის მომენტისთვის ჯერ არ დასრულებულა. ერთი ბარით გადაადგილება მოთხოვნას ზუსტად იმდენად სწევს, რომ ის უკვე დახურულ უფროს ბარში მოხვდეს. მომავალი აღარ რჩება — რჩება დადასტურებული წარსული.

იგივე lookahead გადაადგილების გარეშე საკუთარი თავის წინააღმდეგ მიმართულ იარაღად იქცევა. დოკუმენტაციაში მოყვანილია ანტიმაგალითი კომენტარით „FUTURE LEAK, არ გამოიყენოთ“ და ცალკეა გაფრთხილება: სკრიპტები, რომლებიც lookahead-ის მეშვეობით მომავალს წარსულში გადაიტანენ, გამოსაქვეყნებლად არ დაიშვება. ბექტესტზე ასეთი კოდი ფანტასტიკურ სტატისტიკას აჩვენებს. რეალურ ანგარიშზე კი არაფერს აჩვენებს.

სკალის შუა ნიშნული ნაგულისხმევი მდგომარეობაა და ის მოტყუება არ არის: ფუნქცია ზუსტად აბრუნებს იმას, რაც უფროს კონტექსტში ამ მომენტში არსებობს. მარჯვენა ნიშნული კი უკვე გაყალბებაა, რადგან ისტორიულ ბარზე სკრიპტში მომავლის მონაცემები ხვდება.

ცალკე ხაფანგი ელოდება მათ, ვინც უფროსი ბარის დახურვის უშუალოდ დაფიქსირებას ცდილობს. მოთხოვნის შიგნით ბარის მდგომარეობა არ მუშაობს: დოკუმენტაციაში ეს ერთ ხაზადაა დაფიქსირებული — barstate.isconfirmed გამოძახებაში request.security() არ მუშაობს. საზოგადოების ნაწილი ამას საკუთარი გარსებით უვლის გვერდს და გადაადგილებას გამოძახების გარეთ, ბარის მდგომარეობის მიხედვით ცვლის. ორივე მიდგომა დადასტურებულ მნიშვნელობას იძლევა, მაგრამ გრაფიკზე მისი გამოჩენის მომენტი განსხვავებულია: ოფიციალური მეთოდი დახურულ უფროს ბარს ახალი უფროსი პერიოდის დაწყებისთანავე აბრუნებს, საზოგადოების გარსების ქცევა კი დოკუმენტაციაში აღწერილი არ არის და ის საკუთარ გრაფიკზე თვალით უნდა შეამოწმოთ. იმის გარჩევა, თუ როგორ განვასხვაოთ სანდო სიგნალი მოგვიანებით გადაადგილებულისგან, განხილულია მასალაში ინდიკატორები გადახატვის გარეშე.

რით განსხვავდება barmerge.gaps_on barmerge.gaps_off-ისგან?

განსხვავება ერთ ცხრილში ჩანს:

//@version=6
indicator("gaps თვალით", overlay = true)
float noGaps = request.security(syminfo.tickerid, "60", close, gaps = barmerge.gaps_off)
float withGaps = request.security(syminfo.tickerid, "60", close, gaps = barmerge.gaps_on)
plot(noGaps, "წყვეტების გარეშე", color.blue, 2, plot.style_linebr)
plot(withGaps, "წყვეტებით", color.purple, 6, plot.style_linebr)

არჩევანი მარტივია. „ფასი დღიურ საშუალოზე მაღლაა“ ტიპის პირობებისთვის გამოიყენეთ ნაგულისხმევი მდგომარეობა: მნიშვნელობა თითოეულ ბარზე გჭირდებათ. ცარიელი მნიშვნელობები მაშინ დაგჭირდებათ, როდესაც მნიშვნელოვანია ახალი მონაცემების მოსვლის თავად მომენტი, მაგალითად ახალი უფროსი პერიოდის დაწყებისას მარკერის დასასმელად.

რატომ არის request.security მოუხერხებელი უმცროსი ტაიმფრეიმისთვის?

დოკუმენტაციაში ეს ქცევა შელამაზების გარეშეა აღწერილი. უმცროს მასშტაბზე მიმართვისას ფუნქცია გამოსახულებას უმცროს კონტექსტში ითვლის, მაგრამ გრაფიკის თითოეულ ბარზე მხოლოდ ერთი ინტრაბარის შედეგს აბრუნებს. on მდგომარეობაში ჩართული lookahead-ის შემთხვევაში ეს პირველი ხელმისაწვდომი ინტრაბარია, off მდგომარეობაში კი — ბოლო. რეალური დროის ბარებზე უკანასკნელი ხელმისაწვდომი მნიშვნელობა არგუმენტისგან დამოუკიდებლად ბრუნდება.

ბარისშიდა მონაცემებთან სრულფასოვანი მუშაობისთვის არსებობს request.security_lower_tf(). მისი სიგნატურა განსხვავებულია: gaps და lookahead არგუმენტები არ აქვს, სამაგიეროდ აქვს ignore_invalid_timeframe, რომელიც ნაგულისხმევად გამორთულია. ფუნქცია ინტრაბარების დროის მიხედვით დალაგებულ მნიშვნელობათა მასივს აბრუნებს.

//@version=6
indicator("რამდენი ერთწუთიანი ბარია ერთ ბარში")
array<float> closes = request.security_lower_tf(syminfo.tickerid, "1", close)
int qty = array.size(closes)
plot(qty, style = plot.style_histogram)

ელემენტებზე მიმართვამდე მასივის ზომა უნდა შეამოწმოთ — ეს ფორუმებზე ხშირი შეცდომაა: ადამიანი მაშინვე პირველ ელემენტს იღებს და სკრიპტი შეცდომით ჩერდება, რადგან მასივი ცარიელი აღმოჩნდა. კიდევ ერთი გულწრფელი შენიშვნა თავად TradingView-ისგან: მონაცემთა მომწოდებლებს შორის განსხვავებების გამო ზოგიერთ შემთხვევაში ამ ფუნქციასაც შეუძლია მცირედ გადაიხატოს.

როგორ შევამოწმოთ კოდი გადატვირთვის შემდეგ ისტორიულ მონაცემებსა და რეალურ დროში?

შემოწმება სწორედ იმიტომ არის საჭირო, რომ განსხვავებას თვალით ვერ დაიჭერთ: ცოცხალი გრაფიკიც და გადატვირთვის შემდეგ იგივე გრაფიკიც თანაბრად დამაჯერებლად გამოიყურება. მსგავსი read-back რიტუალი აღწერილია გადატვირთვის შემდეგ სიგნალის შემოწმების განხილვაშიც; აქ ის სხვა მონაცემებისთვისაა ადაპტირებული.

წინასწარ უნდა შეთანხმდეთ, რა ჩაითვლება ჩავარდნად. მარკერის ერთი ბარით გადაადგილება გადახატვაა და არა წვრილმანი. გამქრალი მარკერიც გადახატვაა. თუ მარკერები დაემთხვა, მაგრამ ლოგის მნიშვნელობები განსხვავდება, ესეც სიგნალია: პირობა ჯერ მხოლოდ შემთხვევით ნარჩუნდება.

ცალკე შეამოწმეთ ქცევა სავაჭრო სესიების საზღვარზე და უქმეებზე. სწორედ იქ სცილდება ერთმანეთს ორი ინსტრუმენტის დროის ღერძები და სწორედ იქ ირღვევა ლოგიკა, რომელიც თანაბარ ისტორიულ მონაკვეთზე მუშაობდა. როგორ ჩავრთოთ ასეთი შემოწმება სრულ წესებში, განხილულია მასალაში სტრატეგიაში შესვლისა და გამოსვლის წესები.

რისკები და შეზღუდვები

პასუხისმგებლობის შეზღუდვა. მასალა საგანმანათლებლო ხასიათისაა და არ წარმოადგენს ინდივიდუალურ საინვესტიციო რეკომენდაციას. გარიგებებთან დაკავშირებულ გადაწყვეტილებებს დამოუკიდებლად იღებთ; ფინანსურ ბაზრებზე ვაჭრობა ჩადებული სახსრების დაკარგვის რისკთანაა დაკავშირებული.

სწორად დაწერილი მოთხოვნა წარსულს აღარ გააყალბებს, მაგრამ ამის გამო სიგნალი უფრო ზუსტი არ ხდება. სკრიპტი, რომელიც გადატვირთვის შემდეგ იმავეს აჩვენებს, სანდოა — თუმცა სანდოობა და მომგებიანობა სხვადასხვა თვისებაა და პირველი მეორეს არ უზრუნველყოფს.

მონაცემები მომწოდებლისგან მოდის და სკრიპტში არ იქმნება. TradingView პირდაპირ აღნიშნავს, რომ მონაცემებს თავად არ გენერირებს და საკუთარ მომწოდებლებს ეყრდნობა. დღიური და დღისშიდა მონაცემთა ნაკადები შეიძლება მოცულობით განსხვავდებოდეს, ხოლო გაფართოებული სესია დღიურ ნაკადში არ ხვდება. აქციებზე ეს შესამჩნევია, სადღეღამისო ინსტრუმენტებზე კი თითქმის არა.

მოთხოვნების რაოდენობა შეზღუდულია და ლიმიტი ტარიფზეა დამოკიდებული. ერთნაირი გამოძახებები, როგორც წესი, ერთ მოთხოვნად ითვლება, მაგრამ იმპორტირებული ბიბლიოთეკების შიგნით არსებული გამოძახებები ცალკე ითვლება. სკრიპტი, რომელიც ათი სიმბოლოს მონაცემებს ითხოვს, ზღვარს იმაზე სწრაფად მიაღწევს, ვიდრე იდეის ეტაპზე ჩანს.

on მდგომარეობაში ჩართული lookahead არგუმენტი გამოსახულების გადაადგილების გარეშე საკუთარი თავის პირდაპირ მოტყუებაა. ასეთი სკრიპტის TradingView-ის ბიბლიოთეკაში გამოქვეყნება აკრძალულია, ხოლო მისი ისტორიული შემოწმების შედეგები არაფერს ნიშნავს.

ისტორიულ მონაცემებზე შემოწმების შედეგები მომავალზე არ ვრცელდება. ამ სტატიის რიტუალი დეფექტების მხოლოდ ერთ კლასს აფიქსირებს — ისტორიულ მონაცემებსა და რეალურ დროს შორის შეუსაბამობას. ის არაფერს ამბობს იმაზე, იმუშავებს თუ არა წესი მომავალშიც, და ვერ ჩაანაცვლებს ვერც სტოპ-ლოსის ორდერს და ვერც შესვლამდე განსაზღვრულ პოზიციის ზომას.