3 nycklar till algo crypto backtesting

Många artiklar om algoritmisk kryptohandel förenklar verkligheten med att bygga en handelsrigg och backtesting-kod. Här kommer vi att granska 3 aspekter av backtesting som ofta slängs över men är det nyckeln till att nå resultat.

Låt oss komma direkt till det, de tre nycklarna till backtesting:

• ljus låga värden för stopp
• hantera utförandepriser
• iterativt jämför backtest med faktiska

Detta betyder stark backtesting är mycket ansträngning (ingen överraskning!) men låt oss gräva vidare i detta.

Många backtestingriggar använder ljus stäng värde för varje bock. I livehandel med stop-loss-order det är det låga värdet i en bock som kommer att stoppa din position.

Låt oss look vid ett exempel. Låt oss i diagrammet nedan för BTC föreställa oss att vi utför en KÖP-order vid den blå linjen på det nedre gröna ljuset, ungefär halvvägs från låg till hög för den bocken.

Nästa ticks låga kan utlösa ett stopp om det var en tight stop-loss. Men om din backtest-kod antar en stop-loss SELL at the Close, så är det inte fallet och positionen skulle sträcka sig framåt i din simulering. Titta noga på det röda ljuset efter den gröna bocken (krysset), dess nära och låga värden är mycket olika. I detta specifika fall skulle den senare visa en större vinst.

Således effekten av ett KÖP till ett högre pris än det öppna har en liten allvarliga konsekvenser för din simulering och backtesting. Det är inte skillnaden mellan ditt exekverade pris och tick open, istället kan det vara en stor skillnad i hur positionen sträcker sig och vinner vinst.

Utförandepriset kan ha en kaskadeffekt på en handels vinst.

Tänk på 2 positioner, den ena gick in kl 20.00 (för att använda runda siffror), den andra kl 20.50, ett något högre (marknadsköp) pris. Denna [relativt lilla] skillnad på 0.50 enheter kan ha en kaskadeffekt på positionens vinst över tid. Varför? Eftersom i en efterföljande bock kan 20.50-positionen stoppas eftersom ett lågt värde kan vara lägre än dess stop-loss-inställning. Under tiden fortsätter den första positionen för många fler vinster. Stor skillnad!

För att hantera detta måste vi uppskatta våra utförda priser...

Viktigt att komma ihåg att backtesting har till uppgift att uppskatta avkastningen från en modell/strategi när den körts i det förflutna.

Din backtesting-kod vet inte vilket pris en handel fick (förfluten tid) på KÖP- eller SÄLJ-sidan.

När man tittar på tidigare historiska marknadsdata är ett faktisk orderutförandepris inte känt. Du kan faktiskt ha en logg som visar det faktiska priset på en position men backtradern tittar på allmänna marknadsdata, inte enskilda handelsloggar.

Att använda det öppna priset för en bock vid inträde är inte realistiskt, inte heller att använda stängningspriset. Varför gör detta stor skillnad? Eftersom, som diskuterats i föregående avsnitt, kan ett inträde till ett högre exekveringspris lätt få en limit sell order att utlösas tidigare än i backtest-simuleringen.

Du vill att dina backtestingsresultat ska vara något pessimistiska.

Det finns inget riktigt svar på var man ska uppskatta utförandepriserna exakt, det är viktigt att förstå att du inte kan få detta exakt rätt i dina simuleringar. Att anta ett ÖPPET pris för dina KÖP-ordrar är generellt optimistiskt och inte det ideala tillvägagångssättet. Om du på samma sätt antar ett STÄNGD-pris för dina SÄLJ-ordrar kommer sannolikt att avvika kraftigt från faktiska resultat.

KÖP på marknaden

Här är några alternativ att välja mellan för KÖP marknadsorder:

a) uppskatta ett exekveringspris halvvägs (eller något fördefinierat avstånd) mellan en bock OPEN och CLOSE

b) uppskatta ett exekveringspris halvvägs (eller något fördefinierat avstånd) mellan en bocks LÅG och HÖG

c) valde ett slumpmässigt pris mellan ÖPPEN eller LÅG och STÄNG eller HÖG

Även om marknadsåtgärder tenderar att vara slumpmässiga till sin natur, är jag inte ett fan av (c) eftersom din backtest-kod kommer inte att vara idempotent; det kommer att returnera olika resultat varje gång det körs på samma data. Det här är rörigt.

Alternativ (b) framhäver en mer volatil marknad, medan alternativ (a) är mindre. Detta är upp till dig men ett val måste göras. Du kan till exempel använda ett volatilitetsindex som CVI och välj sedan enligt det värdet i den period du backtestar.

Vinsttagande SÄLJ limitordrar

Här är några alternativ att välja mellan för vinsttagande SÄLJ limitordrar:

a) uppskatta ett exekveringspris halvvägs (eller något fördefinierat avstånd) mellan en ticks OPEN och HIGH

b) uppskatta ett utförandepris mitt emellan en bocks STÄNGD och HÖG

c) valde ett slumpmässigt pris mellan ovanstående ljusvärden

Stop-loss SÄLJ limitordrar

Här är några alternativ att välja mellan för stop-loss SELL limitordrar:

a) uppskatta ett exekveringspris mitt emellan en ticks ÖPPEN och STÄNGD

b) uppskatta ett utförandepris mitt emellan en bocks STÄNGD och LÅG

c) valde ett slumpmässigt pris mellan ovanstående ljusvärden

Lägg märke till användningen av LÅG vs. HÖG värden beroende på beställningens hållning. En vinsttagande limitförsäljningsorder hanterar ett stigande pris medan en stop-loss preventiv limitförsäljningsorder hanterar ett fallande pris. Båda kommer sannolikt att möta luckor som hoppar över gränsvärdena!

Hanterar gap-down tidigare stop-loss limitorder

Ett mycket vanligt sätt för dina positionsförluster att expandera är att ha en prisgap ner förbi din stop-loss limitorder. Din handelsrigg måste hantera detta genom att identifiera positionen under sin stop-loss limitorder och utföra en marknadsförsäljningsorder på den innan den går vidare i minus.

Kom ihåg att många handelsbörser inte stöder stop-loss marknadsorder, t.ex. Binance, så du är tvungen att använda stop-loss gräns order för att skydda dina positioner. En stop-loss limitorder har ett 'stopppris' och ett 'limitpris', den förra utlöser en limit sell på priset på den senare.

Många börser som Binance stöder inte stop-loss limitorder.

Vad betyder detta för din backtest-algoritm? För att ha en konservativ/pessimistisk syn bör det ta ett försäljningspris någonstans mellan hållplatsens gränspris och tick low. Ju lägre förhållande desto mer konservativt resultat. Det är så att en betydande andel av dessa stop-loss limitorder kommer att utföras till sitt gränspris, men andra kommer att utföras under gränspriset och detta måste redovisas.

Redovisning av vinsttagande säljorder

Om din handelsrigg stöder vinstdrivande modeller (det borde det), där en position stängs med vinst när den når en exitnivå, bör dessa order hanteras aggressivt.

I detta scenario kommer en marknadsorder att lämna vinster på bordet, bättre att göra en limitförsäljningsorder till ett specifikt pris.

Ett starkt tillvägagångssätt när man vill ta vinster på en position är att få toppen av orderboken (se ovan) och sätta SÄLJ-gränspriset till ett av dessa priser. Detta kommer sannolikt att fyllas till ett högre pris (vinst) än en marknadsorder vid denna tidpunkt.

Vad betyder detta för din backtest-algoritm? För att ha en konservativ/pessimistisk syn bör det förutsätta ett pris mellan vinsttagande exitnivå och tick högt. Ett verkligt försäljningspris skulle beror på orderbokens spridning vid tidpunkten för en affär men naturligtvis finns det ingen "orderbok" i en backtest-simulator så vi måste uppskatta från tillgänglig data.

Det finns inget sätt att förbättra backtest-algoritmer om de inte jämförs med faktiska resultat iterativt.

Om du inte iterativt jämför dina backtestresultat med faktiska handelsresultat kan du inte vara säker på din backtesting.

Här är ett konkret exempel på hur du uppnår detta:

• kör din livehandelsrigg under en period, t.ex. 24 timmar
• logga resultaten: varje handel, varje exit, varje stop-loss
• efter denna period, kör din backtest-kod på samma period
• jämför resultatet av backtestet med dina faktiska resultat!

Jämför varje handel i detalj, vilka antaganden gjorde din backtest-kod som inte är representativa för faktisk livehandel?

Vilka är skillnaderna?

• är ditt backtest optimistiskt? Var i så fall? hur? Varför?
• är din backtest alltför pessimistisk?

Du vill att ditt backtest genomgående ska visa ett lite pessimistiskt resultat; konservativ.

Efter att ha gjort detta några gånger, stäng av din handelsrigg och utveckla både backtestkoden och din handelsrigg. iterera.

Eftersom din livehandelsrigg kan köras med relativt liten orderstorlek, kostar det inte mycket att köra den som ett test.

Naturligtvis under vilken tidsperiod som helst kommer det att inträffa oväntade åtgärder på marknaden, poängen här är att identifiera områden där ditt backtest uppenbarligen inte uppskattar vad dina faktiska uppgifter avslöjade.

Några exempel på vad jag har hittat när jag gjorde detta:

• backtestet var alltför optimistiskt om LIMIT SELL-priser, i den faktiska handeln fanns det ofta gap-down-situationer som minskade vinsten
• backtestet var alltför optimistiskt om KÖP exekveringspriser, i verklig handel var det sällsynt att få ett tick open-pris exekverat
• backtestet fångade inte STOP-LOSS säljorder på låga värden inom en bock, i faktisk handel var detta att avsluta positioner tidigt

Detta är det enda sättet att tjäna vinster från din kryptohandelsrigg. Utveckla din backtesting över tiden och iterera över faktiska resultat för att förbättra den.

Att backtesta din algoritmhandelsmodell är hårt arbete! Detta borde inte komma som någon överraskning. Det finns ingen "lätt väg" här.

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