Własne EA, czyli poszukiwanie Złotego Grala

[259]

Gdybym miał wsadzić kilka robotów do jednego kodu zrobiłbym to tak:

1) zhermetyzował wszystko co się da - sporo pracy bo wszelkie zmienne globalne które są wywoływane bezpośrednio w rozmaitych funkcjach muszą być skonsolidowane i przekazywane jako parametr lub wyliczane jako zmienne lokalne,

2) Żeby się nie pogubić w kodzie długim jak papier toaletowy, rozdzieliłbym to na oddzielne pliki dołączane przez #include - każdy robot oddzielnie na tyle na ile się da. To też wymaga zmian i uporządkowania kodu - każdy z nich ma swój init(), start() i deinit() - trzeba je odpowiednio pozmieniać.
Niby proste ale często w nich jest niezły śmietnik, a w samym start() są rzeczy które powinny być raczej w init().
Np:
init() initRobot1()
start() doRobot1()
deinit() deinitRobot1()
Nie wspominając o kolejności kodu, nazwenictwie i przesłanianiu zmiennych...

3) ustandaryzował wszystko co się da, ograniczył do minimum ilość zmiennych globalnych, wsadził te które muszą pozostać globalne, a są specyficzne dla każdego robota do oddzielnych tabelek, a jakby się dało to najlepiej do jednej wielowymiarowej. Też kupa ręcznej roboty. Ale jak uda się to sprowadzić do czegoś w postaci initRobot1(robot1set); doRobot1(robot1set); deinitRobot1(robot1set) to mamy już jakąś protezę obiektów ;-)

4) I teraz jest zasadnicza sprawa - inwentaryzacja zleceń. Każdy z nich musi umieć rozpoznać swoje. Tutaj raczej nie obędzie się bez własnej bazy danych.
EDIT: można je rozgraniczyć numerami magic. Choć są i tacy brokerzy co śledzą te numery i robią im numery ;-)
Mam coś takiego co sprawdza pulę zleceń, i podlicza dla każdej postaci tego samego robota i nieźle odciska swój piętno na czasie wykonywania testów - dynamiczna alokacja pamięci. Coś za coś, nie ma nic za darmo...

A potem debuggował każdego robota oddzielnie bo razem to koszmar…

Aha - to co wyjdzie na backtestach nie będzie możliwe do uzyskania w rzeczywistości. Choćby przez czas jaki jest potrzebny na obsługę zleceń.
Jeżeli 5 robotów każdy po kolei ma coś zrobić ze zleceniami to w testerze pójdzie to gładko, a w rzeczywistości taka kolejka może trwać kilka minut, a w tym czasie rynek może zrobić bardzo dużo. Szczególnie jeżeli będą requoty lub inne zakłócenia. Z tego powodu unikałbym odczekiwania i powtarzania zleceń jak coś nie tak - lepiej wyskoczyć i poczekać na następną pętelkę zwalniając kolejkę innym.

I odpada praca na tikach, szczególnie jak ma pracować na wielu parach.
Są tickery do popychania kodu, albo można zrobić po prostu:

Kod: Zaznacz cały

start() {
	While(!IsStopped()) {
		for (int i=0;i<maxRobots;i++)
			switch (i) {
				case 0: doRobot1(robot1set); break;
				case 1: doRobot2(robot2set); break;
				...
				}
		Sleep (500);
	}
}

i pracuje w kółko Wada - żeby zmienić jakikolwiek parametr EA trzeba go ponownie wrzucić na wykres bo kod który pracuje będzie zbyt zajęty aby obsłużyć użytkownika. Co oznacza całkowity restart EA. Wniosek - kod musi być tak napisany aby mógł bezboleśnie kontynuować pracę po jakiejkolwiek przerwie. EDIT: w zasadzie każdy dobry robot powinien być tak napisany.

Na szczęście w MQL4 istnieje pewna forma wskaźnika (pointer) - przez parametr funkcji:

Kod: Zaznacz cały

funkcja(double& wszystkieZmienneFunkcji[]) {
	wszystkieZmienneFunkcji[3] = (wszystkieZmienneFunkcji[0] + wszystkieZmienneFunkcji[1]) * wszystkieZmienneFunkcji[2];
}

W ten sposób można załatwić zmienne globalne specyficzne dla każdego robota - można tej funkcji podstawiać niemalże dowolną tabelkę (o ile zgodzi się typ i ilość wymiarów) na której będzie robić obliczenia i zapisywać wyniki w tej samej tabelce. A samą tabelkę można zapisywać do pliku i w ten sposób dane nię będą tracone.

I na koniec nie zdziwiłbym się gdyby backtest takiego kodu trwał tygodniami. Zwłaszcza jak nie zrobi się w kodzie przełączników wyłączających to czego nie trzeba liczyć za każdym razem w teście albo będzie się niepotrzebnie liczyło to samo wielokrotnie. Np. Symbol() ;-) Albo niepotrzebne za to powtarzane w każdej pętelce pisanie/czytanie pliku ze zmiennymi...
Optymalizacja kodu się kłania i mam tu na myśli optymalizację pod kątem zdarzeń, a nie stricte matematyczną.
Choćby te if (warunek1) if (warunek2) if (warunek3) zamiast if (warunek 1 && warunek 2 && warunek 3) - zaczynamy od warunku który odrzuci najwięcej przypadków… Oczywiście to ma sens gdy te warunki to coś więcej niż zmienne typu bool albo proste dodawanie/odejmowanie/porównanie gotowych wartości.
Albo np. MarketInfo(symbol,MODE_STOPLEVEL) - w realu należy to sprawdzać za każdym razem bo brokerzy czasami tym manipulują. W testerze wystarczy raz w init() bo to się nie zmienia. Oczywiście to przykład - nie każdy robot jest na to wrażliwy.

[personov]

A ja już sobie przed chwilą połączylem 3 roboty. Może nie zrobiłem tego tak profesjonalnie jak to opisaliście, ale działa
Wszystko rozchodzi sie o przelicznie ilości otwartych pozycji dla danego robota i o zamykanie pozycji tylko dla danego robota.
Są 3 numery magic. W każdym OrderSend() jest różny numer magic w zależności od robota.
Do przeliczania ilości otwartych pozycji używam funkcji total(). Dałem trzy takie funkcje total1(), total2() i total3(). Każda przelicza zlecenia innego numeru magic.
Do zamknięcia uzywam również funkcji i zrobiłem tak smo jak z total().
Zajęło mi to ok. 2 godzin i działa

[259]

A ja już sobie przed chwilą połączylem 3 roboty. Może nie zrobiłem tego tak profesjonalnie jak to opisaliście, ale działa (...)
Zajęło mi to ok. 2 godzin i działa

A ja się tyle napisałem

[personov]

A teraz kilka lat testowania z łączeniem kilku robotów
Chodzi o to, żeby jeden lepiej się zachowywal w konsoli, a inny w tredzie itp.

[259]

Będziesz je przełączał czy każdy z nich autonomicznie będzie wykrywał trend/konsolę?

[personov]

Bez przełącznika. Mają się nawzajem usupełniać. Liczyć się będzie wynik końcowy.

[259]

Życzę powodzenia, naprawdę. Wiem ile to czasu zabiera żeby dojść do w miarę reprezentatywnych rezultatów.
Małe podpowiedzi:
- jeżeli się da to debugowanie najlepiej robić na danych zgrubnych - np. otwarcie świeczek zamiast najdokładniejszego testu. Wyniki są dalekie od rzeczywistości ale za to szybciej da się wyłapać proste rzeczy jak np. err 130 czy brak zleceń z powodu jakiegoś innego błędu.
- zanim przejdziesz do prawdziwych danych tikowych (np. Dukascopy) sprawdź to na tych interpolowanych tikach. Jakość nie ta ale znów trwa to szybciej i może uda się odfiltrować trochę śmiecia
- i na koniec, nie do końca sprawdzony ale zaobserwowany efekt z optymalizacji - jeżeli użyjesz Brit's patch który wyłącza nadpisywanie tików, będziesz mógł również przerwać optymalizację i wznowić ją bez rozpoczynania od początku.
Ma to szczególne znaczenie jeżeli z jakiegoś powodu musisz zrestartować komputer lub terminal się wywalił. Warunek - plik cache z poprzedniej optymalizacji musi istnieć, parametry nie mogą być zmienione i Brit's patch musi być uruchomiony na tej samej ramce czasowej co test (może się mylę ale zaobserwowałem taką zależność) zanim wznowisz optymalizację (najlepiej ze dwa razy bo zdarza się, że za pierwszym "nie załapie"). Co to jest ten Brit's patch itd jest tutaj:
http://www.forex-nawigator.biz/dyskusje ... 942#334942
Zaczyna się od: "Chyba jednak napiszę tę brakującą część - o co chodzi z tymi wszystkimi tickami, plikami, skryptami itd." Z późniejszymi zmianami ;-)
(tak czy inaczej, każda sroczka swój ogonek chwali )

[elky_obi]

Ja mam już swojego Grala, "jeden słownie" (1) wskaźnik, jak idę w górę to kopię jak idę w dół to ciągnę, skuteczność 100 % od 2 lat - małe kwoty = system = człowiek = wierzysz w co chcesz = Ostrołęka, najpiękniejsze miasto tryliarderów..

[rayzeel]

wierzysz w co chcesz.

W to nie wierzę i nie uwierzę

A wracając do testów to nie mogę zrozumieć sformułowania "jakość danych" ? Badałem to na różne sposoby i wychodzi mi, że spokojnie mogę sobie testować na interwałach minutowych, a pewnie nawet i wyższych... Problem w tym, że trzeba to odpowiednio ubrać, a mt4 już na to nie pozwala i w mt4 jest totalna katastrofa... Poza tym, nie rozumiem funkcjonowania testera w mt4 dlatego napisałem swój własny ... trochę pracy trzeba było w to włożyć, ale przynajmniej wiem dokładnie co robię...Jest też dużo innych plusów jak np. wykonanie testu od 2001 do teraz na m1 zajmuje 11 sekund A wracając do danych to oczywiście granie na większe zasięgi nie będzie miało znaczenia jak te tiki się rozkładają i sprowadzi się to do tego, że tiki wcale nie są potrzebne, liczy się to, czy świeca zahacza lub nie tp lub sl. System grający na wąskie zasięgi natomiast nie przejdzie takiej rozdzielczości danych, ale jeśli chcemy tak grać to musimy mieć tiki od brokera u którego chcemy grać. Dukas ma tiki z banku a broker mt4 paczkuje tiki i robi tak jak mu się podoba więc potem wychodzi, że strategia się wykłada i zwala się winę na strategię...

[259]

A wracając do testów to nie mogę zrozumieć sformułowania "jakość danych" ? Badałem to na różne sposoby i wychodzi mi, że spokojnie mogę sobie testować na interwałach minutowych (...) A wracając do danych to oczywiście granie na większe zasięgi nie będzie miało znaczenia jak te tiki się rozkładają i sprowadzi się to do tego, że tiki wcale nie są potrzebne, liczy się to, czy świeca zahacza lub nie tp lub sl

Jeżeli Twój kod/system/metoda opiera się o świeczki i ma odpowiedni margines, tzn. nie ma to znaczenia czy wejdzie/wyjdzie 3-7 pips dalej/bliżej to jak najbardziej masz rację i możesz olać te wszystkie tiki i wszystko co się za tym ciągnie

Poza tym, nie rozumiem funkcjonowania testera w mt4 dlatego napisałem swój własny(...)Jest też dużo innych plusów jak np. wykonanie testu od 2001 do teraz na m1 zajmuje 11 sekund

Mam jednego robota który przemiata półroczny test w kilkadziesiąt sekund i drugiego który na tych samych danych potrzebuje 17 minut. A trzeci potrzebuje na to pół dnia...
Ale muszę tutaj wyrazić wielki szacun za zrobienie własnego testera - kilka razy do tego podchodziłem i rezygnowałem ze względu na bardzo skomplikowaną materię. Na początku wydaje się to być proste, ale jak dochodzi się do szczegółów to nagle wzór na ilość kombinacji bez powtórzeń staje w oczach i rośnie zgodnie z naturalnym przyrostem jaki z niego wynika...

Dukas ma tiki z banku a broker mt4 paczkuje tiki i robi tak jak mu się podoba więc potem wychodzi, że strategia się wykłada i zwala się winę na strategię...

Z tym akurat się nie zgodzę. Przynajmniej nie co do zasady i konsekwencji kwantyzacji. Ale nie chciałbym tego rozwijać w tym wątku. Lepszy jest do tego ten o modelowaniu.