Trading Strategi Backtesting Eksempel

Back-testing dine handelsideer En av de mest nyttige tingene du kan gjøre i analysevinduet, er å teste teststrategien din på historiske data. Dette kan gi deg verdifull innsikt i styrker og svake punkter i systemet ditt før du investerer ekte penger. Denne enkle AmiBroker-funksjonen kan spare mye penger for deg. Skrive dine handelsregler Først må du ha objektive (eller mekaniske) regler for å gå inn og ut av markedet. Dette trinnet er grunnlaget for strategien din, og du må tenke på det selv, siden systemet må samsvare med risikotoleransen, porteføljestørrelsen, pengenehåndteringsteknikker og mange andre individuelle faktorer. Når du har egne regler for handel, bør du skrive dem som kjøp og salg av regler i AmiBroker Formula Lanugage (pluss kort og omslag hvis du vil teste også kort handel). I dette kapittelet vurderer vi veldig grunnleggende glidende gjennombruddssystem. Systemet vil kjøpe aksjekontrakter når nærprisen stiger over 45-dagers eksponentielt glidende gjennomsnitt og vil selge stockscontracts når nær pris faller under 45-dagers eksponentielt glidende gjennomsnitt. Det eksponentielle glidende gjennomsnittet kan beregnes i AFL ved hjelp av den innebygde funksjonen EMA. Alt du trenger å gjøre er å spesifisere inngangsarrangementet og gjennomsnittsperioden, slik at det 45-dagers eksponentielle glidende gjennomsnittet av sluttkursene kan oppnås med følgende erklæring: Den nære identifiseringen refererer til innebygd array-holdings sluttkurs for nåværende analysert symbol . For å teste om den nærtliggende prisen krysser over eksponentielt glidende gjennomsnitt, bruker vi innebygd kryssfunksjon: Kjøp kryss (Lukk, ema (Lukk, 45)) Ovennevnte setning definerer en buy trading regel. Det gir quot1quot eller quottruequot når nær pris krysser over ema (lukk, 45). Da kan vi skrive selgeregelen som vil gi quot1quot når motsatt situasjon skjer - Lukk priskryss under ema (nær 45): selg kors (ema (close, 45), lukk) Vær oppmerksom på at vi bruker samme kryssfunksjon, men den motsatte rekkefølgen av argumenter. Så komplett formel for lange handler ser slik ut: kjøp kryss (lukk, ema (lukk 45)) selg kryss (ema (lukk 45), lukk) MERK: For å opprette ny formel vennligst åpne Formula Editor ved hjelp av Analysis-gtFormula Editor meny, skriv inn formelen og velg Verktøy-gtSend til analyse-menyen i Formula Editor. For å back-test systemet, klikk bare på Back test-knappen i vinduet Automatisk analyse. Pass på at du har skrevet inn formelen som inneholder minst kjøp og salg av handelsregler (som vist ovenfor). Når formelen er riktig begynner AmiBroker å analysere symbolene dine i henhold til handelsreglene dine, og genererer en liste over simulerte bransjer. Hele prosessen er veldig rask - du kan prøve å teste tusenvis av symboler på noen minutter. Fremdriftsvinduet viser deg beregnet sluttidspunkt. Hvis du vil stoppe prosessen, kan du bare klikke på Avbryt-knappen i fremdriftsvinduet. Når prosessen er ferdig, vises listen over simulerte handler nederst i automatiske analysevinduet. (Resultatpanelet). Du kan undersøke når kjøp og salg signaler skjedde bare ved å dobbeltklikke på handelen i resultatruten. Dette gir deg rå eller ufiltrerte signaler for hver bar når kjøps - og salgsbetingelsene er oppfylt. Hvis du vil se bare single trade-piler (åpning og lukking for øyeblikket valgt handel), bør du dobbeltklikke på linjen mens du holder SHIFT-tasten nede. Alternativt kan du velge hvilken type skjerm ved å velge passende element fra hurtigmenyen som vises når du klikker på resultatruten med høyre museknapp. I tillegg til resultatlisten kan du få svært detaljert statistikk over ytelsen til systemet ditt ved å klikke på Rapporter-knappen. For å finne ut mer om rapportstatistikk, sjekk ut rapportvindubeskrivelsen. Endre testinnstillingene for tilbakestilling Tilbakeprøvningsmotoren i AmiBroker bruker noen forhåndsdefinerte verdier for å utføre oppgaven, inkludert porteføljestørrelsen, periodiciteten (daglig hver måned), provisjonsbeløp, rentesats, maksimal tap og fortjeneste målstopp, type handler, prisfelt og så på. Alle disse innstillingene kan endres av brukeren ved hjelp av innstillingsvinduet. Når du har endret innstillinger, vær så snill å husk å kjøre testen på nytt hvis du vil at resultatene skal synkroniseres med innstillingene. For eksempel, for å tilbakestille testen på ukentlige barer i stedet for daglig bare klikk på Innstillinger-knappen, velg Weekly from Periodicity combo-boksen og klikk OK. Kjør deretter analysen din ved å klikke på Tilbake test. Reserverte variabelnavn Følgende tabell viser navnene på reservert variabler som brukes av Automatic Analyzer. Betydningen og eksemplene på bruk av dem er gitt senere i dette kapittelet. Tillater kontroll dollarbeløp eller prosentandel av porteføljen som er investert i handelen (se forklaringer nedenfor) Automatisk analyse (ny i 3.9) Hittil har vi diskutert ganske enkel bruk av back testeren. AmiBroker støtter imidlertid mye mer sofistikerte metoder og konsepter som vil bli diskutert senere i dette kapittelet. Vær oppmerksom på at nybegynneren først skal spille litt med de enklere emnene som er beskrevet ovenfor, før du fortsetter. Så når du er klar, ta en titt på følgende nylig introduserte funksjoner i back-testeren: a) AFL-scripting-vert for avanserte formelskribenter b) forbedret støtte for korte handler c) måten å kontrollere ordreutføringsprisen fra script d) ulike typer stopp i back tester e) plassering størrelse f) runde størrelse og tick størrelse g) margin konto h) backtesting futures AFL scripting vert er et avansert tema som er dekket i et eget dokument tilgjengelig her og jeg vil ikke diskutere det i dette dokumentet. Resterende funksjoner er mye lettere å forstå. I tidligere versjoner av AmiBroker, kan du bare simulere stopp-og-omvendt strategi hvis du ønsker å back-test system med både lange og korte handler. Når lang stilling ble stengt, ble en ny kort posisjon åpnet umiddelbart. Det var fordi kjøp og salg av reserverte variabler ble brukt til begge typer bransjer. Nå (med versjon 3.59 eller høyere) finnes det separate reservert variabler for å åpne og lukke lange og korte handler: buy - quottruequot eller 1 verdi åpner lang handel selge - quottruequot eller 1 verdi lukker lang handel kort - quottruequot eller 1 verdi åpner korthandel - quottruequot eller 1 verdi lukker kort handel Som for å back-test kort handler må du tilordne korte og dekke variabler. Hvis du bruker stop-and-reverse-system (alltid på markedet), tilordner du bare å selge til kort og kjøpe for å dekke kortsalgsdekkekjøp. Dette simulerer måten pre-3.59-versjoner fungerte. Men nå gjør AmiBroker deg til å ha separate handelsregler for å gå lenge og for å gå kort som vist i dette enkle eksempelet: lange handler inngangs - og utgangsregler: kjøp kryss (cci (), 100) selger kryss (100, cci ()) kort Handler inngang og utgang regler: kort kors (-100, cci ()) cover cross (cci (), -100) Merk at i dette eksempelet hvis CCI er mellom -100 og 100 er du ute av markedet. Kontroller handelspris AmiBroker tilbyr nå 4 nye reservert variabler for å spesifisere prisen som kjøpes, selges, kort - og omslagsordrer utføres. Disse arrays har følgende navn: buyprice, salgspris, shortprice og coverprice. Hovedverdien av disse variablene er å kontrollere handelsprisen: BuyPrice IIF (dayofweek () 1, HIGH, CLOSE) på mandag, kjøp på høyt, ellers kjøp på tett, så du kan skrive følgende for å simulere ekte stoppordrer: BuyStop. Formelen for buy stop level SellStop. formelen for salgsstoppnivå hvis kjøpsordren stiger over buystopnivået (highgtbuystop) når som helst når kjøpesummen går over (ved kjøpstopp eller lavt avhengig av hvilket som er høyere) Kjøp kryss (High, BuyStop) hvis det er noen ganger under dagskursene under salgsprisnivået (selgstopp, selgstopp) KjøpPris max (BuyStop, Low) sørg for at kjøpesummen ikke mindre enn Low SellPrice min (SellStop, High) sørg for salgspris ikke høyere enn høy Vær oppmerksom på at AmiBroker forhåndsinnstiller salgspris, salgspris, shortprice og coverprice array variabler med verdiene som er definert i vinduet System Test Settings (vist nedenfor), slik at du ikke trenger å definere dem i formelen din. Hvis du ikke definerer dem, fungerer AmiBroker som i de gamle versjonene. Under tilbakest testing vil AmiBroker sjekke om verdiene du tilordnet til salgspris, salgspris, shortprice, coverprice passer inn i høyt lavt utvalg av gitt bar. Hvis ikke, vil AmiBroker justere den til høy pris (hvis prisverdien er høyere enn høy) eller til lav pris (hvis prisverdien er lavere enn lav) Resultatmål stopper Som du kan se i bildet ovenfor, er nye innstillinger for Resultatmål stopper er tilgjengelige i vinduet System Test Settings. Resultatmål stopper utføres når høyprisen for en gitt dag overstiger stoppnivået som kan gis som prosentandel eller poengøkning fra kjøpesummen. Som standard blir stoppene utført til pris du definerer som salgspris array (for lange handler) eller dekning pris array (for korte handler). Denne oppførselen kan endres ved å bruke quotExit ved stopquot-funksjonen. quotExit ved stopquot-funksjonen Hvis du markerer quotExit ved stopquot-boksen i innstillingene, stopper vil bli utført på eksakt stoppnivå, dvs. hvis du definerer resultatmål stopper på 10 ditt stopp og kjøpesummen var 50 stoppordre vil bli utført på 55 selv om Din salgsprismatrise inneholder forskjellig verdi (for eksempel sluttkurs på 56). Maksimal tap stopper arbeid på lignende måte - de utføres når lavprisen for en gitt dag faller under stoppnivået som kan gis som en prosentandel eller poengøkning fra kjøpesummen. Denne typen stopp brukes til å beskytte fortjeneste som det sporer handelen din, slik at hver gang en posisjonverdi når en ny høy, er det stoppende stoppet plassert på et høyere nivå. Når fortjenesten faller under det bakre stoppnivået, er stillingen lukket. Denne mekanismen er illustrert på bildet nedenfor (10 tilbakestillingsstopp er vist): En prøve på lav nivå implementering av Profit-mål stopp i AFL: Kjøp kryss (MACD (), Signal ()) for (i 0 I lt BarCount i) if (priceatbuy 0 Kjøp i) priceatbuy BuyPrice i if (priceatbuy gt 0 SellPrice i gt 1.1 priceatbuy) Selg jeg 1 SelgPris i 1.1 priceatbuy priceatbuy 0 annet Selg jeg 0 Dette er en ny funksjon i versjon 3.9. Posisjonsstørrelsen i backtester er implementert ved hjelp av ny reservert variabel PosisjonSize ltsize arraygt Nå kan du styre dollarbeløp eller prosentandel av porteføljen som er investert i handelspositive nummer definere (dollar) beløp som er investert i handelen for eksempel: PositionSize 1000 invest 1000 i hver handel negativt tall -100 ..- 1 definere prosentandel: -100 gir 100 av nåværende porteføljestørrelse, -33 gir 33 av tilgjengelig egenkapital for eksempel: PositionSize -50 investerer bare bare halvparten av det nåværende egenkapitaldimensjonale eksempelet: PositionSize - 100 RSI () som RSI varierer fra 0..100 dette vil resultere i posisjon avhengig av RSI-verdier - g lave verdier av RSI vil resultere i høyere prosent investert Hvis mindre enn 100 av tilgjengelige kontanter er investert, tjener det gjenværende beløpet renter som definert i innstillingene. Det finnes også en ny avkrysningsboks i AA-innstillingsvinduet: quotAllow posisjonsstørrelseskrympekvot - dette styrer hvordan backtester håndterer situasjonen når den valgte posisjonsstørrelsen (via Posisjonsstørrelse) overstiger tilgjengelig kontanter: Når dette flagget er merket, blir posisjonen angitt med størrelse skinket til tilgjengelig kontanter hvis den ikke er merket, ikke posisjonen er oppgitt. For å se aktuelle stillingsstørrelser, bruk en ny rapportmodus i AA-innstillingsvinduet: quotTrade-liste med priser og pos. sizequot Til slutt, her er et eksempel på Tharps ATR-baserte posisjonstørrelsesteknikk kodet i AFL: Kjøp ltyour buy formula heregt Selg 0 selger bare etter stopp TrailStopAmount 2 ATR (20) Capital 100000 VIKTIG: Sett den også i Innstillinger: Innledende Egenkapitalrisiko 0,01KapitalposisjonSize (RiskTrailStopAmount) BuyPrice ApplyStop (2, TrailStopAmount, 1) Teknikken kan oppsummeres som følger: Den totale egenkapitalen per symbol er 100.000, vi setter risikonivået til 1 av den totale egenkapitalen. Risikoenivået er definert som følger: Hvis et tilbakestilt stopp på en 50 aksje er på, si 45 (verdien av to ATRer mot stillingen), er 5 tapet fordelt på 1000 risikoen for å gi 200 aksjer til å kjøpe. Så er risikoen for tap 1000, men allokeringsrisikoen er 200 aksjer x 50 aksjer eller 10 000. Så tildeler vi 10 av egenkapitalen til kjøpet, men risikerer bare 1000. (Redigert utdrag fra AmiBroker mailinglisten) Rund masse størrelse og tick størrelse Ulike instrumenter handles med ulike quottrading unitsquot eller quotblocksquot. For eksempel kan du kjøpe brøkdel av enheter i fond, men du kan ikke kjøpe brøkdel av antall aksjer. Noen ganger må du kjøpe i 10s eller 100s mye. AmiBroker lar deg nå spesifisere blokkstørrelsen på global og per-symbol nivå. Du kan definere per-symbol runde størrelsesstørrelse på Symbol-gtInformation-siden (bilde 3). Verdien på null betyr at symbolet ikke har noen spesiell runde masse størrelse og vil bruke quotDefault round lot sizequot (global setting) fra siden Automatisk analyseinnstillinger (bilde 1). Hvis standardstørrelsen er satt til null betyr det at brøkdel antall aksjekontrakter er tillatt. Du kan også kontrollere runde størrelsesstørrelse direkte fra AFL-formelen din ved hjelp av RoundLotSize reservert variabel, for eksempel: Denne innstillingen styrer minimumsprisbevegelsen for gitt symbol. Du kan definere den på global og per-symbol nivå. Som med rund masseformat, kan du definere per-symbol-tikkestørrelse på Symbol-gtInformation-siden (bilde 3). Verdien på null instruerer AmiBroker til å bruke quotdefault tick sizequot definert på Innstillinger-siden (bilde 1) i Automatic Analysis-vinduet. Hvis standard tick-størrelse også er satt til null betyr det at det ikke er noen minimumsprisbevegelse. Du kan angi og hente kryssstørrelsen også fra AFL-formelen ved å bruke TickSize reservert variabel, for eksempel: Merk at innstillingen for kryssstørrelse påvirker KUN trader forlatt av innebygde stopp og ordet ApplyStop (). Backtesteren forutsetter at prisdataene følger tikkestørrelseskrav, og det endrer ikke prisrapporter levert av brukeren. Så spesifiserer tick-størrelse bare fornuftig hvis du bruker innebygde stopp, slik at utgangspunkter genereres på kvoterte prisnivåer i stedet for beregnet. For eksempel i Japan - du kan ikke ha fraksjonelle deler av yen, slik at du bør definere global ticksize til 1, så innebygd stopper avslutningshandler på heltallnivåer. Innstillingen for kontormargin definerer prosentmarginalkravet for hele kontoen. Standardverdien av Kontobutikk er 100. Dette betyr at du må gi 100 midler for å komme inn i handelen, og slik fungerer backtester i tidligere versjoner. Men nå kan du simulere en marginal konto. Når du kjøper på margin, låner du bare penger fra megleren til å kjøpe aksjer. Med gjeldende regelverk kan du sette opp 50 av kjøpesummen på aksjen du ønsker å kjøpe og låne den andre halvdelen fra megleren. For å simulere dette oppgir du bare 50 i feltet Kontantmargin (se bilde 1). Hvis din egenkapital er satt til 10000 vil din kjøpekraft være 20000, og du vil kunne legge inn større posisjoner. Vær oppmerksom på at denne innstillingen angir marginen for hele kontoen og det er IKKE relatert til futures trading i det hele tatt. Med andre ord kan du handle aksjer på marginkonto. quotReverse inngangssignal tvinger exitquot-boksen til Backtester-innstillingene. Når det er PÅ (standardinnstillingen) - backtester fungerer som i tidligere versjoner og lukker allerede åpen posisjon hvis nytt inngangssignal i omvendt retning oppstår. Hvis denne bryteren er AV - selv om omvendt signal oppstår, opprettholder backtester nåværende åpen handel og lukker ikke positon før det går til vanlig utgang (salg eller omslag) signal. Med andre ord når denne bryteren er OFF backtester ignorerer korte signaler under lange handler og ignorerer kjøpssignaler under korte handler. quotAllow samme barutgang (single bar trade) alternativ til Innstillinger Når det er PÅ (standardinnstillingene) - inngang og utgang i samme bar er tillatt (som i tidligere versjoner) hvis den er AV - Avslutt kan skje fra Bare den neste linjen (dette gjelder for vanlige signaler, det er en egen innstilling for ApplyStop-genererte utganger). Bytte den til OFF gjør det mulig å reprodusere oppførselen til MS backtester som ikke klarer å håndtere samme dagutganger. quotActivate stopper immediatelyquotThis setting løser problemet med testing systemer som inngår bransjer på markedet åpent. I versjoner før 4,09 backtester antok at du var å inngå handler på markedet nær, så innebygde stopp ble aktivert fra neste dag. Problemet var når du faktisk definerte åpen pris som handelens inngangspris - da samme prisendringer i samme dag ikke utløste stoppene. Det var noen publiserte løsninger basert på AFL-kode, men nå trenger du ikke bruke dem. Bare hvis du handler på åpen, bør du markere quotActivate stops immediatelyquot (bilde 1). Du kan spørre hvorfor ikke bare sjekke buyprice eller shortprice array hvis den er lik åpen pris. Unfortunatelly dette vil ikke fungere. Hvorfor Bare fordi det er doji dager når åpen pris er like nær og da vil backtester aldri vite om handel ble inngått på markedet åpen eller nær. Så vi trenger virkelig en egen innstilling. QUOTE QuickAFLquotQuickAFL (tm) er en funksjon som tillater raskere AFL-beregning under visse forhold. I utgangspunktet (siden 2003) var den bare tilgjengelig for indikatorer, fra versjon 5.14 er den også tilgjengelig i automatisk analyse. I utgangspunktet var ideen å tillate raskere diagramrapportering ved å beregne AFL-formel bare for den delen som er synlig på diagrammet. På samme måte kan automatisk analysevindu bruke delsett av tilgjengelige anførselstegn for å beregne AFL, hvis valgt 8220range8221 parameter er mindre enn 8220All siteringskvot. Detaljert forklaring på hvordan QuickAFL fungerer, og hvordan du kontrollerer den, finnes i denne Knowledge Base-artikkelen: amibrokerkb20080703quickafl Merk at dette alternativet ikke bare fungerer i backtesteren, men også i optimaliseringer, utforskninger og skanninger. Testtesting: Tolkning Tidligere Backtesting er en nøkkel En del av effektiv trading-systemutvikling. Det oppnås ved å rekonstruere, med historiske data, handler som ville ha skjedd tidligere, ved bruk av regler som er definert av en gitt strategi. Resultatet gir statistikk som kan brukes til å måle strategiens effektivitet. Ved hjelp av disse dataene kan handelsmenn optimalisere og forbedre sine strategier, finne tekniske eller teoretiske feil, og få tillit til strategien deres før de påføres de virkelige markedene. Den underliggende teorien er at enhver strategi som fungerte bra i det siste, vil trolig fungere godt i fremtiden, og omvendt vil enhver strategi som har gått dårlig i fortiden, sannsynligvis utføre dårlig i fremtiden. Denne artikkelen tar en titt på hvilke applikasjoner som brukes til backtest, hva slags data er oppnådd, og hvordan man bruker den Data og verktøyene Backtesting kan gi rikelig med verdifull statistisk tilbakemelding om et gitt system. Noen universelle backtesting-statistikker inkluderer: Netto fortjeneste eller tap - Netto prosentvis gevinst eller tap. Tidsramme - Tidligere datoer der testingen skjedde. Universe - Aksjer som ble inkludert i backtestet. Volatilitetsmålinger - Maks prosent prosent opp og ned. Gjennomsnitt - Prosent gjennomsnittlig gevinst og gjennomsnittlig tap, gjennomsnittlige barer holdt. Eksponering - Andel av investert kapital (eller eksponert for markedet). Nivåer - Gevinst-til-tap-forhold. Årlig avkastning - Prosentavkastning over et år. Risikojustert avkastning - Prosentavkastning som en funksjon av risiko. Typisk vil backtesting programvare ha to skjermer som er viktige. Den første tillater handelsmannen å tilpasse innstillingene for backtesting. Disse tilpasningene inkluderer alt fra tidsperiode til provisjonskostnader. Her er et eksempel på en slik skjerm i AmiBroker: Den andre skjermen er den faktiske backtesting-resultatrapporten. Her finner du all statistikk som er nevnt ovenfor. Igjen, her er et eksempel på dette skjermbildet i AmiBroker: Generelt inneholder de fleste handelsprogramvarene lignende elementer. Enkelte avanserte programvare inkluderer også tilleggsfunksjonalitet til å utføre automatisk posisjonering, optimalisering og andre mer avanserte funksjoner. De 10 budene Det er mange faktorer som handlerne tar hensyn til når de vurderer handelsstrategier. Her er en liste over de 10 viktigste tingene å huske mens backtesting: Ta hensyn til de brede markedstrendene i tidsrammen der en bestemt strategi ble testet. For eksempel, hvis en strategi bare ble testet tilbake fra 1999-2000, kan det ikke gå bra på et bjørnmarked. Det er ofte en god ide å backtest over en lang tidsramme som omfatter flere forskjellige typer markedsforhold. Ta hensyn til universet der tilbakestesting skjedde. For eksempel, hvis et bredt markedssystem er testet med et univers bestående av tech-aksjer, kan det mislykkes å gjøre det bra i ulike sektorer. Som en generell regel, hvis en strategi er rettet mot en bestemt genre av lager, begrense universet til den genren, men i alle andre tilfeller opprettholde et stort univers for testformål. Volatilitetsforanstaltninger er ekstremt viktige å vurdere i utviklingen av et handelssystem. Dette gjelder spesielt for levererte kontoer, som er utsatt for marginanrop dersom egenkapitalen faller under et bestemt punkt. Traders bør søke å holde volatiliteten lav for å redusere risikoen og muliggjøre lettere overgang inn og ut av et gitt lager. Det gjennomsnittlige antall barer som holdes er også veldig viktig å se når man utvikler et handelssystem. Selv om de fleste backtesting programvare inkluderer provisjonskostnader i de endelige beregningene, betyr det ikke at du bør overse denne statistikken. Hvis det er mulig, kan det hende at gjennomsnittlig antall barer som holdes, reduserer provisjonskostnadene, og forbedrer din generelle avkastning. Eksponering er et dobbeltkantet sverd. Økt eksponering kan føre til høyere fortjeneste eller høyere tap, mens redusert eksponering betyr lavere fortjeneste eller lavere tap. Imidlertid er det generelt en god ide å holde eksponering under 70 for å redusere risiko og muliggjøre lettere overgang inn og ut av et gitt lager. Den gjennomsnittlige gevinstløpsstatistikken, kombinert med vinner-til-tap-forholdet, kan være nyttig for å bestemme optimal plassering og pengestyring ved hjelp av teknikker som Kelly-kriteriet. (Se Money Management ved hjelp av Kelly-kriteriet.) Traders kan ta større stillinger og redusere provisjonskostnader ved å øke sine gjennomsnittlige gevinster og øke deres vinner-til-tap-forhold. Årlig avkastning er viktig fordi den brukes som et verktøy for å benchmark en systemavkastning mot andre investeringssteder. Det er viktig ikke bare å se på den samlede årlige avkastningen, men også å ta hensyn til økt eller redusert risiko. Dette kan gjøres ved å se på den risikojusterte avkastningen, som står for ulike risikofaktorer. Før et handelssystem er vedtatt, må det overgå alle andre investeringssteder med like eller mindre risiko. Backtesting tilpasning er ekstremt viktig. Mange backtesting-applikasjoner har innspill for provisjonsbeløp, runde (eller brøkdelte) masse størrelser, tikkestørrelser, marginkrav, renter, slippage-forutsetninger, stillingsreguleringsregler, same-bar-utgangsreguleringer, (bak) stoppinnstillinger og mye mer. For å få de mest nøyaktige backtesting resultatene, er jeg viktig å justere disse innstillingene for å etterligne megleren som vil bli brukt når systemet går live. Backtesting kan noen ganger føre til noe kjent som overoptimalisering. Dette er en tilstand hvor resultatene avstemmes så høyt til fortiden at de ikke lenger er like nøyaktige i fremtiden. Det er generelt en god ide å implementere regler som gjelder for alle aksjer, eller et utvalg av målrettede aksjer, og er ikke optimalisert i den grad reglene ikke lenger er forståelige av skaperen. Backtesting er ikke alltid den mest nøyaktige måten å måle effektiviteten til et gitt handelssystem. Noen ganger har strategier som har gått bra i det siste, ikke lykkes i det nåværende. Tidligere resultater er ikke en indikasjon på fremtidige resultater. Pass på å papirhandel et system som har blitt suksessfullt testet før du går, for å være sikker på at strategien fortsatt gjelder i praksis. Konklusjon Backtesting er et av de viktigste aspektene ved å utvikle et handelssystem. Hvis det opprettes og tolkes ordentlig, kan det hjelpe handelsmenn å optimalisere og forbedre strategiene, finne tekniske eller teoretiske feil, samt få tillit til strategien deres før de påføres det til de virkelige verdensmarkeder. Ressurser Tradecision (tradecision) - High-end Trading System Development AmiBroker (amibroker) - Budsjett Trading System Development. En økonomisk teori om total utgifter i økonomien og dens effekter på produksjon og inflasjon. Keynesian økonomi ble utviklet. En beholdning av en eiendel i en portefølje. En porteføljeinvestering er laget med forventning om å tjene en avkastning på den. Dette. Et forhold utviklet av Jack Treynor som måler avkastning opptjent over det som kunne vært opptjent på en risikofri. Tilbakekjøp av utestående aksjer (tilbakekjøp) av et selskap for å redusere antall aksjer på markedet. Selskaper. En skattemessig tilbakebetaling er refusjon på skatter betales til en person eller husstand når den faktiske skatteforpliktelsen er mindre enn beløpet. Den monetære verdien av alle ferdige varer og tjenester som er produsert innen et land grenser i en bestemt tidsperiode. Bakprovning Backtesting er prosessen med å bruke en handelsstrategi eller analysemetode til historiske data for å se hvor nøyaktig strategien eller metoden ville ha spådd faktiske resultater . Slik fungerer det (Eksempel): For eksempel, antar du å utarbeide en modell som du tror konsekvent forutser fremtidens verdi av SampP 500. Ved å bruke historiske data kan du teste modellen for å se om den ville ha fungert tidligere. Ved å sammenligne de forventede resultatene av modellen mot de faktiske historiske resultatene, kan backtesting avgjøre om modellen har prediktiv verdi. Nesten hvilken som helst metode for å forutse noe, kan backtestes. For eksempel kan en analytiker backtest hans eller hennes metoder for å forutsi en selskaps nettoinntekt. graden av volatilitet i en bestemt bestanddel. nøkkelforhold. eller returprocenter. Tekniske forhandlere er de vanligste brukerne av backtesting, og de fleste backtesting i dag er ferdig med dataprogramvare. Hvorfor det betyr: Backtesting tilbyr analytikere. handelsmenn og investorer en måte å evaluere og optimalisere sine handelsstrategier og analytiske modeller før implementering av dem. Tanken er at en strategi som ville ha fungert dårlig i fortiden, vil sannsynligvis fungere dårlig i fremtiden, og omvendt. Men som du kan se er en viktig del av backtesting den risikable antakelsen om at tidligere resultater forutser fremtidig ytelse. InvestingAnswers er den eneste økonomiske referanseguideen du noensinne trenger. Våre dybdeverktøy gir millioner av mennesker over hele verden svært detaljert og grundig forklart svar på deres viktigste økonomiske spørsmål. Vi tilbyr den mest omfattende og høyeste økonomiske ordboken på planeten, pluss tusenvis av artikler, praktiske kalkulatorer og svar på vanlige økonomiske spørsmål - alle 100 gratis. Hver måned vender mer enn 1 million besøkende i 223 land over hele verden til InvestingAnswers som en pålitelig kilde til verdifull informasjon. Suksessfull tilbakekjenning av algoritmiske handelsstrategier - Del I Denne artikkelen fortsetter serien om kvantitativ handel, som startet med Beginners Guide og Strategi Identifikasjon. 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. Hva er hovedårsakene 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 feil implementert. 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 ekstremt forsiktig for å 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 backtests 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 i forhold til 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 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 nærmere på noen spesielle 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 handel