3 nøkler til algo krypto-backtesting

Mange artikler om algoritmisk kryptohandel forenkler virkeligheten med å bygge en handelsrigg og backtesting-kode. Her skal vi gjennomgå 3 aspekter ved backtesting som ofte blir oversvømt, men som er det nøkkelen til å oppnå resultater.

La oss komme rett til det, de tre nøklene til backtesting:

• lys lave verdier for stopp
• administrerende utførelsespriser
• iterativt sammenligne backtest med faktiske resultater

Dette betyr sterk backtesting er mye innsats (ingen overraskelse!), men la oss grave videre i dette.

Mange backtesting-rigger bruker stearinlys nær verdi for hver hake. I live trading med stop-loss-ordrer det er den lave verdien i en hake som vil stoppe posisjonen din.

La oss look med et eksempel. I diagrammet nedenfor for BTC, la oss forestille oss at vi utfører en KJØP-ordre på den blå linjen på det nedre grønne stearinlyset, omtrent midtveis fra lav til høy for den haken.

Den neste hakens lavpunkt kan utløse et stopp hvis det var et tett stop-loss. Men hvis backtest-koden din antar et stop-loss SELG ved avslutningen, så er det ikke tilfelle og posisjonen vil strekke seg fremover i simuleringen. Se nøye på det røde stearinlyset etter den grønne inngangshaken (krysset), dens nære og lave verdier er svært forskjellige. I dette spesifikke tilfellet vil sistnevnte vise en større fortjeneste.

Dermed effekten av et KJØP til en høyere pris enn den åpne kan ha alvorlige konsekvenser for simulering og backtesting. Det er ikke forskjellen mellom din utførte pris og tikken åpen, i stedet kan det være en stor forskjell i måten posisjonen utvider seg og oppnår fortjeneste.

Gjennomføringsprisen kan ha en kaskadeeffekt på en handelsfortjeneste.

Tenk på 2 posisjoner, en angitt kl 20.00 (for å bruke runde tall), den andre kl 20.50, en litt høyere (markedskjøp) pris. Denne [relativt lille] forskjellen på 0.50 enheter kan ha en kaskadeeffekt på posisjonens resultat over tid. Hvorfor? Fordi i en påfølgende hake kan 20.50-posisjonen bli stoppet da en lav verdi kan være lavere enn dens stop-loss-innstilling. I mellomtiden fortsetter den første posisjonen for mange flere ticks til en fortjeneste. Stor forskjell!

For å håndtere dette må vi estimere våre utførte priser...

Viktig å huske på at backtesting sin jobb er å estimere avkastning fra en modell/strategi når den ble kjørt i fortiden.

Backtesting-koden din vet ikke hvilken pris en handel mottok (fortid) på KJØP- eller SELG-siden.

Når man ser på tidligere historiske markedsdata, er en faktisk ordreutførelsespris ikke kjent. Du kan faktisk ha en logg som viser faktisk pris på en posisjon, men backtraderen ser på generelle markedsdata, ikke individuelle handelslogger.

Å bruke den åpne prisen for et hake ved inngang er ikke realistisk, det er heller ikke å bruke lukkeprisen. Hvorfor utgjør dette en stor forskjell? Fordi, som diskutert i forrige avsnitt, kan en oppføring til en høyere utførelsespris lett føre til at en grensesalgsordre utløses raskere enn i backtest-simuleringen.

Du vil at backtesting-resultatene dine skal være litt pessimistiske.

Det finnes ikke noe reelt svar på nøyaktig hvor du skal estimere utførelsesprisene, det er viktig å forstå at du ikke kan få dette helt riktig i simuleringene dine. Å anta en ÅPEN pris for dine KJØP-ordrer er generelt optimistisk og ikke den ideelle tilnærmingen. På samme måte vil det å anta en SENG-pris for SELL-ordrene dine sannsynligvis avvike sterkt fra faktiske resultater.

KJØP på markedet

Her er noen alternativer å velge mellom for KJØP markedsordrer:

a) estimer en utførelsespris midtveis (eller en forhåndsdefinert avstand) mellom en hake er ÅPEN og STENGT

b) estimer en utførelsespris midtveis (eller en forhåndsdefinert avstand) mellom en hak er LAV og HØY

c) valgte en tilfeldig pris mellom ÅPEN eller LAV og CLOSE eller HØY

Mens markedshandling har en tendens til å være tilfeldig, er jeg ikke en fan av (c) fordi backtest-koden din vil ikke være idempotent; den vil returnere forskjellige resultater hver gang den kjøres på samme data. Dette er rotete.

Alternativ (b) fremhever et mer volatilt marked, mens alternativ (a) er mindre. Dette er opp til deg, men et valg må tas. Du kan for eksempel bruke en volatilitetsindeks som CVI og velg deretter i henhold til den verdien i perioden du backtester.

Fortjeneste å ta SELL limit-ordrer

Her er noen alternativer å velge mellom for profitttaking SELL limit-ordrer:

a) estimer en utførelsespris midtveis (eller en forhåndsdefinert avstand) mellom en hake er OPEN og HIGH

b) estimer en utførelsespris midt mellom en hake er CLOSE og HIGH

c) valgte en tilfeldig pris mellom de ovennevnte lysverdiene

Stop-loss SELG grenseordrer

Her er noen alternativer å velge mellom for stop-loss SELL limitordrer:

a) estimer en utførelsespris midt mellom en hake er ÅPEN og STENGT

b) estimer en utførelsespris midt mellom en hake er CLOSE og LOW

c) valgte en tilfeldig pris mellom de ovennevnte lysverdiene

Legg merke til bruken av LAV vs. HØY verdier avhengig av bestillingens holdning. En fortjenestetakende grensesalgsordre har å gjøre med en stigende pris, mens en stopp-tap-forebyggende grensesalgsordre har å gjøre med en synkende pris. Begge vil sannsynligvis møte hull som hopper over grenseverdiene!

Håndtere gap-down tidligere stop-loss grenseordrer

En veldig vanlig måte å utvide posisjonstapene dine på er å ha en prisgapet ned forbi stop-loss grenseordren. Handelsriggen din må håndtere dette ved å identifisere posisjonen under sin stop-loss limitordre og utføre en markedssalgsordre på den før den går videre i minus.

Husk at mange handelsbørser ikke støtter stop-loss markedsordrer, f.eks. Binance, så du er tvunget til å bruke stop-loss grense ordre om å beskytte posisjonene dine. En stop-loss limitordre har en "stopppris" og en "grensepris", førstnevnte utløser et limitsalg på prisen på sistnevnte.

Mange børser som Binance støtter ikke stop-loss limitordrer.

Hva betyr dette for backtest-algoritmen din? For å ha et konservativt/pessimistisk syn bør det ta en salgspris et sted mellom holdeplassens grensepris og haken lav. Jo lavere forholdet er, desto mer konservativt er resultatet. Det er slik at en betydelig prosentandel av disse stop-loss grenseordrene vil utføres til sin grensepris, mens andre vil utføres under grenseprisen og dette må redegjøres for.

Regnskap for profitttakende salgsordrer

Hvis handelsriggen din støtter profitttakende modeller (det burde det), der en posisjon stenges med overskudd når den når et exit-nivå, bør disse ordrene administreres aggressivt.

I dette scenariet vil en markedsordre etterlate fortjeneste på bordet, bedre å lage en grensesalgsordre til en bestemt pris.

En sterk tilnærming når du ønsker å ta fortjeneste på en posisjon er å få toppen av ordreboken (se ovenfor) og sette SELL-grenseprisen til en av disse prisene. Dette vil sannsynligvis fylle til en høyere pris (fortjeneste) enn en markedsordre på dette tidspunktet.

Hva betyr dette for backtest-algoritmen din? For å ha et konservativt/pessimistisk syn bør det forutsettes en pris mellom overskuddstakende exit-nivå og tick høyt. En faktisk salgspris ville avhenge av ordrebokspredning på tidspunktet for en handel, men selvfølgelig er det ingen "ordrebok" i en backtest-simulator, så vi må estimere fra tilgjengelige data.

Det er ingen måte å forbedre backtest-algoritmer med mindre de sammenlignes med faktiske resultater iterativt.

Med mindre du iterativt sammenligner backtestresultatene dine med faktiske handelsresultater, kan du ikke være trygg på backtestingen din.

Her er et konkret eksempel på hvordan du oppnår dette:

• kjøre live trading riggen for en periode, f.eks. 24 timer
• logg resultatene: hver handel, hver exit, hver stop-loss
• etter denne perioden, kjør tilbaketestkoden din i samme periode
• sammenligne resultatene av backtesten med dine faktiske resultater!

Sammenlign hver handel i detalj, hvilke forutsetninger gjorde backtest-koden din som ikke er representative for faktisk live-handel?

Hva er forskjellene?

• er backtest optimistisk? I så fall hvor? hvordan? Hvorfor?
• er ryggtesten din for pessimistisk?

Du vil at backtesten konsekvent skal vise et litt pessimistisk resultat; konservative.

Etter å ha gjort dette noen ganger, slå av handelsriggen din og utvikle både backtest-koden og handelsriggen din. repetere.

Fordi din live trading-rigg kan kjøre med relativt liten ordrestørrelse, koster det ikke mye å kjøre den som en test.

Selvfølgelig vil det være uventet handling i markedet i løpet av en hvilken som helst tidsperiode, poenget her er å identifisere områder der backtesten din tydeligvis ikke estimerer hva faktiske resultater avslørte.

Noen eksempler på hva jeg har funnet når jeg gjør dette:

• backtesten var altfor optimistisk med hensyn til LIMIT SELL-priser, i faktisk handel var det ofte gap-down-situasjoner som reduserte fortjenesten
• backtesten var altfor optimistisk med hensyn til KJØP-utførelsespriser, i faktisk handel var det sjelden å få en tick open-pris utført
• backtesten fanget ikke STOP-LOSS salgsordrer på lave verdier innenfor en hake, i faktisk handel var dette å avslutte posisjoner tidlig

Dette er den eneste måten å tjene penger på din kryptohandelsrigg. Utvikle backtestingen din over tid og gjenta de faktiske resultatene for å forbedre den.

Tilbaketesting av algoritmehandelsmodellen er hardt arbeid! Dette burde ikke komme som noen overraskelse. Det er ingen "enkel vei" her.

Source: https://medium.com/@gk_/3-keys-to-algo-crypto-backtesting-99f006cfd390?source=rss——-8—————–cryptocurrency