Co to jest przykładowy przykład testowania algorytmu?

Definicja: co oznacza testowanie algorytmu

Testowanie algorytmu to proces oceny automatycznego systemu opartego na regułach przy użyciu zdefiniowanych danych i zdefiniowanych metryk, aby zrozumieć, jak zachowywałby się przy określonych założeniach. W kontekście forex „algorytm” zazwyczaj oznacza deterministyczny zestaw reguł decyzyjnych (na przykład, kiedy wejść/wyjść i jak ustawiany jest rozmiar pozycji). Kluczowe jest to, że testowanie nie jest tym samym co prognozowanie: opisuje przeszłe lub symulowane zachowanie przy danym ustawieniu.

Przykładowy scenariusz (z jawnymi założeniami)

Poniżej znajduje się przykładowy przykład z uproszczonymi liczbami. Celowo nie opiera się on na danych rynkowych w czasie rzeczywistym.

Cel i okres testowy

Załóżmy, że chcesz przetestować algorytm, który otwiera i zamyka transakcje przy użyciu następujących stałych mechanik:

1. W danym momencie może być otwarta tylko jedna pozycja.
2. Gdy transakcja jest otwierana, zamyka się dokładnie po 5 krokach cenowych.
3. Zysk/strata jest obliczana na podstawie pojedynczej ceny wejścia i pojedynczej ceny wyjścia.
4. Rozmiar pozycji jest stały: 10 jednostek na transakcję.

Założenia (sformułuj je jawnie):

• Dane testowe: 3 niezależne „transakcje” z próbek podobnych do historycznych, ze znanymi cenami wejścia i wyjścia.
• Uwzględnienie spreadu/poślizgu: modelujesz koszty transakcyjne przy użyciu stałego kosztu na transakcję w wysokości 0,50 (w wybranych jednostkach P/L).
• Nie uwzględniono finansowania, rolowania ani podatków.
• Wszystkie ceny są traktowane jako w pełni znane w momencie decyzji (bez patrzenia w przyszłość).

Dane wejściowe

Załóżmy, że trzy transakcje mają następujące ceny wejścia i wyjścia (ruch ceny określa surowy P/L):

• Transakcja A: wejście 100,0 → wyjście 101,0 (ruch +1,0)
• Transakcja B: wejście 200,0 → wyjście 198,5 (ruch −1,5)
• Transakcja C: wejście 50,0 → wyjście 50,2 (ruch +0,2)

Aby przeliczyć ruch na surowy P/L, załóż prostą liniową konwersję:

• Surowy P/L = ruch × rozmiar pozycji
• Rozmiar pozycji = 10 jednostek

Więc:

• Surowy P/L transakcji A = (+1,0) × 10 = +10,0
• Surowy P/L transakcji B = (−1,5) × 10 = −15,0
• Surowy P/L transakcji C = (+0,2) × 10 = +2,0

Zastosuj koszty transakcyjne

Załóż stały koszt transakcyjny na zamkniętą transakcję w wysokości 0,50.

• Netto P/L na transakcję = surowy P/L − 0,50

Wyniki:

• Netto transakcji A = 10,0 − 0,50 = 9,5
• Netto transakcji B = −15,0 − 0,50 = −15,5
• Netto transakcji C = 2,0 − 0,50 = 1,5

Całkowity netto P/L w teście 3-transakcyjnym = 9,5 + (−15,5) + 1,5 = −4,5

Metryki, które możesz zweryfikować

Na podstawie tych samych założeń możesz obliczyć:

• Wskaźnik wygranych = 2 wygrane transakcje z 3 = 66,7%
• Średni netto P/L na transakcję = (−4,5) / 3 = −1,5
• Zysk brutto (suma wygranych) = 9,5 + 1,5 = 11,0
• Strata brutto (bezwzględna suma przegranych) = 15,5
• Współczynnik zysku = zysk brutto / strata brutto = 11,0 / 15,5 ≈ 0,71

To jest „przykładowy” przykład, ponieważ każda inna osoba może odtworzyć każdą liczbę, używając tych samych danych wejściowych i formuł. Jeśli nie może, oznacza to, że ustawienie testowe jest niejasne.

Jak mechanika różni się od zmienności rynku/dostawcy

W rzeczywistym użyciu kilka elementów zazwyczaj się zmienia i może zmienić wyniki, nawet jeśli reguły algorytmu pozostają takie same:

• Zachowanie rynku: reżimy zmienności, korelacje i zmiany trendów.
• Szczegóły wykonania: jakość realizacji zleceń, timing i zrealizowane koszty.
• Jakość danych: czy ceny podobne do historycznych odzwierciedlają to, co można było zaobserwować bez patrzenia w przyszłość.

Powyższy przykład oddzielił stałe mechaniki (5-krokowe utrzymanie, stały rozmiar, model kosztów) od zmiennych części (ruchy cen). To oddzielenie jest kluczowe dla dobrego testowania, ponieważ mówi ci, co jest określone przez twój algorytm, a co przez twoje założenia.

Istotne ograniczenia i tryby awarii

Co najmniej jednym istotnym ograniczeniem jest to, że testowanie może prowadzić do mylących wniosków, jeśli założenia nie odpowiadają rzeczywistości. Typowe tryby awarii obejmują:

• Overfitting: dostrajanie reguł lub parametrów algorytmu, aż dopasują się do konkretnej próbki historycznej, co zmniejsza wydajność na nowych danych.
• Niedopasowanie wykonania: symulowane wypełnienia i modele kosztów mogą być zbyt optymistyczne w porównaniu z rzeczywistym wykonaniem.
• Ukryte koszty i warunki: rzeczywisty handel może obejmować efekty, które nie są reprezentowane w uproszczonym modelu kosztów (na przykład zmienne spready lub inne opłaty).
• Wyciek danych: wykorzystanie w testowaniu informacji, które nie byłyby dostępne w momencie decyzji, zawyża wyniki.