C back test trading strategier

Framgångsrik backtesting av algoritmiska handelsstrategier - Del I Denna artikel fortsätter serien om kvantitativ handel, som började med Beginners Guide och Strategy Identification. Båda dessa längre, mer inblandade artiklar har varit mycket populära så jag fortsätter i denna ån och ger detaljer om ämnet strategi backtesting. Algoritmisk backtesting kräver kunskap om många områden, däribland psykologi, matematik, statistik, mjukvaruutveckling och marknadsexchange mikrostruktur. Jag kunde inte hoppas att täcka alla dessa ämnen i en artikel, så jag ska dela dem i två eller tre mindre bitar. Vad ska vi diskutera i det här avsnittet Jag börjar med att definiera backtesting och då kommer jag att beskriva grunderna för hur det utförs. Då kommer jag att klargöra de fördomar vi berörde i Beginners Guide to Quantitative Trading. Nästa kommer jag presentera en jämförelse av de olika tillgängliga backtestingprogrammen. I efterföljande artiklar kommer vi att titta på detaljerna i strategimodeller som ofta knappast nämns eller ignoreras. Vi kommer också att överväga hur man gör backtesting processen mer realistisk genom att inkludera idiosyncrasies av en handelsutbyte. Då kommer vi att diskutera transaktionskostnader och hur man korrekt modellerar dem i en backtest-inställning. Vi kommer att sluta med en diskussion om utförandet av våra backtests och slutligen ge ett exempel på en gemensam kvantstrategi, känd som en genomsyrande parhandel. Låt oss börja med att diskutera vad backtesting är och varför vi bör utföra det i vår algoritmiska handel. Vad är Backtesting Algoritmisk handel står förutom andra typer av investeringsklasser eftersom vi på ett mer tillförlitligt sätt kan ge förväntningar om framtida prestanda från tidigare resultat, till följd av riklig tillgång till data. Processen genom vilken detta utförs är känt som backtesting. I enkla termer görs backtesting genom att exponera din specifika strategialgoritm till en ström av historisk finansiell data, vilket leder till en uppsättning handelssignaler. Varje handel (som vi kommer att mena här för att vara en rundresa med två signaler) kommer att ha en associerad vinst eller förlust. Sammanställningen av denna vinstlösning under löptiden för din strategi backtest kommer att leda till den totala vinsten och förlusten (även känd som PL eller PnL). Det är kärnan i idén, även om djävulen självklart alltid är i detaljerna. Vilka är de viktigaste orsakerna till att backtesting en algoritmisk strategi Filtrering - Om du kommer ihåg från artikeln om strategiidentifiering. Vårt mål vid det inledande forskningsfasen var att upprätta en strategipipeline och sedan filtrera bort någon strategi som inte uppfyllde vissa kriterier. Backtesting ger oss en annan filtreringsmekanism, eftersom vi kan eliminera strategier som inte uppfyller våra prestationsbehov. Modellering - Backtesting gör det möjligt för oss att (säkert) testa nya modeller av vissa marknadsfenomen, till exempel transaktionskostnader, orderdirigering, latens, likviditet eller andra marknadsmiljöstrukturproblem. Optimering - Även om strategin optimering är fylld med biaser tillåter backtesting oss att öka prestanda för en strategi genom att ändra kvantiteten eller värdena för parametrarna som är associerade med den strategin och omberäkna dess prestanda. Verifiering - Våra strategier är ofta anskaffade externt, via vår strategipipeline. Backtesting en strategi säkerställer att den inte har implementerats felaktigt. Även om vi sällan kommer att få tillgång till signalerna som genereras av externa strategier, har vi ofta tillgång till prestandametri som Sharpe Ratio och Drawdown egenskaper. Således kan vi jämföra dem med vår egen implementering. Backtesting ger en mängd fördelar för algoritmisk handel. Det är emellertid inte alltid möjligt att helt enkelt backtesta en strategi. I allmänhet, som frekvensen av strategin ökar, blir det svårare att korrekt modellera marknadens och börsens mikrostruktureffekter. Detta leder till mindre tillförlitliga backtests och därigenom en svårare utvärdering av en utvald strategi. Detta är ett speciellt problem där exekveringssystemet är nyckeln till strategins prestanda, som med ultrahögfrekvensalgoritmer. Tyvärr är backtesting full av fördomar av alla slag. Vi har berört några av dessa frågor i tidigare artiklar, men vi kommer nu att diskutera dem på djupet. Fördomar som påverkar strategiska backtests Det finns många fördomar som kan påverka prestandan i en backtestad strategi. Tyvärr har dessa förspänningar en tendens att blåsa upp prestanda snarare än att förringa det. Således bör du alltid överväga en backtest att vara en idealiserad övre gräns för strategins faktiska prestanda. Det är nästan omöjligt att eliminera biaser från algoritmisk handel, så det är vårt jobb att minimera dem så mycket vi kan för att fatta välgrundade beslut om våra algoritmiska strategier. Det finns fyra stora fördomar som jag önskar diskutera: Optimering Bias. Titta framåt. Survivorship Bias och psykologiska tolerans Bias. Optimering Bias Detta är förmodligen den mest skrämmande av alla backtest-förskott. Det innebär att justera eller introducera ytterligare handelsparametrar tills strategins prestanda på backtestdatasatsen är väldigt attraktiv. Men när strategin går, kan strategin vara märkbart annorlunda. Ett annat namn för denna förspänning är kurvmontering eller data-snooping bias. Optimeringsförskjutning är svår att eliminera eftersom algoritmiska strategier ofta involverar många parametrar. Parametrar i det här fallet kan vara inmatningsexekveringskriterier, återkallningsperioder, medelvärden (dvs. den glidande parametern för glidande medel) eller volatilitetsmätningsfrekvensen. Optimeringsperspektivet kan minimeras genom att hålla antalet parametrar till ett minimum och öka antalet datapunkter i träningssatsen. Faktum är att man också måste vara försiktig med den senare eftersom äldre träningspunkter kan bli föremål för en tidigare regim (som en lagstiftningsmiljö) och kan därför inte vara relevant för din nuvarande strategi. En metod för att mildra denna bias är att utföra en känslighetsanalys. Detta innebär att parametrarna varieras stegvis och plottar en yta av prestanda. Ljud, grundläggande resonemang för parametervalg bör med alla andra faktorer betraktas leda till en jämnare parametraryta. Om du har en mycket hoppig yt yta betyder det ofta att en parameter inte speglar ett fenomen och är en artefakt av testdata. Det finns en stor litteratur om flerdimensionella optimeringsalgoritmer och det är ett mycket aktivt forskningsområde. Jag kommer inte att stanna här, men behåll det bakom dig när du hittar en strategi med en fantastisk backtest. Look-Ahead Bias Look-ahead-bias introduceras i ett backtesting-system när framtida data av misstag ingår i en punkt i simulering där data inte skulle ha varit tillgängliga. Om vi ​​kör backtesten kronologiskt och vi når tidpunkt N, så kommer framåtblickande bias uppträda om data ingår för vilken punkt Nk, där k0. Look-ahead biasfel kan vara otroligt subtila. Här är tre exempel på hur framtidsförspänning kan introduceras: Tekniska buggar - Arrayvektorer i kod har ofta iteratorer eller indexvariabler. Felaktiga överskott av dessa index kan leda till en förutseende förspänning genom att inkorporera data vid Nk för icke-noll k. Parameterberäkning - Ett annat vanligt exempel på framåtriktad förspänning inträffar vid beräkning av optimala strategiparametrar, t. ex. med linjära regressioner mellan två tidsserier. Om hela datasatsen (inklusive framtida data) används för att beräkna regressionskoefficienterna och sålunda retroaktivt appliceras på en handelsstrategi för optimeringsändamål, införlivas framtida data och en framåtblickande bias finns. MaximaMinima - Vissa handelsstrategier använder sig av extrema värden under en viss tidsperiod, till exempel inkorporering av höga eller låga priser i OHLC-data. Eftersom de maximala minimala värdena endast kan beräknas i slutet av en tidsperiod införs emellertid en blick för framåtblick om dessa värden används under den aktuella perioden. Det är alltid nödvändigt att lagra highlow-värden med minst en period i någon handelsstrategi som använder dem. Precis som med optimeringsförspänning måste man vara ytterst försiktig för att undvika införandet. Det är ofta den främsta anledningen till att handelsstrategier underpresterar deras backtest signifikant i live trading. Survivorship Bias Survivorship bias är ett särskilt farligt fenomen och kan leda till betydligt uppblåst prestanda för vissa strategityper. Det inträffar när strategier testas på dataset som inte inkluderar hela universum av tidigare tillgångar som kan ha blivit utvalda vid en viss tidpunkt, men bara överväga de som har överlevt till den aktuella tiden. Tänk på att testa en strategi för ett slumpmässigt urval av aktier före och efter marknadskraschen 2001. Vissa tekniklager gick i konkurs, medan andra lyckades hålla sig flytande och till och med blomstrade. Om vi ​​hade begränsat den här strategin endast till lager som gjorde det genom marknadsutnyttjandeperioden skulle vi introducera en överlevnadsperspektiv eftersom de redan har visat deras framgång för oss. Faktum är att detta bara är ett annat specifikt fall med förutseende bias, eftersom framtida uppgifter införlivas i tidigare analyser. Det finns två huvudsakliga sätt att mildra överlevnadsförhållanden i dina strategiska backtest: Survivorship Bias Free Datasets - När det gäller egenkapitaldata är det möjligt att köpa dataset som innehåller avnoterade enheter, även om de inte är billiga och bara brukar användas av institutionella företag . I synnerhet är Yahoo Finance-data INTE överlevnadsklausulfri, och detta används vanligtvis av många detaljhandelshandlare. Man kan också handla på tillgångsklasser som inte är benägna att överleva bias, till exempel vissa varor (och deras framtida derivat). Använd mer aktuella data - När det gäller aktier utnyttjar utnyttjandet av en nyare dataset möjligheten att det valda aktievalet vägs till överlevande, helt enkelt eftersom det finns mindre sannolikhet för total avnotering av aktier på kortare tidsperioder. Man kan också börja bygga ett personligt överlevnads-biasfritt dataset genom att samla in data från aktuell punkt framåt. Efter 3-4 år kommer du att ha en solid överlevnads-biasfri uppsättning av aktiedata för att backtest ytterligare strategier. Vi kommer nu att överväga vissa psykologiska fenomen som kan påverka ditt handelsprestanda. Psykologisk tolerans Bias Dessa speciella fenomen diskuteras inte ofta i samband med kvantitativ handel. Det diskuteras emellertid i stor utsträckning när det gäller mer diskretionära handelsmetoder. Det har olika namn, men Ive bestämde sig för att kalla det psykologiska toleransförhållandet eftersom det fångar kärnan i problemet. När man skapar backtest över en period av 5 år eller längre är det lätt att titta på en uppåtgående trender, beräkna den sammanslagna årliga avkastningen, Sharpe-förhållandet och jämn drawdown-egenskaper och vara nöjd med resultaten. Som ett exempel kan strategin ha en maximal relativ drawdown på 25 och en maximal drawdown-varaktighet på 4 månader. Detta skulle inte vara atypiskt för en momentumstrategi. Det är enkelt att övertyga sig om att det är lätt att tolerera sådana förlustperioder eftersom den övergripande bilden är rosig. I praktiken är det dock mycket svårare Om historiska drawdowns på 25 eller fler uppträder i backtestsna, så är det sannolikt att du ser perioder med liknande drawdown i live trading. Dessa uttagsperioder är psykologiskt svåra att uthärda. Jag har observerat första hand vad en förlängd drawdown kan vara, i en institutionell miljö, och det är inte trevligt - även om backtests föreslår att sådana perioder kommer att inträffa. Anledningen till att jag har sagt det en bias är att ofta en strategi som annars skulle bli framgångsrik stoppas från handel under tider av förlängd drawdown och därigenom kommer att leda till signifikant underpresterande jämfört med en backtest. Således, även om strategin är algoritmisk, kan psykologiska faktorer fortfarande ha stor inverkan på lönsamheten. Takeaway är att se till att om du ser dragningar av en viss procentandel och varaktighet i backtestsna, bör du förvänta dig att de uppträder i levande handelsmiljöer och kommer att behöva fortsätta för att nå lönsamhet en gång till. Programvarupaket för backtesting Programvaran landskapet för strategi backtesting är enorm. Lösningar sträcker sig från helintegrerad avancerad sofistikerad programvara till programmeringsspråk som C, Python och R, där nästan allt måste skrivas från början (eller lämpliga plugins erhållna). Som kvanthandlare är vi intresserade av att kunna äga vår handelssteknologistack jämfört med hastigheten och tillförlitligheten i vår utvecklingsmetodik. Här är de viktigaste övervägandena för programval: Programmeringsförmåga - Valet av miljö kommer till stor del att komma ner till din förmåga att programvara programvara. Jag skulle hävda att kontrollen över den totala stacken kommer att få större effekt på din långsiktiga PL än att outsourca så mycket som möjligt till leverantörsprogram. Detta beror på risken att det finns risk för att det finns risk för att det finns externa buggar eller idiosyncrasier som du inte kan fixa i leverantörsprogramvara, vilket annars skulle vara lätt att avhjälpa om du hade mer kontroll över din tech stack. Du vill också ha en miljö som uppnår den rätta balansen mellan produktivitet, tillgänglighet i biblioteket och genomförandegraden. Jag gör min egen personliga rekommendation nedan. Execution CapabilityBroker Interaction - Vissa backtesting programvara, som Tradestation, kopplar direkt i en mäklare. Jag är inte en fan av detta tillvägagångssätt eftersom minskade transaktionskostnader ofta är en stor del av att få ett högre Sharpe-förhållande. Om du är bunden till en viss mäklare (och Tradestation tvingar dig att göra det) kommer du att få en hårdare övergång till ny programvara (eller en ny mäklare) om behovet uppstår. Interaktiva mäklare tillhandahåller ett API som är robust, om än med ett lite stötigt gränssnitt. Anpassning - En miljö som MATLAB eller Python ger dig stor flexibilitet när du skapar algo-strategier, eftersom de ger fantastiska bibliotek för nästan alla matematiska operationer som är tänkbara, men tillåter också omfattande anpassning där det behövs. Strategisk komplexitet - Vissa program är inte skurna ut för tungt talande eller matematisk komplexitet. Excel är ett sådant program. Medan det är bra för enklare strategier, kan det inte riktigt klara av många tillgångar eller mer komplicerade algoritmer, i snabb takt. Bias Minimization - Låter en viss del av programvara eller data sig mer till handelsförskjutningar. Du måste se till att om du vill skapa all funktionalitet själv, så introducerar du inte fel som kan leda till fördomar. Utvecklingshastighet - Man borde inte spendera månader och månader genom att implementera en backtestmotor. Prototypning bör bara ta några veckor. Se till att din programvara inte hindrar dina framsteg i stor utsträckning, bara för att fånga några extra procentpoäng för körhastighet. C är elefanten i rummet här Utföringshastighet - Om din strategi är helt beroende av exekveringstidligheten (som i HFTUHFT), är ett språk som C eller C nödvändigt. Däremot kommer du att verga på Linux-kärnoptimering och FPGA-användning för dessa domäner, vilket ligger utanför ramen för denna artikel. Kostnad - Många av programmiljöerna som du kan programmera algoritmiska handelsstrategier med är helt gratis och öppen källkod. Faktum är att många hedgefonder använder sig av öppen källkodsprogramvara för hela deras algo trading stacks. Dessutom är Excel och MATLAB båda relativt billiga och det finns till och med gratis alternativ till var och en. Nu när vi har listat de kriterier som vi behöver välja vår programvaruinfrastruktur vill jag springa igenom några av de mer populära paketen och hur de jämför: Obs! Jag kommer bara att inkludera programvara som är tillgänglig för de flesta detaljhandlare och mjukvaruutvecklare, eftersom det här är läsaren av webbplatsen. Medan annan programvara är tillgänglig, till exempel de mer institutionella betygsverktygen, anser jag att dessa är för dyra för att kunna användas effektivt i en detaljhandelsinställning och jag har personligen ingen erfarenhet av dem. Backtesting Software Comparison Beskrivning: Språk på hög nivå utformad för utvecklingens hastighet. Brett utbud av bibliotek för nästan alla programmatiska uppgifter som kan tänkas. Att få bredare acceptans i hedgefonden och investeringsbanken. Inte lika snabbt som CC för körhastighet. Exekvering: Python plugins finns för större mäklare, som Interactive Brokers. Därför backtest och exekveringssystem kan alla vara en del av samma tech stack. Anpassning: Python har en mycket hälsosam utvecklingsgemenskap och är ett modent språk. NumPySciPy ger snabbvetenskaplig databehandling och statistisk analysverktyg som är relevanta för kvanthandel. Strategikomplexitet: Många plugins existerar för de viktigaste algoritmerna, men inte riktigt lika stor en kvant gemenskap som existerar för MATLAB. Bias Minimization: Samma bias minimeringsproblem finns som för alla högnivå språk. Behöver vara extremt försiktig med testning. Utvecklingshastighet: Pythons största fördel är utvecklingshastighet, med robust inbyggd testfunktion. Exekveringshastighet: Inte lika snabbt som C, men vetenskapliga datorkomponenter optimeras och Python kan prata med inbyggd C-kod med vissa plugins. Kostnad: FreeOpen Käll Beskrivning: Mogent språk på hög nivå utformad för snabb körning. Brett utbud av kvantitativa finans - och numeriska bibliotek. Svårare att felsöka och tar ofta längre tid att implementera än Python eller MATLAB. Extremt utbredd i både köp - och säljsidan. Exekvering: De flesta mäklare API är skrivna i C och Java. Således finns många plugins. Anpassning: CC tillåter direkt åtkomst till underliggande minne, varför ultrahögfrekventa strategier kan implementeras. Strategikomplexitet: C STL erbjuder ett stort antal optimerade algoritmer. Nästan alla specialiserade matematiska algoritmer har en fri, öppen källkodsimplementering på webben. Biasminimering: Utsiktsförskjutning kan vara knepigt att eliminera, men inte hårdare än andra högnivå språk. Bra felsökningsverktyg, men man måste vara försiktig när man arbetar med underliggande minne. Utvecklingshastighet: C är ganska ordentlig jämfört med Python eller MATLAB för samma algoritm. Fler linjer av kod (LOC) leder ofta till större sannolikhet för buggar. Exekveringshastighet: CC har extremt snabb exekveringshastighet och kan vara väl optimerad för specifika beräkningsarkitekturer. Detta är den främsta anledningen att utnyttja den. Kostnad: Olika kompilatorer: LinuxGCC är gratis, MS Visual Studio har olika licenser. Olika strategier kräver olika mjukvarupaket. HFT - och UHFT-strategier kommer att skrivas i CC (dessa dagar utförs de ofta på GPU och FPGA), medan lågfrekventa riktningsbaserade aktiestrategier är lätta att implementera i TradeStation, på grund av programvaruhandeln i en och samma form. Min personliga preferens är för Python eftersom det ger rätt grad av anpassning, utvecklingshastighet, provningsförmåga och körhastighet för mina behov och strategier. Om jag behöver något snabbare, kan jag släppa in till C direkt från mina Python-program. En metod som favoriseras av många kvanthandlare är att prototyper sina strategier i Python och sedan konvertera de långsammare utföringssektionerna till C på ett iterativt sätt. Så småningom är hela algoet skrivet i C och kan lämnas ensam för handel. I de närmaste artiklarna om backtesting kommer vi att titta på några speciella problem kring implementeringen av ett algoritmiskt backtestingssystem för handel, liksom hur man införlivar effekterna av börser. Vi kommer att diskutera strategiska resultatmätningar och slutligen avsluta med en exempelstrategi. Just Komma igång med Kvantitativ TradingThe Back Test Library för Professional Trading Strategy Developers Tillbaka test är processen att testa handelsstrategier baserat på historiska marknadsdata för att försöka simulera hur ett handelssystem kan utföra i framtiden. Backtestning är att utveckla handelsstrategi vilken forskning och kvalitetsförbättring är inom hälso - och transportindustrin. Vem skulle vilja prova en otestad hjärtmonitor eller bil Ingen. Detsamma gäller för finansiella handelsstrategier. Alla handelsstrategier måste testas, optimeras och valideras innan de går live med riktiga pengar. Nästan någon teknisk analys handelsstrategi kan testas. Även om det är sant att många mellanhandelsprogram för applikationer tillhandahåller skriptspråk som tillåter handlare att utveckla och återställa testhandelsstrategier fann vi att det inte fanns några återprövningsbibliotek tillgängliga för avancerade handelssystemutvecklare som föredrar att programmera sina handelsstrategier i lågnivåprogrammering språk som C, C och Java. Så vi utvecklade en bakprovningsmotor för avancerade systemutvecklare. Nu kan utvecklare skapa strategier i något programmeringsspråk, sedan backtest och optimera dessa strategier för att förbättra prestanda. BackTestLib gör det möjligt för utvecklare att testa sina handelssystem i C, C, VB, F, R, IronPython eller något annat språk med hjälp av fält - eller streckdata. Det spelar ingen roll hur ditt handelssystem är skrivet. Allt du behöver göra är att tillhandahålla en lista över affärer, och det bakre testbiblioteket gör resten för dig. BackTestLib kan beräkna din trading systemprestanda med hjälp av två doser riskmätningar, inklusive Sharpe-förhållandet, Calmar-förhållandet, Sortino-förhållandet, Maximal neddragning, Monte Carlo-neddragning, Totalt PL, Risk för belöningsförhållande, Största vinst, Största förlust, Genomsnittlig antal affärer Månad, Handelsloggar och mer. Perfekt för strategioptimering Professionella handlare vet att alla goda saker kommer till ett slut. Även de bästa handelssystemen hamnar ibland i att förlora perioder, vilket kräver optimering eller handelssystemspensionering. Orsakerna varierar, inklusive förändringar i likviditet, volatilitet och underliggande marknadsdynamik, liksom andra faktorer. BackTestLib-resultaten ger resultat som representerar en rad mätningar baserat på lönsamheten och risken för ditt handelssystem när de testas med de data som den levererades med. Kod Exempel Skapa några simulerade affärer Lista lt Trade gt handlar ny Lista lt Trade gt () trades. Add (ny handel (DateTime. Parse (quot112014 9: 30: 45.422 AMquot), SignalType. Buy, 24)) trades. Add Handel (DateTime. Parse (quot112014 9: 32: 33.891 AMquot), SignalType. ExitLong, 24.09)) trades. Add (ny handel (DateTime. Parse (quot112014 9: 37: 12.839 AMquot), SignalType. Sell, 24.07)).Add (ny handel (DateTime. Parse (quot112014 9: 48: 27.488 AMquot), SignalType. Exx, 24.19)) trades. Add (ny handel (DateTime. Parse (quot112014 9: 49: 16.415 AMquot), SignalType. Buy, 24)) trades. Add (ny handel (DateTime. Parse (quot112014 9: 50: 45.512 AMquot), SignalType. Exit, 24.09)) trades. Add (ny handel (DateTime. Parse (quot112014 9:51: 14.212 AMquot) SignalType. Buy, 24.01)) Kör backtest double lastPrice 24.03 BacktestResults resultat Backtester. Backtest (trades, lastPrice) Utför resultaten Console. WriteLine (antal antal handlar: citerade resultat. TotalNumberOfTrades) Nackdelar ole. WriteLine (antal engagemang per månad: cit. results. AverageTradesPerMonth) Console. WriteLine (antal antal lönsamma trader: citerade results. NumberOfProfitableTrades) Console. WriteLine (antal totalt antal förlorande trader: citerade resultat. NumberOfLosingTrades) Console. WriteLine (quotototal: quot. results. TotalProfit) Console. WriteLine (quotototal förlust: quot. result. TotalLoss) Console. WriteLine (quotPercent profitable trades: quot. result. PercentProfit) Console. WriteLine (quotPercent profitable trades: quot. result. PercentProfit) Console. WriteLine (mest stora vinst: citerade resultat. StörstaProfit) Console. WriteLine (mest stora förlust: citerade resultat. Största lösen) Console. WriteLine (quotMaximum drawdown: quot. resultater. MaximumDrawDown) Console. WriteLine (quotMaximum drawdown Monte Carlo: quot. resultat. MaximumDrawDownMonteCarlo) Console. WriteLine (quotStandard avvikelse : quot. results. StandardDeviation) Console. WriteLine (quotStandard avvikelse årlig: citerade resultat. StandardDeviationAnnualized) Console. WriteLi ne (kvotavvikelse (MAR 10): cit. Results. DownsideDeviationMar10) Console. WriteLine (quotValue Added Monthly Index (VAMI): citerade results. ValueAddedMonthlyIndex) Console. WriteLine (quotSharpe förhållande: quot. results. SharpeRatio) Console. WriteLine (quotSortino förhållande: quot. results. SortinoRatioMAR5) Console. WriteLine (quotAnnualized Sortino-förhållande: citerade resultat. ÄndradSortinoRatioMAR5) Console. WriteLine (quotSterling-förhållande: citerade resultat. SterlingRatioMAR5) Console. WriteLine (quotCalmar ratio: quot. resultater. CalmarRatio) Console. WriteLine (quotRisk till belöningsförhållande: citerade resultat. RiskRewardRatio) Visa handelsloggen (Trade Trade in results. Trades) Console. WriteLine (trade. Date quot: quot trade. Signal. ToString () quot på quot trade. Price. ToString ()) MultiCharts 10 MultiCharts är ett pris - winning trading plattform Oavsett om du behöver daghandel programvara eller du investerar i längre perioder, MultiCharts har funktioner som kan hjälpa till att uppnå dina handelsmål. High-definition kartläggning, inbyggda indikatorer och strategier, ett-klick trading från diagram och DOM, hög precision backtesting, brute-force och genetisk optimering, automatiserat utförande och support för EasyLanguage-skript är alla viktiga verktyg till ditt förfogande. hoice of brokers och data feeds Valfrihet har varit drivsidan bakom MultiCharts och du kan se den i det stora utbudet av data som stöds och mäklare. Välj din handelsmetod, testa den och börja handla med någon stödd mäklare som du gillar. Fördelen med MultiCharts. How att backtest din handelsstrategi korrekt. Många framgångsrika handlare delar en vana 8211 de backtestar sina handelsstrategier. Backtesting din handelsstrategi kommer inte ensam att garantera att du blir lönsam, men det är ett jätte steg i rätt riktning. I den här artikeln undersöker vi några potentiella fördomar som kan krypa in i din backtesting, och vi kommer att titta på hur man minimerar effekterna av dessa förspänningar. Det finns många problem som kan uppstå när du återprövar ditt handelssystem, men de flesta problem faller i en av tre kategorier: postdiktiva fel, för många variabler eller misslyckas med att förutse drastiska förändringar på marknaden. Var och en av dessa fel förklaras, tillsammans med metoder för att undvika fel. Klicka här för att lära dig hur du använder Bollinger Bands med ett kvantifierat, strukturerat tillvägagångssätt för att öka dina handelskanter och säkra större vinster med Trading with Bollinger Bands 8211 A Quantified Guide. 1. Postdictive Error Det postdictiva felet är bara ett fint sätt att säga att du har använt information som endast är tillgänglig 8220 efter faktum8221 för att testa ditt system. Tro det eller inte, det här är ett mycket vanligt fel vid testning av handelssystem. Detta fel är lätt att göra. Vissa program kan du använda today8217s data för att testa ett handelssystem, vilket alltid är ett postdiktivt fel (vi vet inte om today8217s data är användbara än för att förutsäga framtiden, men vi vet säkert om det är användbart för att förutse det förflutna ). Wouldn8217t du älskar att kunna använda slutkursen på GBPUSD för att förutsäga vad marknaden kommer att göra idag. Naturligtvis skulle du definitivt det, men tyvärr är den här informationen inte tillgänglig för oss förrän dagen är över. Till exempel kan du ha ett system som innehåller slutkursen, då innebär det uppenbarligen att handeln inte kan initieras förrän dagen är över. annars är detta ett postdiktivt fel. Ett annat exempel kan hjälpa till att illustrera det postdiktiva felet, om du har en regel i ditt handelssystem om högsta priser, så har du ett postdiktivt fel. Detta beror på att högsta priser ofta definieras av data som kommer senare, i framtiden. Sättet att undvika det postdiktiva felet är att se till att när du backtestar ett system så används endast information som tidigare finns tillgänglig vid backtesting. Med manuell backtesting eller backtesting med forex tester kan du uppnå detta ganska enkelt, men med automatiserad backtesting kan postdictive felet smyga in i ditt handelssystem. 2. För många variabler Detta är också känt som 8220Degrees of Freedom8221 bias. Detta innebär helt enkelt att du har för många variabler eller handelsindikatorer i ditt handelssystem. Det är mycket möjligt att komma fram till ett handelssystem som kan förklara förflutna prisbeteenden hos ett valutapar. Faktum är att ju fler indikatorer du lägger till desto lättare blir det ofta. Problemet kommer när du vill tillämpa detta system för framtiden. Ofta när ett handelssystem har för många indikatorer kan det förutsäga marknadsbeteendet under en tidsperiod extremt bra. Men that8217s är allt systemet bra för, för i framtiden faller systemet ifrån varandra. Ovanstående uttalande är ofta svårt för handlare att komma till rätta med, men det är sant. Tänk på vad William Eckhardt, New Market Wizards har att säga om handelssystem. Generellt sett har de delikata tester som statistiker använder för att klämma ut betydelsen av marginala data inte någon plats i handeln. Vi behöver stumma statistiska instrument, robusta tekniker. Självklart varnar han mot felgraderingsfelet och föreslår att enkla handelssystem är mer benägna att stå tidstest. Detta är helt sant. Några av de mest kraftfulla handelssystemen som finns tillgängliga är extremt enkla. Tänk på detta när du handlar och när du försöker hitta ett lönsamt handelssystem. De flesta handlare kommer att finna att de med erfarenhet blir mer benägna att omfamna synen på att enklare handel är att föredra framför ett komplicerat tillvägagångssätt. 3. Drastiska förändringar på marknaden Många handlare glömmer att förutse oförutsedda händelser som kommer att uppstå i framtiden. Det betyder inte riktigt att du inte vet vad som kommer att hända i framtiden 8211 eftersom du vet det här: det kommer att finnas tider i framtiden när marknaderna kommer att verka orimligt. När detta händer bör du ha utformat ditt handelssystem för att fungera under dessa tider. Kanske kan några exempel hjälpa till med det här: När Saddam Hussein hittades (över helgen) reagerade valutamarknaderna ganska drastiskt på måndagen8217s öppning. När den globala finanskrisen började utvecklas i september 2008 handlades de flesta valutapar med mycket mer volatilitet än vad som hade sett i åratal. Faktum är att det kommer att bli oväntade händelser i framtiden, och dessa händelser kommer att påverka marknaderna, så det bästa du kan göra är att vara beredd. Hur förbereder du dig på det oväntade Tänk på följande enkla lösningar: 1) Överdriv dina förväntade förluster. Om din backtesting avslöjar en maximal förlust på 5000, antar du en maximal förlust på 10 000. Kommer ditt handelssystem fortfarande att vara lönsamt under dessa förhållanden 2) Besluta om en lämplig risknivå för varje handel. Kom ihåg att även denna risknivå kommer sannolikt att överskridas. Om du har bestämt dig för att riskera 1 på varje handel, bör du anta att någon gång i framtiden kan du vara i handeln och en oväntad händelse inträffar, och din handel kommer inte att förlora 1, men i stället kommer 5 att gå vilse. 3) Du bör ha en beredskapsplan upprättad. That is, how will you exit a trade if something bad happens and you cannot access your account For instance, what happens if your trading platform is inaccessible and you desperately want out of a trade Most brokers offer a telephone line to traders for these instances. Do you have the phone number 4) Do you have a maximum risk level set This would be applicable if you have several trades open simultaneously. If you decide to risk 1 per trade and you have 7 trades open simultaneously, does this mean that you will be risking 7 of your account Or have you decided on a maximum risk level of say, 3 Keeping in mind that the unexpected will occur, you should probably have a maximum risk level for those times when you have several open trades. 5) What is the maximum drawdown (amount of money your trading system loses over an extended period of time) you are willing to tolerate Keeping in mind that you (and you are not alone) are more likely to overestimate the severity of drawdowns that you can withstand, it is important to be realistic. If you lose 30 of your account will you stop trading What about if you lose 50 Or if you see 70 of your account disappear Again, the best way to plan for drawdowns is to do extensive backtesting to find out what sort of historical drawdowns your trading system experiences and then plan for even worse drawdowns in the future. Anticipating drastic changes in the markets is the single best way to preserve the equity in your account. So, you know that successful traders share this habit 8211 they backtest their trading strategies. You know that backtesting separates the wealthy traders from those who lose money. You also know several ways of incorporating backtesting into your trading regimen. And you know of the pitfalls 8211 what to look out for 8211 when you are backtesting, so that you can get the most out of the process. But, what exactly, will you get out of backtesting your trading system In the next article I will explore the side effects of backtesting. Walter Peters, PhD is a professional forex trader and money manager for a private forex fund. In addition, Walter is the co-founder of Fxjake. a resource for forex traders. Walter loves to hear from other traders, he can be reached by email at walterfxjake .