Prace
nad modelem matematycznym systemu transakcyjnego o trzech poziomach hierarchii doszły do punktu, kiedy można sformułować
zagadnienie optymalizacji parametru na trzecim, najwyższym poziomie
hierarchii. Przypomnę, że parametrem tym jest liczba elementów w
sekwencjach wykorzystywanych do optymalizacji na poziomie drugim,
czyli doboru progu odwrócenia pozycji względem kursu na początku
interwału czasowego. Można powiedzieć, że wyższy poziom w
hierarchii oznacza też wyższy poziom abstrakcji. A zatem pora
uporać się z niełatwym zadaniem zapisania tego w formalnej i
precyzyjnej postaci.
Dysponujemy
już aparatem pojęciowym i symbolicznym pozwalającym na opis –
dla każdego interwału czasowego – zbioru wyników optymalizacji
parametru p dla wszystkich wartości parametru m,
przebiegających z góry określony zakres od 1 do M. Wyniki
te są umieszczone w pionowym wektorze będącym efektem działania
operatora U. Kolejne takie wektory pionowe utworzą macierz
prostokątną. Staje się teraz jasne że wiersze tej macierzy to
sekwencje pozycji (początkowych i końcowych) oraz odpowiadających
im zysków, które będą stanowić zbiór wejściowy dla
optymalizacji parametru m.
Powstaje
tutaj jednak fundamentalne pytanie o wymiary tej macierzy. Liczba
wierszy wynosi oczywiście M, jednak kluczową kwestią jest
określenie liczby kolumn. Determinuje ona w istocie długość
sekwencji dla optymalizacji m.
Długie
i dogłębne przemyślenia doprowadziły mnie do decyzji o
wprowadzeniu nowego parametru do modelu. Mając całą świadomość
konsekwencji, jakie to może mieć dla zdolności uogólniania opracowywanej strategii. Trzeba pamiętać
jednak, że zwykle eliminowanie jednego parametru na drodze
optymalizacji pociąga za sobą konieczność wprowadzania innego, a
czasami nawet kilku, w celu określenia funkcji kryterium tej
optymalizacji i sterowania jej przebiegiem.
Po
tym wprowadzeniu nietrudno już się domyślić, jaką interpretację
będzie mieć proponowany przeze mnie parametr, który wstępnie
oznaczyłem literą Q. Na zasadzie analogii do przejścia z
pierwszego poziomu na drugi, w tym przypadku również będzie on
oznaczał liczbę elementów w sekwencji rekordów, dla których
będziemy przeglądać funkcję kryterium.
Wcześniej
jeszcze proponuję przyjrzeć się następującemu symbolicznemu
zapisowi operacji przejścia od sekwencji rekordów OHLC do
wspomnianej wyżej macierzy o wymiarach M x Q
Natomiast
sama procedura optymalizacji parametru m może zostać opisana
następującą formułą, przy czym symbol G/R oznacza
funkcję kryterium bazującą na uogólnionym podejściu
maksymalizacji zysku i minimalizacji ryzyka, wprowadzonym
tutaj.
Ciągłość
pozycji w obrębie sekwencji dla ustalonych wartości m, czyli
w każdym z wierszy jest zapewniona dzięki warunkom wprowadzonym w
dwu poprzednich częściach opisu modelu. Pozostaje pytanie: czy na
najwyższym poziomie hierarchii, czyli tym, gdzie funkcjonuje już
docelowy, działający na rynku system, należy wprowadzić jeszcze
jakieś dodatkowe warunki. Co jeszcze ewentualnie trzeba zapewnić
aby system był jak najlepiej dostosowany do gry w realnych
warunkach?
Kontynuacja wątku tutaj.
Kontynuacja wątku tutaj.
Mam dziwne wrażenie, że próba optymalizacji parametru m to zły pomysł. Optymalizacja wielkości próby na podstawie której się optymalizuje pozostałe parametry to chyba rzadkość :D. Ale zobaczymy jakie będą efekty...
OdpowiedzUsuńPo drugie wydaje mi się, że nie trzeba aż tak panikować jeśli chodzi o ilość parametrów w modelu - 3 parametry to praktycznie nic :), a zawsze można zwiększyć ilość danych w próbie, co zmniejszy niebezpieczeństwo przeuczenia!
Po trzecie: czy jest możliwość, żeby utworzyć stronę z użytymi na blogu wzorami i objaśnieniami, którą będzie się na bieżąco aktualizować? - tzn. by można było szybko odszukać czym jest m, czym p itd. Szczególnie, że zaczyna się tego robić dużo a te wzory nie są zbyt czytelne - przynajmniej dla mnie :(
Osobiście bym też część oznaczeń pozamieniał - np. ohlc można zastąpić jakąś jedną uniwersalną literą a w razie konieczności doprecyzować czy chodzi o o,h,l czy c :) - chociaż nic na siłę!
No właśnie - skuteczność będzie można ocenić jak się pojawią pierwsze implementacje i wyniki na realnych danych. Parametry zawsze, zgodnie z zasadą brzytwy Ockhama, staram się oszczędzać jak tylko można, więc wprowadzam je zawsze po dogłębnej analizie wymagań.
UsuńPomysł oddzielnego zebrania wzorów i symboli jest dobry - wzorem dodatków do podręczników, typu "tablice i formuły" :) Wkrótce, miejmy nadzieję że w najbliższy weekend, planuję drobną modyfikację układu strony bloga, więc może to być dobrą okazją. A oznaczenia literowe nie muszą być wieczne, warto pomyśleć o uproszczeniu, szczególnie jeśli wzory zaczną być jeszcze bardziej złożone.
A może jeszcze rozważyć taką opcję:
OdpowiedzUsuń1. parametr p optymalizować na jakiejś nie za dużej stałej liczbie słupków np. 30-50
2. obliczoną "optymalną" wartość parametru p skorygować o parametry z poprzednich okresów (np. z tej samej ilości co wartość m) przemnożone przez jakąś malejącą liniowo wagę.
Ogólnie podejście z malejącym w czasie historycznym wpływem jakichś wcześniej wyznaczonych parametrów jest "kopalnią" nowych idei na systemy transakcyjne. Na moją intuicję, wiąże się to częściowo z modelami liniowymi szeregów czasowych typu ARMA oraz ogólniej GARCH. Pierwsze znam dość dobrze, ale to te drugie szczególnie mnie interesują. Na razie mam słabe rozeznanie tematu - pewnie jak się zabiorę za ich zastosowanie, będzie to zostawiać "ślady" na blogu :)
UsuńW realnych warunkach problemem może być dodatkowy warunek na zachowanie ciągłości pozycji. Mało prawdopodobne jest by wszystkie opcje miały przeciwną pozycję i nie byłoby z czego wybrać, ale w rzeczywistości odwrócenie może nie nastąpić a w teorii powinno. Tym samym trzeba będzie ręcznie korygować e_n,m i mieć świadomość, że najlepsze m według którego graliśmy zostało chwilowo wyeliminowane spośród rozpatrywanych opcji.
OdpowiedzUsuńNo tak, to jest odwieczny problem ewentualnych rozbieżności tego, co dostajemy w wyniku symulacji z sytuacjami realnymi, które są zwykle bardziej złożone. Zaczynając choćby od banalnego problemu poślizgów cenowych, które w realu mogą wcale nie występować albo też i być bardzo duże. A w symulacjach trzeba przyjmować jakieś wartości "umowne".
Usuń