Ponovno smo zagnali shranjeni preizkus za nazaj in dobili drugačno kapitalsko krivuljo. Ista koda strategije, isto časovno obdobje, isti simbol. Končno stanje računa se je razlikovalo za 1.8 %, tri posle pa so se premaknili za eno svečko.
To je dovolj, da je raziskovalnemu rezultatu težko zaupati. Če sodelavec, vaša prihodnja različica ali storitev za simulirano trgovanje ne more ponoviti zagona, ne morete vedeti, ali je sprememba izboljšala strategijo ali zgolj spremenila poskus. Takole smo iskali vzrok odstopanja.
1. dan: Zapisali smo, kaj pomeni »isti zagon«
Naša prva napaka je bila, da smo datoteko strategije obravnavali kot celoten poskus. Pa ni bila. Zagon je bil odvisen tudi od vhodnih podatkov, različice pogona, koledarja, metapodatkov instrumenta in nastavitev izvajanja. Koda je opisovala le en del izračuna.
Preden smo karkoli spremenili, smo pripravili manifest zagona. Zabeležili smo commit strategije, identifikatorje posnetkov podatkov, časovno obdobje, trgovalno platformo, razpored provizij, vir financiranja, model izvršitve in različice programske opreme. Shranili smo tudi naročila in izvršitve, saj sama kapitalska krivulja ne pokaže, kje sta se zagona prvič razšla.
| Artefakt | Kaj zabeležiti | Zakaj je pomembno |
|---|---|---|
| Tržni podatki | ID posnetka, različica sheme, prilagoditve | Ponudniki popravljajo zgodovino in revidirajo korporacijske dogodke |
| Izvajanje | Provizijski razred, časovna vrsta financiranja, nastavitve izvršitve in vpliva | Privzete vrednosti in predpostavke o računu spreminjajo rezultate |
| Okolje izvajanja | Commit kode, različice pogona in odvisnosti | Knjižnice lahko spremenijo vrstni red, zaokroževanje ali kazalnike |
| Izhod | Naročila, izvršitve, pozicije in metrike | Pokaže, kje se zagona začneta razhajati |
2. dan: Primerjali smo posle, ne Sharpa
Povzetne metrike so nas zavajale. Oba zagona sta imela skoraj enak Sharpe, vendar so dnevniki izvršitev razkrili prvo neskladje pri poravnavi financiranja. En zagon je obrestno mero obračunal za pozicijo, odprto ob časovnem žigu poravnave; drugi pa za pozicijo po ponovnem uravnoteženju ob tem časovnem žigu.
Koda strategije se ni spremenila. Spremenil se je vrstni red dogodkov v pogonu. Manjša posodobitev različice je zaporedje določila izrecno, medtem ko je bilo prej odvisno od tega, kako sta se dogodka po naključju razvrstila.
Pogoje zagona smo popravili tako, da zdaj določajo vrstni red: financiranje najprej obračunamo za pozicijo, preneseno v poravnavo, nato pa obdelamo odločitve strategije za ta časovni žig. Natančna konvencija se lahko razlikuje glede na trgovalno platformo in pogon. Napaka je v tem, da vrstni red ostane nedoločen.
3. dan: Izkazalo se je, da »ista« podatkovna datoteka ni bila enaka
Ko smo določili vrstni red dogodkov, je večina preostalih neskladij ostala pri nekaj delniških poslih. Ponudnik je popravil zgodovinsko prilagoditev zaradi delitve delnic. Naša datoteka je imela isto ime in enako število vrstic kot prej, zato je delovala nespremenjena.
Zdaj ustvarimo prstni odtis vsakega nespremenljivega posnetka podatkov in skupaj z njim hranimo tudi pravilnik prilagoditev. Zgoščena vrednost pove, ali so se bajti spremenili, ne pojasni pa zakaj. Zato manifest vsebuje tudi vir, čas pridobitve in različico pretvorbe. Pri podatkih, ki se revidirajo, so te podrobnosti del rezultata.
Ponovljiv preizkus za nazaj mora odgovoriti na vprašanje: »Katero različico preteklosti je videl?«
4. dan: Našli smo eno neopazno privzeto nastavitev
Zadnja razlika je bila provizija maker, nastavljena na nič, ker je konfiguracija strategije izpuščala to polje. Novejši pogon je uporabil privzeto provizijo računa. Ta ena sama privzeta nastavitev je dovolj spremenila mejne posle, da je pojasnila večino razlike v končnem stanju računa.
Gospodarsko pomembne nastavitve smo določili izrecno, pogon pa zdaj v zapis zagona izpiše razrešeno konfiguracijo. Privzete vrednosti so priročne pri raziskovanju. So pa slab dokaz pri primerjavi rezultatov skozi čas.
Česa naslednjič ne bi počeli
Pol dneva smo primerjali skupne metrike, preden smo pogledali prvo različno izvršitev. Ne začnite tam. Dnevnika dogodkov razvrstite po časovnem žigu in poiščite prvo odstopanje; poznejše razlike so pogosto posledica istega vzroka.
Opustili bi tudi zamisel, da sama slika vsebnika zagotavlja ponovljiv zagon. Zaklene velik del programskega okolja, ne pa zunanje podatkovne datoteke, razporeda provizij, pridobljenega med izvajanjem, ali revidirane zgodovine pri ponudniku.
Ko se preizkus za nazaj spremeni, ohranite oba manifesta zagona in dnevnika, nato pa odpravljajte po en vir odstopanja naenkrat. Uporaben rezultat ni zgolj krivulja, ki jo lahko znova ustvarite. Je zapis, ki pojasni, kateri podatki in predpostavke so ga ustvarili ter zakaj se lahko naslednji zagon razlikuje.
← Vse objave
