O metoda statistica pentru autoreglarea sistemelor de trading

[English version] [MQLmagazine.com in english] [Editia romaneasca]

Incep sa scriu acest articol in ideea ca ar putea deveni folositor intr-un interval de timp nu prea indepartat. M-am gandit la asta de ceva vreme. Ideea de autoreglare a aparut de ceva vreme, dar complexitatea extrema a sistemelor de retail trading au facut-o imposibil de aplicat. Totusi, sistemele HFT sunt in general simple, si reguli similare sunt aplicate pe sute de titluri, intr-o maniera parametrizata. De aceea, daca regulile ar fi simple si ar putea fi scrise gen “cand apare asta, faci asta, rezultand asta”, in loc de logica de labirint a sistemelor de retail, atunci un set de statistici optime pe datele de intrare (intinzandu-se pe un tablou de cotatii, date de orderbook s.a.m.d.) este premisa pentru operatii gen cotare, primire de executii, take profit sau stop loss in doar cativa ticksi. Asa cum s-a vazut in articolul despre Progress Apama, acesti algoritmi sunt foarte instabili, fiind o continua cautare pentru algoritmi mai noi.

Acum poti intreba, de ce am incerca autoreglarea sistemelor de trading din moment ce institutionalii nu o fac (cel putin la nivelul HFT). Chestia e ca algoritmii lor sunt atat de rapizi incat pot sa nici nu aiba timp suficient de a inregistra datele in baza de date, incat autoreglarea, care necesita analiza suplimentara, ar fi o completa pierdere de timp, aducand prea putine imbunatatriri algoritmilor comparata cu latenta suplimentara care se formeaza. Ce va veni in aceste articole are de aceea o natura experimentala si nu trebuie luata ca solutie, ci ca incercare – nu pot spune sigur daca exista vreun sens in a incerca sa gasesti, cu statistici obisnuite, parametri recurenti ai unui proces stochastic.

Asa ca, sa presupunem ca un tablou de parametri (cum ar fi volatilitati individuale, medii mobile, volume de executii) va fi inregistrat intr-o baza de date sau un tablou. Trebuie sa luam in considerare si faptul ca un semnal de trading poate exista permanent, la fiecare tick. Presupunand volumul a fi constant, acelasi semnal poate fi in doua directii : cumparare sau vanzare. Fiecare semnal poate avea doua rezultate, unul pentru cumparare, unul pentru vanzare. Putem crea totusi reguli separate pentru vanzare.

De exemplu, un semnal cuprinse de volatilitate si distanta dintre cotatia mediana si media mobila a cotatiei mediene este de : 0.03 stddev si 2 ticksi. Ca sa-l rasucim putin , introducem cotarea, si notam 0 pentru situatia fara executii. Pusa intr-un buy cu 3 ticksi take profit si 2 ticksi stop loss, la un anumit moment, face 2 ticksi profit, pusa intr-un sell, nu are executii. Deci bazei de date cu cumparari va fi adaugata inregistrarea (0.03 ; 2 ; 2), iar celei cu vanzari (0.03 ; 2 ; 0).

Si acum lucrurile devin interesante. La sfarsit, dupa ce datele sunt stranse pentru o masa de semnale care constituie “numarul mare” pentru statistici, ne uitam prin baza de date. Mai intai, la o prima privire vom grupa baza de date dupa actiune si rezultat. In acest caz, avem sase stari finale:

1. BUY: coteaza, executie, take profit (BQFT)
2. BUY: coteaza, executie, stop loss (BQFS)
3. BUY: coteaza, fara executie, anulare ordin (BQC)
4. SELL: coteaza, executie, take profit (SQFT)
5. SELL: coteaza, executie, stop loss (SQFS)
6. SELL: coteaza, fara executie, anulare ordin (SQC)

Avem deci sase cazuri. Analizand BUY cu cotatie, executie si take profit, este doar una din cele sase stari si va consta intr-o parte mare a datelor, la fel ca si celelalte stari. Scopul analizei statistice e de a avea o statistica pregatita pentru fiecare caz. De exemplu, cazul nostru ar trebui sa arate, la sfarsit, cam asa:

0.03, 2 : 45% BQFT, 35% BQSL, 20% BQC ; 30% SQFT, 30% SQSL, 40% SQC

Dupa ce masa initiala de semnale impreuna cu rezultatele este colectata, statisticile trebuie sa fie lansate pentru fiecare combinatie de parametri. Avand numere reale ca parametri, cu multe zecimale, va conduce la faptul de a avea un numar mare de cazuri, egal cu numarul de semnale de input, facand statistica imposibila. Asa ca e nevoie de agregarea datelor. De exemplu, pentru fiecare set de parametri, pot fi calculate quartilele si apoi numarul de grupuri cu formula Freedman-Diaconis (e doar un exemplu, alte metode pot fi aplicate). Aceasta va conduce la un numar diferit de grupuri pentru fiecare dintre parametri. Apoi un nou tabel va fi creat, iar fiecare caz va avea o eticheta cu numarul de grupuri. De exemplu stddev 0.03 poate fi denumita ca “Grupul 1″ pe scara stddev si cei 2 ticksi distanta pot fi “Grupul 2″ pe scala distantelor in ticksi. Numarul total de cazuri poate fi mai mic sau egal decat produsul grupurilor per fiecare criteriu. Daca ai 3 criterii de 10 grupuri fiecare, pot fi si mai mult de 1000 de cazuri. Mai mult ca sigur, cazurile din miez vor avea un numar mare de situatii inregistrate, iar celelalte de-abia vor avea cate una. Totusi, cu cat mai platykurtica este repartitia situatiilor per cazuri, cu atat mai mare nevoia pentru un “numar mai mare” de situatii. Dupa aplicarea statisticilor, statistica bazei de date va arata cam asa:

Grupul 1, Grupul 2 : 45% BQFT, 35% BQSL, 20% BQC ; 30% SQFT, 30% SQSL, 40% SQC

Ce e important e ca trebuie sa fie extrase statistici relevante. Daca asa stau lucrurile, care ar fi decizia de trading? Mergi pe o cumparare cu o sansa de profit in 45% din cazuri? Numai ca sa suporti 35% stop losses… Pentru ca pe latura de vanzari e mult mai rau, cu situatii de stop loss aproape egale cu cele de profit. In acest caz, decizia este una de cumparare, dar totusi cu rezerve. Daca profiturile nu sunt destul de relevante, nicio decizie nu trebuie sa se ia. Totusi, este necesar ca algoritmul sa aiba un modul de decizii care sa aleaga numai cazurile relevante pentru trading.. Dar cat de rapida trebuie sa fie masina, intrucat dupa ce datele initiale sunt stranse, cu fiecare nou semnal (care poate fi si un tick, intr-un algoritm gen HFT) va fi lansata o masiva recalculare a marimilor grupurilor pe intreaga baza de date, pentru a aduce statistica la zi, si in acelasi timp de a veni cu decizia de trading si executia in timp real ?

Amintiti-va articolul meu despre motorul CEP. CEP este vazut acolo ca un modul de recunoastere – lansare, dar daca CEP poate fi utilizat ca dispozitiv de inregistrare ? Daca CEP poate fi legat de motorul statistic? Cata latenta va adauga calculului? Mai putem vorbi de timp real?

Editii