TradingView-ötletként megjelentetve az ETHUSDT-ről. Grafikon megtekintése a TradingView-n
Ha valaha átültetett már egy indikátort Pythonba, hogy visszateszteljen vele, vagy megbízott egy szkriptben, mert ellenőrzéssel együtt érkezett, akkor itt arról a résről lesz szó, amelyet ez a két dolog nyitva hagy.
Három saját indikátorunkat építettük újra, hogy visszateszt futhasson rajtuk. Mindhárom újraépítésben hibás állandó lapult. Mindhárom átment a saját érvényesítésén. Egyet sem kapott el egyetlen teszt sem.
Miért is építenénk újra egy indikátort
Egy Pine-szkript az Ön grafikonján fut. Nem megy végig ciklusban hat év előzményen, és nem válaszolja meg, hogy egy jelzés valóban kifizetődik-e. Ahhoz, hogy ezt megkérdezzük, olyasmiben építjük újra, amit ezerszer le lehet futtatni.
Épp ebben az újraépítésben szűnik meg csendben egy indikátor ugyanaz az indikátor lenni.
A legtöbbe kerülő hiba, és ez egyetlen gyertya
A Volume Oracle egyik belső hossza az idősíkból származik:
target bars = 36 hours × 60 / 240 minutes = 9
regime length = round(9 × 2.5) = round(22.5)A Pine math.round függvénye a holtversenyt a nullától elfelé dönti el. Ezt adja: 23. A Python 3 round() függvénye banki kerekítést használ, amely a holtversenyt a páros szám felé dönti el. Ezt adja: 22.
Mindkettő a kerekítés helyes megvalósítása. Egyszerűen csak különböző megállapodások, és semmi sem figyelmezteti Önt arra, hogy átlépett az egyikből a másikba.
Minden abból a számból származó visszatekintés elmozdult vele együtt. Az eredmény egy 36 jelzéses végigfuttatás legjobban alátámasztott sorában:
| változat | 48 órás előny | találati arány | n |
|---|---|---|---|
| újraépített, hossz 22 | +0,423% | 51 | 1216 |
| helyes, hossz 23 | +0,260% | 50 | 1223 |
38%-os levágás egyetlen kerekítési megállapodás miatt.
Aztán a tanulságot is rosszul jegyeztük fel
A feljegyzésünk azt írta, hogy csak 4H-n fordul elő. Abból az egyetlen idősíkból íródott, amely éppen teszt alatt állt, és két hónapon át így is maradt.
Ugyanezt a számolást minden idősíkon végigfuttatva:
| idősík | rezsimhossz | áramláshossz | eredmény |
|---|---|---|---|
| 5m | 45 a 45 ellen | 23 a 22 ellen | eltér |
| 2H | 45 a 45 ellen | 23 a 22 ellen | eltér |
| 4H | 23 a 22 ellen | 12 a 11 ellen | eltér |
| 8H | 53 az 52 ellen | 27 a 26 ellen | eltér |
| 1D | 18 a 18 ellen | 9 a 9 ellen | holtverseny, egyezik |
| 3D, 1W | 15 a 15 ellen | 8 a 8 ellen | holtverseny, egyezik |
Tizenhatból négy, nem egy.
Ebből a táblázatból két olyan dolog esik ki, amelyet semennyi okoskodás nem hozott elő.
A holtverseny nem elég. Az 1D, a 3D és az 1W mind pontosan ,5-re esik, és egyezik. A banki kerekítés csak olyan holtversenyt mozdít el, amelynek a felfelé kerekített válasza páratlan, tehát a round(17.5) így is, úgy is 18. Az összes holtverseny nagyjából fele ártalmatlan, és épp ezért nem bizonyít semmit, ha kiragadva egyet ellenőrzünk.
Az eltérés érkezhet egy lépéssel később is. 5m-en és 2H-n az első hossz 45-nél egyezik. A következő sor, round(45 × 0.5), megint 22,5, és az már kettéválik. Ha az első állandót ellenőrzi, majd továbbmegy, mindkét idősíkot tévesen nyilvánítja rendben lévőnek.
A másik kettő, röviden
Harmonic úgy normalizál egy oszcillátort, hogy egy gördülő sávra vágja. A forrásban minden gyertyát a saját sávja vág le. Az újraépítés egy teljes 200 gyertyás ablakot vágott le az aktuális gyertya sávjával, ami már más függvény. A 11 497 gyertyán mért eltérés: átlagosan 0,47 pont. Valódi átírási hiba, érdemi hatás nélkül.
Ezt ráadásul fel is nagyítottuk, mielőtt megmértük volna. Pusztán a kód elolvasása alapján úgy hirdettük ki, hogy szinte biztosan ez a 9%-os elcsúszás. A szám 0,47 volt. A valódi hiba és az érdemi hiba két különböző állítás, és a nagyságrendet azelőtt mérjük meg, hogy a hatást néven neveznénk.
Plutus Flow 50 gyertyán átlagolja a forgalmat, hogy kiugrásokat találjon. Az újraépítés 20-at használt, mert azt a számot hittük ismerni. Hatás: egy százalékpont tizedénél kevesebb, előjelváltás nélkül. Az ítélet nem mozdult, de a szám hibás volt, most pedig helyes, és egyedül ez a mérce számít.
Az a rész, amely valójában a tanulság
Íme, mit jelentett akkor az egyes újraépítések érvényesítése.
| újraépítés | a saját ellenőrzése | mit jelentett ez |
|---|---|---|
| Volume Oracle | előtte 3/3, utána 3/3 | nem tudta megkülönböztetni őket |
| Harmonic | előtte 6/8, utána 5/8 | a hibás változatot pontozta magasabbra |
| Plutus Flow | soha nem futott le | — |
A középső soron érdemes elidőzni. Az érvényesítés a hibás kódot részesítette előnyben. Ha az ellenőrzésre bíztuk volna a döntést, érvekkel visszaterelt volna minket a hibába.
Az az érvényesítés, amely egyetlen kimeneti értéket hasonlít össze, nem képes felismerni a hibás bemeneti állandót. A kimenet túlságosan durva szita. Sokféle különböző hibás paraméterkészlet ugyanazt a rezsimcímkét, ugyanazt a keresztezési állapotot, ugyanazt a színt adja ma a grafikonon. Azokon a gyertyákon térnek el, amelyeket éppen nem néz, márpedig pontosan ott él egy visszateszt.
Mit tegyünk helyette
Írassa ki az összes származtatott paramétert. Minden hosszt, minden küszöböt, minden szorzót. Vesse össze őket a forrással soronként, mielőtt bármit is osztályozna.
Tartsa meg a kimeneti ellenőrzést. Más hibaosztályt fog meg, és szükség van rá. Csak éppen közel sem elegendő, és mind a három egyenesen elsétált mellette.
Az őszinte érvényességi kör
A Pine-kód mindhárom esetben helyes volt. Az volt hibás, amit a tesztelésére építettünk, és ez a probléma kellemetlenebb változata: a mérőeszköz elcsúszott, a saját önellenőrzése pedig azt mondta, hogy nem.
A 38%-os szám egy sor, egy végigfuttatás, egy idősík, mintán belül, és a saját feljegyzésünkből idézzük, nem futtattuk újra. A kerekítési eredmény egyetlen paranccsal újratermelhető, és épp a javítása hozta felszínre, hogy a saját feljegyzésünk két hónapja hibás volt.
TradingView-ötletként megjelentetve az ETHUSDT-ről. Grafikon megtekintése a TradingView-n
A saját eszközeink múltbeli mérése, utólag leírva. Itt semmi sem ajánlás, és nem is utal jövőbeli eredményekre.