C Back Testing Trading Strategier

Vellykket Backtesting of Algorithmic Trading Strategies - Del I Denne artikkelen fortsetter serien om kvantitativ handel, som startet med Beginners Guide og Strategy Identification. Begge disse lengre, mer involverte artiklene har vært veldig populære, så jeg fortsetter i denne venen og gir detaljer om temaet strategi backtesting. Algoritmisk backtesting krever kunnskap om mange områder, inkludert psykologi, matematikk, statistikk, programvareutvikling og marketexchange mikrostruktur. Jeg kunne ikke håpe å dekke alle disse emnene i en artikkel, så jeg skal dele dem i to eller tre mindre biter. Hva skal vi diskutere i denne delen Jeg begynner med å definere backtesting og da vil jeg beskrive grunnleggende om hvordan det utføres. Da vil jeg belyse de forspenninger vi berørte i Beginners Guide to Quantitative Trading. Neste vil jeg presentere en sammenligning av de ulike tilgjengelige backtesting programvare alternativene. I etterfølgende artikler vil vi se nærmere på detaljer om strategibestemmelser som ofte knapt nevnes eller ignoreres. Vi vil også vurdere hvordan å gjøre backtesting prosessen mer realistisk ved å inkludere idiosyncrasies av en trading utveksling. Da vil vi diskutere transaksjonskostnader og hvordan du skal modellere dem riktig i en backtest-innstilling. Vi vil ende med en diskusjon om utførelsen av våre backtests og endelig gi et eksempel på en felles kvantstrategi, kjent som en gjennomsiktig parhandel. La oss begynne med å diskutere hva backtesting er og hvorfor vi bør utføre det i vår algoritmiske handel. Hva er Backtesting Algoritmisk handel står bortsett fra andre typer investeringsklasser fordi vi på en mer pålitelig måte kan gi forventninger om fremtidig ytelse fra tidligere resultater, som en konsekvens av rikelig datatilgjengelighet. Prosessen som dette utføres er kjent som backtesting. Enkelt sagt blir backtesting utført ved å eksponere din spesifikke strategialgoritme til en strøm av historiske økonomiske data, noe som fører til et sett med handelssignaler. Hver handel (som vi vil bety her for å være en rundtur på to signaler) vil ha en tilknyttet fortjeneste eller tap. Akkumuleringen av denne fortjenesten i løpet av strategien din vil føre til total fortjeneste og tap (også kjent som PL eller PnL). Det er essensen av ideen, selv om djevelen selvfølgelig alltid er i detaljene. Hvilke hovedårsaker til backtesting av en algoritmisk strategi Filtrering - Hvis du husker fra artikkelen om strategiidentifikasjon. Vårt mål i den første undersøkelsen var å sette opp en strategipipeline og deretter filtrere ut en strategi som ikke oppfyller visse kriterier. Backtesting gir oss en annen filtreringsmekanisme, da vi kan eliminere strategier som ikke oppfyller våre ytelsesbehov. Modellering - Backtesting gjør det mulig for oss å (trygt) teste nye modeller av bestemte markedsfenomener, for eksempel transaksjonskostnader, ordreruting, latens, likviditet eller andre markedsmiljøstrukturproblemer. Optimalisering - Selv om strategioptimalisering er full av forstyrrelser, gir backtesting oss mulighet til å øke ytelsen til en strategi ved å endre mengden eller verdiene av parametrene knyttet til den strategien og omberegne ytelsen. Verifisering - Våre strategier er ofte hentet eksternt, via vår strategipipeline. Backtesting en strategi sikrer at den ikke har blitt implementert feil. Selv om vi sjelden vil få tilgang til signaler generert av eksterne strategier, har vi ofte tilgang til resultatene som Sharpe Ratio og Drawdown egenskaper. Dermed kan vi sammenligne dem med vår egen implementering. Backtesting gir en rekke fordeler for algoritmisk handel. Det er imidlertid ikke alltid mulig å returtest en strategi. Generelt, ettersom frekvensen av strategien øker, blir det vanskeligere å korrekt modellisere markedets og børsens mikrostruktureeffekter. Dette fører til mindre pålitelige backtests og dermed en vanskeligere vurdering av en valgt strategi. Dette er et spesielt problem hvor eksekveringssystemet er nøkkelen til strategien, som med ultrahøyfrekvente algoritmer. Dessverre er backtesting fulle av forstyrrelser av alle typer. Vi har rørt noen av disse problemene i tidligere artikler, men vi vil nå diskutere dem i dybden. Forstyrrelser som påvirker strategien Backtests Det er mange forstyrrelser som kan påvirke ytelsen til en backtested strategi. Dessverre har disse forutsetningene en tendens til å oppblåse ytelsen i stedet for å forringe den. Dermed bør du alltid vurdere en backtest å være en idealisert øvre grense på den faktiske utførelsen av strategien. Det er nesten umulig å eliminere forstyrrelser fra algoritmisk handel, så det er vår jobb å minimere dem så godt vi kan for å ta informerte beslutninger om våre algoritmiske strategier. Det er fire store forstyrrelser som jeg ønsker å diskutere: Optimalisering Bias. Forsiktig Bias. Overlevelsesforstyrrelser og psykisk toleranse. Optimalisering Bias Dette er trolig den mest lumske av alle backtest-forstyrrelser. Det innebærer å justere eller introdusere ytterligere handelsparametere til strategiens ytelse på backtest datasettet er veldig attraktivt. Men når leve kan resultatene av strategien være markant annerledes. Et annet navn for denne bias er kurvepassing eller data-snooping bias. Optimeringsforstyrrelser er vanskelig å eliminere ettersom algoritmiske strategier ofte involverer mange parametere. Parametre i dette tilfellet kan være inngangskriterier, tilbakekallingsperioder, gjennomsnittsperioder (dvs. den bevegelige gjennomsnittlige utjevningsparameteren) eller volatilitetsmålingsfrekvensen. Optimaliseringsforstyrrelser kan minimeres ved å holde antall parametere til et minimum og øke mengden datapunkter i treningssettet. Faktisk må man også være forsiktig med sistnevnte, da eldre treningssteder kan bli gjenstand for et tidligere regime (for eksempel et lovgivningsmiljø) og dermed ikke er relevant for din nåværende strategi. En metode for å redusere denne bias er å utføre en følsomhetsanalyse. Dette betyr at parametrene varierer trinnvis og plotter ytelsesytelsen. Lyd, grunnleggende begrunnelse for parametervalg bør med alle andre faktorer anses å føre til en jevnere parameteroverflate. Hvis du har en veldig hoppende ytelsesflate, betyr det ofte at en parameter ikke reflekterer et fenomen og er en gjenstand for testdataene. Det er en stor litteratur om multidimensjonale optimaliseringsalgoritmer, og det er et svært aktivt forskningsområde. Jeg vil ikke dvele på det her, men hold det i bakhodet når du finner en strategi med en fantastisk backtest Look-Ahead Bias Look-ahead bias blir introdusert i et backtesting system når fremtidige data ved et uhell er inkludert i et punkt i simulering der dataene ikke ville ha vært tilgjengelige. Hvis vi kjører backtesten kronologisk, og vi når tidpunkt N, forekommer fremtidsforspenning hvis data er inkludert for noe punkt Nk, hvor k0. Look-ahead bias feil kan være utrolig subtil. Her er tre eksempler på hvordan fremtidsforstyrrelser kan innføres: Tekniske feil - Arrayvektorer i kode har ofte iteratorer eller indeksvariabler. Feilreguleringer av disse indeksene kan føre til en forutgående forspenning ved å inkorporere data ved Nk for ikke-null k. Parameterberegning - Et annet vanlig eksempel på fremtidsforspenning skjer når man beregner optimale strategiparametere, for eksempel med lineære regresjoner mellom to tidsserier. Hvis hele datasettet (inkludert fremtidige data) brukes til å beregne regresjonskoeffisientene, og dermed på en retroaktiv måte brukes til en handelsstrategi for optimalisering, blir fremtidige data innarbeidet, og en forutgående forspenning eksisterer. MaximaMinima - Visse handelsstrategier gjør bruk av ekstreme verdier i en hvilken som helst tidsperiode, for eksempel å inkorporere høye eller lave priser i OHLC-data. Men siden disse maksimalminimalverdiene bare kan beregnes i slutten av en tidsperiode, innføres en blikkprøveforventning hvis disse verdiene brukes - i løpet av den nåværende perioden. Det er alltid nødvendig å lagre highlow-verdier med minst en periode i enhver handelsstrategi som bruker dem. Som med optimaliseringsforstyrrelser, må man være svært forsiktig med å unngå introduksjonen. Det er ofte den viktigste grunnen til at handelsstrategier undergraver sine backtests betydelig i live trading. Survivorship Bias Survivorship bias er et spesielt farlig fenomen og kan føre til betydelig oppblåst ytelse for bestemte strategityper. Det oppstår når strategier testes på datasett som ikke inkluderer hele universet av tidligere eiendeler som kan ha blitt valgt på et bestemt tidspunkt, men bare vurdere de som har overlevd til nåværende tid. For eksempel, vurder å teste en strategi for et tilfeldig utvalg av aksjer før og etter 2001-markedet. Noen teknologilager gikk konkurs, mens andre klarte å holde seg flytende og til og med blomstre. Hvis vi hadde begrenset denne strategien bare til aksjer som gjorde det gjennom markedsutvinningsperioden, ville vi innføre en overlevelsesforstyrrelser fordi de allerede har demonstrert deres suksess for oss. Faktisk er dette bare et annet spesifikt tilfelle av fremtidsforspenning, da fremtidig informasjon innlemmes i tidligere analyser. Det er to hovedveier for å redusere overlevelsesforstyrrelser i strategistøttene dine: Survivorship Bias Free Datasets - I tilfelle av egenkapitaldata er det mulig å kjøpe datasett som inkluderer avnoterte enheter, selv om de ikke er billige og bare pleier å bli benyttet av institusjonelle firmaer . Spesielt er Yahoo Finance-data ikke overlevert bias gratis, og dette brukes ofte av mange forhandlere av algo-handelsfolk. Man kan også handle på aktivaklasser som ikke er tilbøyelige til overlevelse, slik som visse varer (og deres fremtidige derivater). Bruk mer nylige data - For aksjer reduserer bruk av et nyere datasett muligheten for at aksjeseleksjonen er vektet til overlevende, ganske enkelt fordi det er mindre sannsynlighet for total avnotering av aksjer i kortere tidsperioder. Man kan også begynne å bygge et personlig overlevelses-bias-datasett ved å samle inn data fra nåværende punkt videre. Etter 3-4 år vil du ha et solidt overlevelses-bias-fritt sett med aksjedata for å backtest videre strategier. Vi vil nå vurdere visse psykologiske fenomener som kan påvirke din trading ytelse. Psykologisk toleranse Bias Disse spesielle fenomenene diskuteres ikke ofte i forbindelse med kvantitativ handel. Det diskuteres imidlertid mye med hensyn til mer skjønnsmessige handelsmetoder. Det har forskjellige navn, men jeg bestemte meg for å kalle det psykisk toleranseforstyrrelser fordi det fanger essensen av problemet. Når du lager backtest over en periode på 5 år eller mer, er det enkelt å se på en oppadgående egenkapitalkurve, beregne den sammensatte årlige avkastningen, Sharpe-forholdet og til og med trekkegenskaper og være fornøyd med resultatene. Som et eksempel kan strategien ha en maksimal relativ drawdown på 25 og en maksimal trekkvarighet på 4 måneder. Dette ville ikke være atypisk for en momentumstrategi. Det er greit å overbevise seg om at det er lett å tolerere slike perioder med tap fordi det generelle bildet er rosenrødt. Men i praksis er det langt vanskeligere Hvis historiske trekk på 25 eller flere forekommer i backtestene, så vil du med all sannsynlighet se perioder med tilsvarende drawdown i live trading. Disse periodene med drawdown er psykologisk vanskelig å tåle. Jeg har observert første hånd hva en utvidet drawdown kan være, i en institusjonell setting, og det er ikke hyggelig - selv om backtestene tyder på at slike perioder vil oppstå. Grunnen til at jeg har betegnet det er en forspenning er at ofte en strategi som ellers ville lykkes, blir stoppet fra handel i tider med utvidet drawdown og dermed vil føre til betydelig underprestering sammenlignet med en backtest. Selv om strategien er algoritmisk i naturen, kan psykologiske faktorer fremdeles ha stor innflytelse på lønnsomheten. Takeaway er å sikre at hvis du ser drawdowns av en viss prosentandel og varighet i backtestene, bør du forvente at de skal skje i live tradingmiljøer, og må fortsette for å oppnå lønnsomhet en gang til. Programvarepakker for Backtesting Programvarelandskapet for strategi backtesting er enorm. Løsninger spenner fra fullstendig integrert institusjonell sofistikert programvare til programmeringsspråk som C, Python og R, hvor nesten alt må skrives fra bunnen av (eller passende plugins oppnådd). Som kvanthandlere er vi interessert i balansen mellom å være i stand til å eie vår handelssteknologistakk versus hastigheten og påliteligheten til vår utviklingsmetode. Her er de viktigste hensynene til programvarevalg: Programmeringsevner - Valget av miljø vil i stor grad komme ned til din evne til å programmere programvare. Jeg vil hevde at å være i kontroll over den totale stabelen vil ha større effekt på din langsiktige PL enn å outsourcing så mye som mulig til leverandørprogramvare. Dette skyldes ulemperrisikoen for å ha eksterne feil eller idiosyncrasier som du ikke klarer å fikse i leverandørprogramvare, noe som ellers lett kunne løses hvis du hadde mer kontroll over din tech stack. Du vil også ha et miljø som oppnår den rette balansen mellom produktivitet, tilgjengelighet for bibliotek og utførelseshastighet. Jeg lager min egen personlige anbefaling nedenfor. Execution CapabilityBroker Interaction - Visse backtesting programvare, for eksempel Tradestation, binder direkte med en megling. Jeg er ikke en fan av denne tilnærmingen, da redusering av transaksjonskostnader ofte er en stor del av å få et høyere Sharpe-forhold. Hvis du er bundet til en bestemt megler (og Tradestation tvinger deg til å gjøre dette), vil du få en vanskeligere overgang til ny programvare (eller en ny megler) hvis behovet oppstår. Interaktive meglere gir en API som er robust, om enn med et litt stødig grensesnitt. Tilpasning - Et miljø som MATLAB eller Python gir deg stor fleksibilitet når du oppretter algo-strategier, da de gir fantastiske biblioteker til nesten alle matematiske operasjoner som er tenkelige, men tillater også omfattende tilpasning der det er nødvendig. Strategi Kompleksitet - Visse programmer bare ikke kutte ut for tunge nummer crunching eller matematisk kompleksitet. Excel er et slikt stykke programvare. Selv om det er bra for enklere strategier, kan det egentlig ikke takle mange eiendeler eller mer kompliserte algoritmer, med fart. Bias Minimization - Låner et bestemt stykke programvare eller data seg mer til handelsforstyrrelser Du må sørge for at hvis du vil lage all funksjonalitet selv, at du ikke introduserer feil som kan føre til forstyrrelser. Hastighet for utvikling - Man bør ikke bruke måneder og måneder til å implementere en backtest-motor. Prototyping bør bare ta noen uker. Pass på at programvaren din ikke hindrer fremgangen din i stor grad, bare for å få tak i noen ekstra prosentpoeng av eksekveringshastighet. C er elefanten i rommet her Utførelseshastighet - Hvis strategien din er helt avhengig av eksekveringsaktualitet (som i HFTUHFT), vil et språk som C eller C være nødvendig. Imidlertid vil du være opptatt av Linux-kjerneoptimalisering og FPGA-bruk for disse domenene, som ligger utenfor rammen av denne artikkelen. Kostnad - Mange av programvaremiljøene du kan programmere algoritmiske handelsstrategier med, er helt gratis og åpen kildekode. Faktisk gjør mange hedgefond bruk av åpen kildekode-programvare for hele algo trading stacks. I tillegg er Excel og MATLAB begge relativt billige, og det finnes til og med gratis alternativer til hver. Nå som vi har listet opp kriteriene som vi trenger å velge programvareinfrastruktur, vil jeg kjøre gjennom noen av de mer populære pakkene og hvordan de sammenligner: Merk: Jeg skal bare inkludere programvare som er tilgjengelig for de fleste forhandlere og programvareutviklere, da dette er leseren av nettstedet. Mens annen programvare er tilgjengelig, for eksempel de mer institusjonelle verktøyene, føler jeg at disse er for dyrt for å bli brukt effektivt i en detaljhandel, og jeg har ingen erfaring med dem. Backtesting Software Comparison Beskrivelse: Språk på høyt nivå designet for utviklingshastighet. Bredt utvalg av biblioteker for nesten enhver programmatisk oppgave å tenke seg. Oppnå bredere aksept i hedgefond og investeringsbank samfunn. Ikke helt så fort som CC for eksekveringshastighet. Gjennomføring: Python plugins finnes for større meglere, som Interactive Brokers. Derfor kan backtest og exekveringssystem alle være en del av samme tech stack. Tilpassing: Python har et veldig sunt utviklingssamfunn og er et modent språk. NumPySciPy gir rask vitenskapelig databehandling og statistisk analyseverktøy som er relevant for kvanthandel. Strategi Kompleksitet: Mange plugins eksisterer for de viktigste algoritmer, men ikke helt like stort et kvant-fellesskap som eksisterer for MATLAB. Bias Minimization: Samme bias minimeringsproblemer eksisterer som for alle høynivå språk. Trenger å være ekstremt forsiktig med testing. Utviklingshastighet: Pythons største fordel er utviklingshastighet, med robust innebygget testingskapasitet. Utføringshastighet: Ikke like rask som C, men vitenskapelige databehandlingskomponenter er optimalisert, og Python kan snakke med innfødt C-kode med visse plugins. Kostnad: FreeOpen Kilde Beskrivelse: Eldre språk på høyt nivå designet for hastighet av utførelse. Bredt utvalg av kvantitative finans - og numeriske biblioteker. Hardere å feilsøke og tar ofte lengre tid å implementere enn Python eller MATLAB. Ekstremt utbredt i både kjøp og salg. Utførelse: De fleste meglerprogrammer er skrevet i C og Java. Dermed finnes mange plugins. Tilpasning: CC gir direkte tilgang til underliggende minne, og dermed kan ultrahøyfrekvensstrategier implementeres. Strategi Kompleksitet: C STL gir et bredt utvalg av optimaliserte algoritmer. Nesten enhver spesialisert matematisk algoritme besitter en fri, åpen kildekode-CC-implementering på nettet. Bias Minimization: Forsiktig forspenning kan være vanskelig å eliminere, men ikke vanskeligere enn andre høyt språk. Gode ​​feilsøkingsverktøy, men man må være forsiktig når man arbeider med underliggende minne. Utviklingshastighet: C er ganske ordentlig i forhold til Python eller MATLAB for samme algoritme. Flere linjer av kode (LOC) fører ofte til større sannsynlighet for feil. Utføringshastighet: CC har ekstremt hurtig eksekveringshastighet og kan være godt optimalisert for spesifikke beregningsarkitekturer. Dette er hovedgrunnen til å utnytte det. Kostnad: Ulike kompilatorer: LinuxGCC er gratis, MS Visual Studio har forskjellige lisenser. Ulike strategier vil kreve forskjellige programvarepakker. HFT - og UHFT-strategier vil bli skrevet i CC (i disse dager utføres de ofte på GPUer og FPGAer), mens lavfrekvente retningsbestemte egenkapitalstrategier er enkle å implementere i TradeStation, på grunn av alt i en art av softwarebrokerage. Min personlige preferanse er for Python, da den gir riktig grad av tilpasning, utviklingshastighet, testingskapasitet og eksekveringshastighet for mine behov og strategier. Hvis jeg trenger noe raskere, kan jeg slippe inn til C direkte fra mine Python-programmer. En metode favorisert av mange kvanthandlere er å prototype deres strategier i Python og deretter konvertere de langsommere utførelseseksjonene til C på en iterativ måte. Til slutt er hele algoet skrevet i C og kan stå alene for handel. I de neste artiklene om backtesting vil vi se på enkelte problemer rundt implementeringen av et algoritmisk trading backtesting system, samt hvordan å innlemme effektene av handelsutveksling. Vi vil diskutere måling av strategisk ytelse og til slutt konkludere med en eksempelstrategi. Bare Komme i gang med kvantitativ TradingThe Back Testing Library for Professional Trading Strategy Utviklere Back testing er prosessen med testing trading strategier basert på historiske markedsdata for å forsøke å simulere hvordan et handelssystem kan utføre i fremtiden. Back testing er å utvikle handelsstrategi hvilken forskning og kvalitetsforbedring er til helsevesenet og transportindustrien. Hvem ønsker å prøve ut en uprøvd hjerteovervåkning eller bil Ingen. Det samme gjelder for finansielle handelsstrategier. Alle handelsstrategier må testes, optimaliseres og godkjennes før de går live med ekte penger. Nesten enhver teknisk analyse handelsstrategi kan testes. Selv om det er sant at mange mellomstore handelsprogrammer gir skriptspråk som tillater handelsmenn å utvikle og tilbakestille testhandelsstrategier, fant vi at det ikke var noen testbiblioteker tilgjengelig for avanserte handelssystemutviklere som foretrekker å programmere handelsstrategier i lavt nivå programmering språk som C, C og Java. Så utviklet vi en testmaskin for tilbakemelding til avanserte systemutviklere. Nå kan utviklere lage strategier i hvilket som helst programmeringsspråk, deretter tilbake test og optimalisere disse strategiene for å forbedre ytelsen. BackTestLib tillater utviklere å teste sine handelssystemer i C, C, VB, F, R, IronPython eller et hvilket som helst annet språk ved å bruke tipp - eller bardata. Det spiller ingen rolle hvordan handelssystemet ditt er skrevet. Alt du trenger å gjøre er å levere en liste over bransjer, og bakprøvebiblioteket gjør resten for deg. BackTestLib kan beregne ditt trading system ytelse ved hjelp av to dusin risikomålinger, inkludert Sharpe forhold, Calmar forhold, Sortino forhold, Maksimal nedtrekk, Monte Carlo nedtrekk, Totalt PL, Risiko for belønning, Største fortjeneste, Største tap, Gjennomsnittlig antall handler Måned, Handelslogger og mer. Perfekt for strategioptimalisering Profesjonelle handelsfolk vet at alle gode ting kommer til en slutt. Selv de beste handelssystemene faller til slutt i å miste perioder, noe som krever optimalisering eller trading system pensjonering. Årsaker varierer, inkludert endringer i likviditet, volatilitet og underliggende markedsdynamikk, samt andre faktorer. BackTestLib-utgangene gir resultater som representerer en rekke målinger basert på lønnsomhet og risiko for ditt handelssystem når de testes med dataene som den ble levert med. Kodeeksempel Lag noen simulerte handler Liste lt Handel gt handler ny Liste lt Handel gt () trades. Add (ny handel (DateTime. Parse (quot112014 9: 30: 45.422 AMquot), SignalType. Buy, 24)) trades. Add Trade (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)) handler. Add (ny handel (DateTime. Parse (quot112014 9: 48: 27.488 AMquot), SignalType. Exit, 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)) Kjør backtest double lastPrice 24.03 BacktestResults resultater Backtester. Backtest (trades, lastPrice) Utfør resultatene Console. WriteLine (quotTotal antall handler: quotes results. TotalNumberOfTrades) Cons ole. WriteLine (quotAverage antall handler per måned: quot. Results. AverageTradesPerMonth) Console. WriteLine (total antall lønnsomme handler: quot. resultater. NumberOfProfitableTrades) Console. WriteLine (total antall tapende handler: quot. resultater. NumberOfLosingTrades) Console. WriteLine (quotototalt resultat: quot. resultater. TotalProfit) Console. WriteLine (quotTotal tap: quot. result. TotalLoss) Console. WriteLine (quotPercent profitable trades: quot. result. PercentProfit) Console. WriteLine (quotPercent profitable trades: quot. result. PercentProfit) Console. WriteLine (quotareste resultat:.LastesteProfit) Console. WriteLine (quotLargestLoss).Console. WriteLine (quotMaximum drawdown: quot. resultater. MaximumDrawDown) Console. WriteLine (quotMaximum drawdown Monte Carlo: quot. Results. MaximumDrawDownMonteCarlo) Console. WriteLine (quotStandard avvik : quot. resultater. StandardDeviation) Console. WriteLine (quotStandard avvik årlig: quot. resultater. StandardDeviationAnnualized) Console. WriteLi ne (quotDownside avvik (MAR 10): quot. Results. DownsideDeviationMar10) Console. WriteLine (quotValue Added Monthly Index (VAMI): quot. resultater. ValueAddedMonthlyIndex) Console. WriteLine (quotSharpe ratio: quot. results. SharpeRatio) Konsoll. WriteLine (quotSortino ratio: quot. results. SortinoRatioMAR5) Console. WriteLine (quotAnnualized Sortino ratio: quot. result. nnualizedSortinoRatioMAR5) Console. WriteLine (quotSterling ratio: quot. resultater. SterlingRatioMAR5) Console. WriteLine (quotCalmar ratio: quot. resultater. CalmarRatio) Console. WriteLine (quotRisk til belønningsforhold:.RiskRewardRatio) Vis handelsloggen foreach (Trade trade in results. Trades) Console. WriteLine (trade. Date quot: quot trade. Signal. ToString () quote på quot trade. Price. ToString ()) MultiCharts 10 MultiCharts er en pris - winning trading plattform Enten du trenger programvare for dagshandel eller investerer i lengre perioder, har MultiCharts funksjoner som kan bidra til å nå dine handelsmål. High-definition kartlegging, innebygde indikatorer og strategier, ett-klikk trading fra diagram og DOM, høy presisjon backtesting, brute-force og genetisk optimalisering, automatisert utførelse og støtte for EasyLanguage-skript er alle viktige verktøyene til din disposisjon. hoice of brokers og data feeds Valgfrihet har vært drivende ideen bak MultiCharts, og du kan se den i det brede valget av støttede datafeed og meglere. Velg din handelsmetode, test den og begynn å handle med noen støttet megler du liker, fordelen ved MultiCharts. Slik backtest Din Trading Strategy Correct Mange vellykkede handelsmenn deler en vane 8211 de backtest deres handelsstrategier. Backtesting din handelsstrategi vil ikke alene garantere at du vil bli lønnsom, men det er et stort skritt i riktig retning. I denne artikkelen undersøker vi noen potensielle forstyrrelser som kan krype inn i din backtesting, og vi vil se på hvordan du minimerer virkningen av disse forstyrrelsene. Det er mange problemer som kan oppstå når du kontrollerer ditt handelssystem, men de fleste problemene faller inn i en av tre kategorier: postdiktive feil, for mange variabler eller unnlater å forutse drastiske endringer i markedet. Hver av disse feilene er forklart, sammen med metoder for å unngå feil. Klikk her for å lære hvordan du bruker Bollinger Bands med en kvantifisert, strukturert tilnærming for å øke dine handelskanter og sikre større gevinster med Trading med Bollinger Bands 8211 A Quantified Guide. 1. Postdictive Error Den postdictive feilen er bare en fancy måte å si at du har brukt informasjon som bare er tilgjengelig 8220after the fact8221 for å teste systemet. Tro det eller ei, dette er en veldig vanlig feil ved testing av handelssystemer. Denne feilen er lett å lage. Noen programvare vil tillate deg å bruke data i dag82 i test av et handelssystem, som alltid er en postdiktiv feil (vi vet ikke om dataene fra today8217 er nyttige ennå for å forutsi fremtiden, men vi vet sikkert om det er nyttig å forutsi fortiden ). Wouldn8217t du elsker å kunne bruke sluttprisen på GBPUSD for å forutsi hva markedet vil gjøre i dag. Selvfølgelig ville du definitivt, men dessverre, denne informasjonen er ikke tilgjengelig for oss før dagen er over. For eksempel kan du ha et system som inkorporerer sluttkurs, da betyr dette åpenbart at handel ikke kan startes før dagen er over. ellers er dette en postdiktiv feil. Et annet eksempel kan bidra til å illustrere den postdiktive feilen, hvis du har en regel i handelssystemet om høyeste priser, så har du en postdiktiv feil. Dette skyldes at høyeste priser ofte defineres av data som kommer senere, i fremtiden. Måten å unngå den postdiktive feilen er å sørge for at når du backtester et system, blir det kun brukt informasjon som er tilgjengelig i det siste på det tidspunktet i backtesting. Med manuell backtesting eller backtesting med forex tester kan du oppnå dette ganske enkelt, men med automatisert backtesting kan postdiktiv feilen snike seg inn i ditt trading system. 2. For mange variabler Dette er også kjent som 8220Degrees of Freedom8221 bias. Dette betyr ganske enkelt at du har for mange variabler eller handelsindikatorer i ditt handelssystem. Det er veldig mulig å komme opp med et handelssystem som kan forklare fortidspraksis for et valutapar. Faktisk, jo flere indikatorer du legger til, desto lettere blir det ofte. Problemet kommer når du vil bruke dette systemet til fremtiden. Ofte når et handelssystem har for mange indikatorer, kan det forutsi markedets oppførsel over en tidsperiode ekstremt godt. Men at8217 er alt systemet bra for, fordi i framtiden faller systemet fra hverandre. Ovennevnte erklæring er ofte vanskelig for handelsmenn å ta tak i, men det er sant. Tenk på hva William Eckhardt, New Market Wizards har å si om handelssystemer. Generelt har de delikate tester som statistikere bruker for å presse betydningen ut av marginale data, ikke noe sted i handel. Vi trenger stumme statistiske instrumenter, robuste teknikker. Selvfølgelig advarer han mot graden av frihetsfeil og tyder på at enkle handelssystemer er mer sannsynlig å stå tidstest. Dette er helt sant. Noen av de mest kraftfulle handelssystemene som er tilgjengelige, er svært enkle. Husk dette når du handler, og som du forsøker å finne et lønnsomt handelssystem. De fleste handelsfolk vil finne at med erfaring blir de mer sannsynlig å omfavne det syn at enklere handel foretrekkes over en kompleks tilnærming. 3. Drastiske endringer i markedet Mange forhandlere glemmer å forutse uforutsette hendelser som vil skje i fremtiden. Det betyr egentlig ikke noe at du ikke vet hva som skal skje i fremtiden 8211 fordi du vet dette: det vil være tider i fremtiden når markedene vil oppføre seg ulovlig. Når dette skjer, bør du ha designet ditt handelssystem for å fortsette å fungere i disse tider. Kanskje noen eksempler kan hjelpe til med dette: Når Saddam Hussein ble funnet (over helgen) reagerte valutamarkedene ganske drastisk på åpningen av mandag8217. Da den globale finanskrisen begynte å utfolde seg i september 2008, handlet de fleste valutapar med mye mer volatilitet enn det som hadde vært sett i årevis. Faktum er at det vil bli uventede hendelser i fremtiden, og disse hendelsene vil påvirke markedene, så det beste du kan gjøre er å være forberedt. Hvordan forbereder du deg på det uventede Vurder disse enkle løsningene: 1) Overstyr dine forventede tap. Hvis din backtesting viser et maksimalt tap på 5000, antar du maksimalt tap på 10.000. Vil dine handelssystemer fortsatt være lønnsomme under disse forholdene 2) Bestem et passende risikonivå for hver handel. Husk at selv dette risikonivået vil sannsynligvis bli overskredet. Hvis du har bestemt deg for å risikere 1 på hver handel, bør du anta at en gang i fremtiden kan du være i en handel, og en uventet hendelse vil oppstå, og handelen din vil ikke miste 1, men i stedet vil 5 gå tapt. 3) Du bør ha en beredskapsplan satt opp. Det vil si hvordan vil du avslutte en handel hvis noe skjer, og du kan ikke få tilgang til kontoen din. For eksempel, hva skjer hvis handelsplattformen din er utilgjengelig og du desperat vil ha en handel. De fleste meglere tilbyr en telefonlinje til forhandlere for disse tilfellene. Har du telefonnummeret 4) Har du et maksimalt risikonivåsett Dette vil gjelde hvis du har flere bransjer åpne samtidig. Hvis du bestemmer deg for å risikere 1 per handel, og du har 7 handler åpne samtidig, betyr dette at du vil risikere 7 av kontoen din eller har bestemt deg for et maksimalt risikonivå, for eksempel 3. Husk at det uventede vil skje, du bør nok ha et maksimalt risikonivå for de tidene når du har flere åpne handler. 5) Hva er maksimal drawdown (hvor mye penger ditt handelssystem mister over en lengre periode) du er villig til å tolerere å huske på at du (og du ikke er alene) er mer sannsynlig å overvurdere graden av drawdowns som du kan tåle, er det viktig å være realistisk. Hvis du mister 30 av kontoen din, slutter du å handle. Hva med om du mister 50 Eller hvis du ser 70 av kontoen din forsvinner Igjen, den beste måten å planlegge for drawdowns er å gjøre omfattende backtesting for å finne ut hva slags historiske drawdowns din handel systemopplevelser og planlegg for enda verre drawdowns i fremtiden. Å forutse drastiske endringer i markedene er den enkleste måten å bevare egenkapitalen på kontoen din. Så, du vet at vellykkede handelsmenn deler denne vanen 8211 de backtest deres handelsstrategier. Du vet at backtesting skiller de velstående handelsmennene fra de som mister penger. Du vet også flere måter å inkorporere backtesting inn i ditt handelsregime. Og du vet om fallgruvene 8211 hva du skal se etter 8211 når du er på nytt, slik at du kan få mest mulig ut av prosessen. Men, hva vil du egentlig få ut av å teste ditt handelssystem? I neste artikkel vil jeg undersøke bivirkningene av backtesting. Walter Peters, PhD er en profesjonell forexhandler og pengeforvalter for et privat forexfond. I tillegg er Walter medstifter av Fxjake. en ressurs for valutahandlere. Walter elsker å høre fra andre handelsmenn, han kan nås via e-post på walterfxjake.