Start strategien på nytt midt i backtesten. Husker den hva den eier?

En nyttig backtesttest handler ikke om å finne en bedre parameter: stopp prosessen halvveis, gjenopprett den og fullfør den samme avspillingen. Med identiske inndata og en kontrollert utførelsessimulator bør beslutningene, ordrene og egenkapitalen samsvare med en kjøring uten avbrudd.

Hvis de ikke gjør det, har du funnet et problem med tilstandshåndteringen. Strategien er avhengig av noe du ikke lagret, eller ikke kunne rekonstruere. Denne avhengigheten betyr noe når research-kjøringer gjenopptas, arbeidere byttes ut eller en papirsimuleringstjeneste rulles ut med ny kode.

Jeg liker denne testen fordi forventet svar er uvanlig tydelig. Det er ingen diskusjon om hvorvidt markedet endret seg. Begge kjøringene får det samme markedet.

Her er tre feil måter å starte på nytt på. Tallene er illustrative; hver feil kan oppstå i et ellers deterministisk system.

1. Last inn noen få stolper og kall indikatorene oppvarmet

Anta at en strategi bruker et eksponentielt glidende gjennomsnitt over 100 perioder. Oppdateringen er:

alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previous

Prosessen som kjører uten avbrudd, viderefører den opparbeidede EMA-en. Den omstartede prosessen henter 100 stolper, initialiserer EMA-en med den første sluttkursen og antar at en indikator over 100 perioder trenger 100 observasjoner.

Denne antakelsen blander indikatorens utjevningsparameter sammen med et endelig minnevindu. En EMA beholder et avtakende bidrag fra starttilstanden. Hvis to versjoner begynner med en EMA-forskjell på 10 prisenheter, krymper identiske etterfølgende priser denne forskjellen slik:

Beregningen er 10 * (99 / 101)^k. Hvis du henter 100 stolper, får du bare 99 oppdateringer dersom den første observasjonen brukes som startverdi.

Problemet viser seg som regel nær en beslutningsgrense. Den ene kjøringen ser at prisen ligger over EMA-en; den andre ser at den ligger under. En liten numerisk forskjell gir en ekstra handel. Når det først skjer, kan også nedkjølingsperioder, tilgjengelige kontanter og senere beslutninger avvike.

Lagre indikatorens rekursive tilstand, initialiseringsstatusen og den sist behandlede hendelsen. Alternativt kan du spille av på nytt fra en kjent starttilstand. En lengre oppvarming kan gi en akseptabel tilnærming, men velg lengden ut fra en eksplisitt feilmargin, og undersøk om denne marginen kan endre beslutningene. «Fem ganger perioden» er en tommelfingerregel, ikke et bevis.

Og indikatorer er ikke hele historikken. En rullerende persentil trenger vinduet sitt. En nettbasert modell kan trenge optimalisatortilstanden sin. En regel som venter 3 stolper etter et tap, må huske tapet og telleren.

2. Lagre posisjonene og glem ordrene som fortsatt er under behandling

Målposisjonen din er 10 enheter. En kjøpsordre på 10 er fylt med 4, så 6 gjenstår. Du lagrer et kontrollpunkt med posisjonen 4, starter på nytt og legger inn en ny kjøpsordre på de manglende 6.

Hvis både den opprinnelige resten og erstatningsordren blir fylt, eier du 16.

Backtestvarianten av denne feilen forblir ofte skjult fordi omstart av fyllemotoren i det stille sletter aktive ordre. I papirsimulering kan simulatoren eller en ekstern tjeneste beholde dem. Den samme gjenopprettingskoden gir dermed ulik eksponering, avhengig av hvilken komponent som overlevde.

Problemet viser seg som en uforklarlig ordrestrøm rett etter gjenoppretting. Noen ganger dobles eksponeringen. Andre ganger stenger strategien en posisjon mens den beskyttende ordren fortsatt er aktiv, slik at den senere kan åpne en ny posisjon.

Et kontrollpunkt må inneholde ordreidentitet og livssyklustilstand sammen med posisjonene. Før gjenopprettingen lager nye handlinger, må den avstemme disse oppføringene mot utførelsessystemet. En ordre med ukjent utfall må undersøkes; å behandle «ingen kvittering lagret» som «aldri sendt» er slik duplikatordrer oppstår.

Stabile klientordre-ID-er gjør det lettere å finne ut hva som skjedde. De hindrer bare duplikater når mottakersystemet faktisk håndhever de nødvendige reglene for unikhet eller idempotens. Lagre også behandlede utførelses-ID-er, slik at en avspilt fylling ikke øker posisjonen to ganger.

Jeg har sansen for den kjedelige skjermen med ordrestatus. På omstartsdag blir de små radene plutselig det mest interessante grensesnittet i hele bygget.

3. Gjenopprett posisjonen og start en ny P&L-bokføring

Tenk på et ubelånt spot-eksempel uten gebyrer. Start med $10,000 i kontanter, kjøp 10 enheter til $100, og lagre et kontrollpunkt når markedsverdien når $110.

Riktig tilstand er $9,000 i kontanter pluss en posisjon verdt $1,100: egenkapital på $10,100. Hvis gjenopprettingen henter tilbake de 10 enhetene, men nullstiller kontantene til de opprinnelige $10,000, rapporterer den $11,100. Du har tryllet fram $1,000 ved å starte en prosess på nytt.

Andre varianter er mindre dramatiske. Gjenopprettingen bevarer egenkapitalen, men nullstiller inngangsprisen til $110. Samlet egenkapital kan fortsatt være riktig, mens fordelingen mellom realisert og urealisert resultat endres. Hvis en stop eller exit-betingelse viser til inngangsprisen, endrer snarveien i regnskapsføringen nå handelsatferden.

Eller systemet glemmer den tidligere egenkapitaltoppen. Anta at egenkapitalen nådde $10,600 før den falt til $10,100. Nedgangen fra toppen er omtrent 4.72%. Nullstill toppverdien ved gjenoppretting, og strategien tror plutselig at nedgangen er null. Enhver risikokontroll som bygger på nedgang fra toppen, er nettopp blitt nullstilt uten tillatelse.

Problemet kan altså være et sprang i egenkapitalen, en mistenkelig forbedring i nedgangen fra toppen eller en risikoregel som slutter å slå inn etter utrullinger. Bevar bokføringen og strategitilstanden som avhenger av regnskapet: kontantbevegelser, posisjoner, relevant kostpris, påløpte kostnader og risikokontrollens minne. Avstem gjenopprettet egenkapital mot bokføringen på samme verdsettelsestidspunkt.

Testen jeg ville beholdt i research-miljøet, kjører først en referanseavspilling uten avbrudd og starter deretter en ny kjøring på nytt ved bevisst vanskelige tidspunkter: under initialisering av indikatorer, etter en delvis fylling og mens en risikogrense er aktiv. Bruk samme hendelsesrekkefølge og bevar eventuell tilfeldig tilstand i simulatoren. Sammenlign den første beslutningen etter gjenoppretting, ordre- og fyllingsoppføringene og egenkapitalkurven. En lik sluttsaldo alene kan skjule feil som utligner hverandre.

Hvis et krasj skjer etter innsending, men før kvitteringen kommer, må testmiljøet også bevare utførelsestjenestens tilstand uavhengig av strategiprosessen. Ellers sletter det usikkerheten du prøver å teste.

En strategis spesifikasjon omfatter hva den husker. Gjør dette minnet tydelig nok til at du kan stoppe prosessen midt i en avspilling og vise nøyaktig hvordan den kommer i gang igjen.