Restartējiet stratēģiju atpakaļtesta vidū. Vai tā atceras, kas tai pieder?

Noderīgai atpakaļtesta pārbaudei nav vajadzīgi labāki parametri: apturiet procesu pusceļā, atjaunojiet to un pabeidziet to pašu atkārtojumu. Ja ievades dati ir identiski un izpildes simulators ir kontrolēts, lēmumiem, orderiem un pašu kapitālam jāsakrīt ar nepārtrauktu izpildi.

Ja tā nenotiek, esat atraduši stāvokļa pārvaldības problēmu. Stratēģija ir atkarīga no kaut kā, ko neesat saglabājuši vai nevarat rekonstruēt. Šī atkarība ir svarīga ikreiz, kad tiek atsākti izpētes palaidieni, nomainīti darba procesi vai papīra tirdzniecības servisā tiek izvietots jauns kods.

Man šī pārbaude patīk, jo gaidāmā atbilde ir neparasti skaidra. Nav strīda par to, vai tirgus ir mainījies. Abi palaidieni saņem vienu un to pašu tirgu.

Lūk, trīs nepareizi veidi, kā restartēt. Skaitļi ir ilustratīvi; katra kļūme var rasties arī citādi deterministiskā sistēmā.

1. Ielādējiet dažus stabiņus un uzskatiet indikatorus par iesildītiem

Pieņemsim, ka stratēģija izmanto 100 periodu eksponenciālo mainīgo vidējo. Tā atjaunināšana notiek šādi:

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

Nepārtrauktais process saglabā uzkrāto EMA vērtību. Pēc restartēšanas process ielādē 100 stabiņus, iestata EMA sākuma vērtību uz pirmo slēgšanas cenu un pieņem, ka 100 periodu indikatoram vajadzīgi 100 novērojumi.

Šis pieņēmums jauc indikatora izlīdzināšanas parametru ar galīga garuma atmiņas logu. EMA saglabā sarūkošu sākotnējā stāvokļa ietekmi. Ja divu versiju EMA vērtības sākumā atšķiras par 10 cenu vienībām, vienādas turpmākās cenas šo atšķirību samazina šādi:

Aprēķins ir 10 * (99 / 101)^k. Ielādējot 100 stabiņus, tiek iegūti tikai 99 atjauninājumi, ja pirmo novērojumu izmanto kā sākuma vērtību.

Problēma parasti parādās lēmuma robežas tuvumā. Vienā palaidienā cena ir virs EMA, otrā — zem tās. Neliela skaitliska atšķirība rada veselu papildu darījumu. Pēc tam var atšķirties arī atdzišanas periodi, pieejamā nauda un turpmākie lēmumi.

Saglabājiet rekursīvā indikatora stāvokli, tā inicializācijas statusu un pēdējo apstrādāto notikumu. Varat arī atkārtot izpildi, sākot no zināma stāvokļa. Ilgāks iesildīšanas periods var dot pieņemamu tuvinājumu, taču izvēlieties tā garumu, balstoties uz skaidri noteiktu kļūdas pielaidi, un pārbaudiet, vai šī pielaide var mainīt lēmumus. “Piecas reizes lielāks par periodu” ir pieņēmums, nevis pierādījums.

Un indikatori neaptver visu vēsturi. Slīdošajam procentiles rādītājam vajadzīgs tā logs. Tiešsaistes modelim var būt vajadzīgs optimizētāja stāvoklis. Noteikumam, kas pēc zaudējuma nogaida 3 stabiņus, jāatceras gan zaudējums, gan skaitītājs.

2. Saglabājiet pozīcijas, bet aizmirstiet neizpildītos orderus

Jūsu mērķa pozīcija ir 10 vienības. Pirkšanas orders par 10 vienībām ir izpildīts par 4, un 6 vēl nav izpildītas. Kontrolpunktā saglabājat pozīciju kā 4, restartējat procesu un iesniedzat jaunu pirkšanas orderi trūkstošajām 6 vienībām.

Ja izpilda gan sākotnējā ordera atlikumu, gan aizstājošo orderi, jums pieder 16 vienības.

Atpakaļtestēšanā šī kļūda bieži paliek nepamanīta, jo, restartējot izpildes dzinēju, aktīvie orderi tiek klusi dzēsti. Papīra tirdzniecībā simulators vai ārējais serviss tos var saglabāt. Tad viens un tas pats atkopšanas kods rada atšķirīgu riska ekspozīciju atkarībā no tā, kurš komponents ir izdzīvojis.

Problēma izpaužas kā neizskaidrojams orderu pieplūdums uzreiz pēc atkopšanas. Dažkārt tas divkāršo riska ekspozīciju. Citkārt tas aizver pozīciju, kurai aizsardzības orders vēl ir aktīvs, un šis orders vēlāk var atvērt jaunu pozīciju.

Kontrolpunktā līdzās pozīcijām jāsaglabā orderu identitāte un dzīves cikla stāvoklis. Pirms jaunu darbību ģenerēšanas atkopšanas procesam šie ieraksti jāsaskaņo ar izpildes sistēmu. Nezināma ordera iznākums ir jāizmeklē; ja pieņemat, ka “saglabātas atbildes nav” nozīmē “orders nav iesniegts”, rodas dublēti orderi.

Stabili klienta ordera identifikatori palīdz noskaidrot, kas noticis. Tie novērš dublikātus tikai tad, ja saņēmēja sistēma patiešām ievēro vajadzīgos unikalitātes vai idempotences noteikumus. Saglabājiet arī apstrādāto izpildījumu identifikatorus, lai atkārtoti atskaņots izpildījums divreiz nepalielinātu pozīciju.

Man ļoti patīk garlaicīgais orderu statusa ekrāns. Restartēšanas dienā tā mazās rindas pēkšņi kļūst par interesantāko saskarni visā birojā.

3. Atjaunojiet pozīciju un sāciet jaunu P&L virsgrāmatu

Aplūkosim piemēru ar spot tirdzniecību bez kredītpleca un komisijām. Sāciet ar $10,000 skaidrā naudā, nopērciet 10 vienības par $100 un izveidojiet kontrolpunktu, kad marķējuma cena sasniedz $110.

Pareizais stāvoklis ir $9,000 skaidrā naudā un pozīcija $1,100 vērtībā: pašu kapitāls ir $10,100. Ja atkopšanas procesā tiek atjaunotas 10 vienības, bet skaidrā nauda tiek atiestatīta uz sākotnējiem $10,000, sistēma uzrāda $11,100. Restartējot procesu, esat radījuši $1,000 no nekā.

Citi gadījumi ir mazāk uzkrītoši. Atkopšana saglabā pašu kapitāla kopsummu, bet atiestata ieejas cenu uz $110. Kopējais pašu kapitāls var palikt pareizs, lai gan mainās sadalījums starp realizēto un nerealizēto peļņu un zaudējumiem. Ja stop vai izejas nosacījums izmanto ieejas cenu, šis uzskaites īsceļš tagad maina tirdzniecības uzvedību.

Vai arī sistēma aizmirst iepriekšējo pašu kapitāla maksimumu. Pieņemsim, ka pašu kapitāls sasniedza maksimumu pie $10,600 un pēc tam nokritās līdz $10,100. Tā kritums no maksimuma ir aptuveni 4.72%. Atiestatiet maksimuma atzīmi atkopšanas laikā, un stratēģija pēkšņi uzskatīs, ka krituma nav. Jebkura uz kritumu balstīta riska kontrole tikko ir atiestatīta bez atļaujas.

Tātad problēma var būt lēciens pašu kapitāla līknē, aizdomīgi uzlabots krituma rādītājs vai riska noteikums, kas pēc izvietošanas vairs neiedarbojas. Saglabājiet virsgrāmatu un no uzskaites atkarīgo stratēģijas stāvokli: naudas plūsmas, pozīcijas, piemērojamo iegādes vērtību, uzkrātās izmaksas un riska kontroles atmiņu. Saskaņojiet atjaunoto pašu kapitālu ar virsgrāmatu, izmantojot vienu un to pašu novērtēšanas laika atzīmi.

Pētniecības testēšanas vidē es paturētu šādu pārbaudi: palaist vienu nepārtrauktu atsauces atkārtojumu un pēc tam restartēt otru palaidienu apzināti neērtos brīžos — indikatoru inicializācijas laikā, pēc daļējas izpildes un brīdī, kad ir aktīvs riska limits. Izmantojiet to pašu notikumu secību un saglabājiet simulatora nejaušības stāvokli, ja tāds ir. Salīdziniet pirmo lēmumu pēc atkopšanas, orderu un izpildījumu ierakstus, kā arī pašu kapitāla līkni. Vienāda gala bilance var slēpt kļūdas, kas cita citu kompensē.

Ja avārija notiek pēc ordera iesniegšanas, bet pirms apstiprinājuma saņemšanas, testēšanas videi neatkarīgi no stratēģijas procesa jāsaglabā arī izpildes servisa stāvoklis. Pretējā gadījumā tā dzēš tieši to nenoteiktību, ko mēģināt pārbaudīt.

Stratēģijas specifikācijā ietilpst arī tas, ko tā atceras. Padariet šo atmiņu pietiekami skaidru, lai varētu apturēt procesu atkārtojuma pusceļā un parādīt, kā tas atsāk darbu.