MQL5-Assistent-Techniken, die Sie kennen sollten (Teil 19): Bayes'sche Inferenz

Einführung

Wir setzen die Nutzung des MQL5-Assistenten fort, indem wir die Bayes‘sche Inferenz besprechen, eine Methode in der Statistik, die Wahrscheinlichkeiten mit jeder neuen Information verarbeitet und aktualisiert. Sie hat zweifellos ein breites Spektrum an Anwendungsmöglichkeiten, doch für unsere Zwecke als Händler konzentrieren wir uns auf ihre Rolle bei der Prognose von Zeitreihen. Bei den Zeitreihen, die den Händlern zur Analyse zur Verfügung stehen, handelt es sich in erster Linie um die Preise der gehandelten Wertpapiere, aber wie wir in diesem Artikel sehen werden, können diese Reihen „erweitert“ werden, um auch Alternativen wie die Geschichte des Wertpapierhandels zu berücksichtigen.

Theoretisch sollte die Bayes'sche Inferenz die Marktanpassung eines jeden Handelssystems verbessern, da die Neubewertung jeder Hypothese inhärent ist. Dies sollte zu einer geringeren Kurvenanpassung führen, wenn sie anhand historischer Daten getestet und anschließend in Vorwärtstests oder Live-Konten-Trainings eingesetzt werden. Aber das ist nur die Theorie, und in der Praxis kann die Implementierung eine gute Idee zunichte machen, weshalb wir in diesem Artikel versuchen werden, mehr als eine mögliche Implementierung der Bayes'schen Inferenz zu berücksichtigen.

Unser Artikel ist daher in einem einfachen Format strukturiert, das die Definition der Bayes'schen Inferenz, Anwendungsbeispiele, die Illustrationen in einer nutzerdefinierten Signalklasse, einer Geldmanagementklasse und einer Trailing-Stop-Klasse umfassen, Berichte über Strategietests und schließlich eine Schlussfolgerung umfasst.

Definition

Die Bayes'sche Inferenz (BI) wird durch die Formel P(H|E) = [P(E|H) * P(H)] / P(E) ermittelt, wobei:

• H für die Hypothese steht, und
• E die Evidenz ist, sodass;
• P(H) ist die Vorwahrscheinlichkeit der Hypothese, während,
• P(E) ist die Wahrscheinlichkeit der Evidenz alias Grenzwahrscheinlichkeit.
• P(H|E) und P(E|H) sind die jeweiligen bedingten Wahrscheinlichkeiten, sie werden auch als Posteriorwahrscheinlichkeit bzw. Wahrscheinlichkeit bezeichnet.

Die obige Formel ist zwar einfach und geradlinig, erzeugt aber ein kleines Henne-Ei-Problem, nämlich, wie finden wir: P(E|H). Dies liegt daran, dass unsere oben aufgeführte Formel folgende Lösung impliziert:

P(E|H) = [P(H|E) * P(E)] / P(H).

Dies könnte jedoch auch als P(E|H) = [P(E∩H)] / P(H). umgeformt werden.  Das würde es uns ermöglichen, in dieser Situation einige manuelle Umgehungen vorzunehmen, wie wir weiter unten sehen werden.

Signal Klasse

Die Signalklasse legt in der Regel die Position fest, die ein Expert Advisor einnehmen sollte, sei es Kauf oder Verkauf. Dazu werden die Indikatorgewichte addiert, wobei der Summenwert immer zwischen 0 und 100 liegt. Bei der Verwendung von BI stehen uns eine Vielzahl von Zeitreihen zur Auswahl, doch dieser Artikel wird sich für die Signalklasse nur auf die Zeitreihe der Schlusskursänderungen beschränken.

Um diese oder andere Zeitreihen zu verwenden, müssen wir zunächst einen „systematischen“ Weg finden, um entweder die Werte der Zeitreihen zu klassifizieren oder ein Clustering zu erhalten. Dieser offensichtliche Schritt ist wichtig, weil er nicht nur unsere Zeitreihendaten normalisiert, sondern es uns auch ermöglicht, sie bei der Verarbeitung ihrer Wahrscheinlichkeit richtig zu identifizieren.

Die Clustering-Methode ist nicht überwacht, und wir verwenden einen rudimentären Ansatz, bei dem jedem Datenpunkt je nach Art der Preisänderung ein Cluster zugewiesen wird. Alle positiven Werte erhalten einen Cluster, Nullwerte einen eigenen Cluster und negative Werte ebenfalls einen eigenen Cluster. Wir haben in der Vergangenheit im Rahmen dieser Artikelserie alternative Clustering-Ansätze betrachtet, und der Leser ist eingeladen, mit diesen zu experimentieren. Da Clustering jedoch nicht das Hauptthema dieses Artikels ist, haben wir etwas sehr Elementares erwähnt.

Selbst mit diesem grundlegenden Clustering-Ansatz wird deutlich, dass wir die Datenpunkte besser „identifizieren“ und somit ihre Wahrscheinlichkeiten einschätzen können. Da es sich bei den Daten um Fließkommazahlen handelt, wäre sonst jeder einzelne Wert einmalig, was im Grunde auf einen einmaligen Clustertyp hinauslaufen würde, und das würde unseren Zweck der Ermittlung und Berechnung der Wahrscheinlichkeitswerte eindeutig zunichte machen. Unser einfacher Ansatz ist im folgenden Quelltext implementiert:

//+------------------------------------------------------------------+
//| Function to assign cluster for each data point                   |
//+------------------------------------------------------------------+
void CSignalBAYES::SetCluster(matrix &Series)
{  for(int i = 0; i < int(Series.Rows()); i++)
   {  if(Series[i][0] < 0.0)
      {  Series[i][1] = 0.0;
      }
      else if(Series[i][0] == 0.0)
      {  Series[i][1] = 1.0;
      }
      else if(Series[i][0] > 0.0)
      {  Series[i][1] = 2.0;
      }
   }
}

Sobald wir die Datenpunkte „identifiziert“ haben, können wir die posteriore Wahrscheinlichkeit, wie in der obigen Formel definiert, ausrechnen. Dazu bräuchten wir allerdings einen bestimmten Clustertyp, der uns als Hypothese dient. Dieses Cluster muss für Kauf- und Verkaufs-Positionen eindeutig sein. Daher haben wir für jeden dieser Fälle nutzerdefinierte Eingabeparameter, die als Indizes dienen, die den Typ des jeweils zu verwendenden Clusters identifizieren. Diese sind mit „m_cluster_long“ (Kauf) bzw. „m_cluster_short“ (Verkauf) bezeichnet.

Um die Posteriorwahrscheinlichkeit zu erhalten, werden also dieser Clusterindex und die „identifizierten“ oder geclusterten Zeitreihen als Eingaben benötigt. Unsere Funktion zur Berechnung der posterioren Wahrscheinlichkeit ermittelt die Wahrscheinlichkeit des Auftretens des Clusters der Positionstypen unter Berücksichtigung des aktuellen Clustertyps. Da wir eine Reihe aktueller Datenpunkte bereitstellen, die jeweils mit ihrem Clusterindex in einem Matrixformat versehen sind, haben wir im Wesentlichen den Datenpunkt mit dem Index Null als aktuellen Cluster.

Um unsere oben erwähnte mögliche Henne-Ei-Situation zu lösen, rechnen wir mit P(E|H).

Von den ersten Prinzipien. Da H, wie oben erläutert, durch den jeweiligen Positionsindex dargestellt wird, ist die Evidenz E der aktuelle Cluster oder der Clustertyp bei Index Null innerhalb der Eingabereihe. Unsere posteriore Wahrscheinlichkeit besteht also darin, die Wahrscheinlichkeit herauszufinden, dass der Clustertyp einer bestimmten Position als Nächstes auftritt, wenn die letzte Evidenz (Cluster bei Index 0) aufgetreten ist.

Um P(E|H) zu finden, müssen wir also die Eingabeserie erneut durchgehen und aufzählen, wann der Positionsindex H gefolgt vom Nullindex E (die Evidenz) aufgetreten ist. Auch dies ist eine Wahrscheinlichkeit, sodass wir zunächst den Raum spezifizieren, d. h. die H-Ereignisse finden, und dann innerhalb dieses Raums herausfinden, wie oft der Evidenzindex in Folge auftritt.

Dies bedeutet eindeutig, dass unsere Eingabereihen ausreichend lang sind, abhängig von der Anzahl der betrachteten Clustertypen. In unserem sehr einfachen Beispiel haben wir 3 Clustertypen (eigentlich 2, wenn man bedenkt, dass die Nullpreisänderung nur selten vorkommt) und dies könnte mit einer Eingabeserie von weniger als 50 funktionieren. Sollte man sich jedoch für einen abenteuerlicheren Clustering-Ansatz entscheiden, bei dem 5/6 oder mehr Clustertypen verwendet werden, muss die Standardgröße der Eingabeserie groß genug sein, um das Auftreten all dieser Clustertypen zu erfassen, damit unsere Posterior-Funktion funktioniert. Das Listing für die posteriore Funktion finden Sie unten:

//+------------------------------------------------------------------+
//| Function to calculate the posterior probability for each cluster |
//+------------------------------------------------------------------+
double CSignalBAYES::GetPosterior(int Type, matrix &Series)
{  double _eh_sum = 0.0, _eh = 0.0, _e = 0.0, _h = 0.0;
   for(int i = 0; i < int(Series.Rows()); i++)
   {  if(Type == Series[i][1])
      {  _h += 1.0;
         if(i != 0)
         {  _eh_sum += 1.0;
            if(Series[i][1] == Series[i - 1][1])
            {  _eh += 1.0;
            }
         }
      }
      if(i != 0 && Series[0][1] == Series[i][1])
      {  _e += 1.0;
      }
   }
   _h /= double(Series.Rows() - 1);
   _e /= double(Series.Rows() - 1);
   if(_eh_sum > 0.0)
   {  _eh /= _eh_sum;
   }
   double _posterior = 0.0;
   if(_e > 0.0)
   {  _posterior += ((_eh * _h) / _e);
   }
   return(_posterior);
}

Sobald wir unsere Posteriorwahrscheinlichkeit erhalten haben, würde sie die Wahrscheinlichkeit darstellen, dass der optimale Clustertyp der Position (ob „m_cluster_long“ oder „m_cluster_short“) angesichts des aktuellen Clustertyps (d. h. der Evidenz oder des Clustertyps für den Datenpunkt bei Index Null) auftritt. Dies wäre ein Wert im Bereich von 0,0 bis 1,0. Damit die jeweilige Hypothese, ob für Kauf- und Verkaufs-Positionen, wahrscheinlich ist, müsste der zurückgegebene Wert idealerweise mehr als 0,5 betragen, jedoch könnten spezielle Situationen vom Leser untersucht werden, in denen ein etwas geringerer Wert interessante Ergebnisse liefern könnte.

Der Dezimalwert müsste jedoch auf den Standardbereich von 0 bis 100 normiert werden, der von den Funktionen der Bedingungen für Kauf und Verkauf ausgegeben wird. Um dies zu erreichen, multiplizieren wir ihn einfach mit 100,0. Der typische Code für die (long) Kauf- und (short) Verkaufs-Bedingungen ist unten aufgeführt:

//+------------------------------------------------------------------+
//| "Voting" that price will grow.                                   |
//+------------------------------------------------------------------+
int CSignalBAYES::LongCondition(void)
{  int result = 0;
   vector _s_new, _s_old, _s;
   _s_new.CopyRates(m_symbol.Name(), m_period, 8, 0, m_series_size);
   _s_old.CopyRates(m_symbol.Name(), m_period, 8, 1, m_series_size);
   _s = _s_new - _s_old;
   matrix _series;
   _series.Init(_s.Size(), 2);
   for(int i = 0; i < int(_s.Size()); i++)
   {  _series[i][0] = _s[i];
   }
   SetCluster(_series);
   double _cond = GetPosterior(m_long_cluster, _series);
   _cond *= 100.0;
   //printf(__FUNCSIG__ + " cond: %.2f", _cond);
   //return(result);
   if(_cond > 50.0)
   {  result = int(2.0 * (_cond - 50.0));
   }
   return(result);
}

Mit dieser Signalklasse kann er leicht in jeden Expert Advisor über den MQL5-Assistenten integriert werden, indem man die Anleitungen verwendet, die hier und hier für Leser zu finden sind, die noch unerfahren im Umgang mit dem MQL5-Assistenten sind.

Klasse Geldmanagement

Es kann auch eine nutzerdefinierte Geldmanagementklasse (MM) implementiert werden, die BI nutzt. Auch hier müssen wir zunächst eine geeignete Zeitreihe auswählen, auf die wir unsere Analyse stützen können, aber wie bereits in der Einleitung erwähnt, werden wir uns bei MM für die historische Handelsperformance entscheiden. Da unser mit dem Assistenten zusammengestellter Expert Advisor nur mit einem Symbol handelt, wird die gesamte Handelshistorie, die bei der Abfrage zur Auswahl steht, auf den Expert Advisor anwendbar sein.

Bei der Verwendung von Zeitreihen der Handelshistorie als Grundlage für die Analyse orientieren wir uns an einer der eingebauten Geldmanagement-Klassen, die „größenoptimiert“ ist und bei der die Größe des Handelsvolumens im Verhältnis zur jüngsten Anzahl aufeinanderfolgender Verluste reduziert wird. In unserem Fall reduzieren wir jedoch die Losgröße, wenn die Wahrscheinlichkeit unseres bevorzugten Clusterindex (die Hypothese) unter einen anderen optimierbaren Parameter fällt, den wir „m_condition“ nennen.

Wir versuchen also im Wesentlichen, den idealen Clustering-Index zu ermitteln, bei dem wir die reguläre Losgröße im Verhältnis zur freien Marge verwenden können. Dieser Clustering-Index ist eine Kennung für die Art der Kapitalkurve (da nur ein Symbol gehandelt wird), bei der wir die Losgröße im Verhältnis zur freien Marge frei skalieren können. Der Verweis auf die „Art der Kapitalkurve“ ist etwas weit gefasst, da unser Clustering dem einfachen Format folgt, das wir in der Signalklasse angenommen haben. Was hier genau bestimmt wird, ist die Art des Handelsergebnisses, d. h. ob Gewinn oder Verlust (Null-Gewinn-Ergebnisse werden einem Index zugeordnet, dürften aber in der Analyse kaum eine Rolle spielen).

Das heißt, wenn zum Beispiel das günstige Handelsergebnis für die Skalierung der Losgröße mit freier Marge ein profitables Handelsergebnis ist, dann würden wir die Abfolge der vorherigen Handelsergebnisse untersuchen und versuchen, die Wahrscheinlichkeit eines weiteren profitablen Handelsergebnisses im Lichte der Evidenze (das Handelsergebnis beim Nullindex der Eingabereihe) zu ermitteln.

Dies erfordert einen weiteren optimierbaren Parameter in Form eines Wahrscheinlichkeitsschwellenwerts, der die Wahrscheinlichkeit der Wiederholung der angestrebten günstigen Bedingungen misst, sodass die Positionsgröße im Verhältnis zur Anzahl der gezählten Verluste reduziert wird, wenn das spätere Ergebnis unter diesem Schwellenwert liegt, wie es in der ursprünglichen Geldmanagementklasse „optimierte Größe“ der Fall ist. Das Listing für die Optimierungsfunktion finden Sie unten:

//+------------------------------------------------------------------+
//| Optimizing lot size for open.                                    |
//+------------------------------------------------------------------+
double CMoneyBAYES::Optimize(int Type, double lots)
{  double lot = lots;
//--- calculate number of losses orders without a break
   if(m_decrease_factor > 0)
   {  //--- select history for access
      HistorySelect(0, TimeCurrent());
      //---
      int       orders = HistoryDealsTotal(); // total history deals
      int       losses=0;                    // number of consequent losing orders
      //--
      int      size=0;
      matrix series;
      series.Init(fmin(m_series_size,orders), 2);
      series.Fill(0.0);
      //--
      CDealInfo deal;
      //---
      for(int i = orders - 1; i >= 0; i--)
      {  deal.Ticket(HistoryDealGetTicket(i));
         if(deal.Ticket() == 0)
         {  Print("CMoneySizeOptimized::Optimize: HistoryDealGetTicket failed, no trade history");
            break;
         }
         //--- check symbol
         if(deal.Symbol() != m_symbol.Name())
            continue;
         //--- check profit
         double profit = deal.Profit();
         //--
         series[size][0] = profit;
         size++;
         //--
         if(size >= m_series_size)
            break;
         if(profit<0.0)
            losses++;
      }
      //--
      series.Resize(size,2);
      SetCluster(series);
      double _cond = GetPosterior(Type, series);
      //--
      //---
      if(_cond < m_condition)
         lot = NormalizeDouble(lot - lot * losses / m_decrease_factor, 2);
   }
//--- normalize and check limits


...

//---

...

//---

...

//---
   return(lot);
}

Alle anderen Parameter wie Verkleinerungsfaktor und Prozentsatz der investierten Marge bleiben die gleichen wie in der ursprünglichen „größenoptimierten“ MM-Klasse.

Zum Vergleich mit BI könnte man das Kelly-Kriterium verwenden, um die Gewinnergebnisse und das Risiko-Ertrags-Verhältnis zu berücksichtigen, jedoch mit einer langfristigen Perspektive, die nicht notwendigerweise durch die Aktualisierung der Allokationskriterien mit den jüngsten oder zwischenzeitlichen Ergebnisse beeinflusst wird. Die Formel lautet: K = W - ((1 - W) / R)

Wobei:

• K ist die prozentuale Aufteilung
• W ist die Gewinnquote &
• R ist der Gewinnfaktor
  

Dieser Ansatz wird Berichten zufolge von Investmentgurus wegen seiner langfristigen Perspektive bei der Kapitalallokation gewählt. Es kann jedoch argumentiert werden, dass die Positionierung einen langfristigen Ansatz verfolgen sollte, nicht die Allokation. Langfristige Perspektiven werden häufig bei der Durchführung von Maßnahmen gewählt, aber wenn es um Risiken geht, ist die Kurzfristigkeit kritischer, weshalb die Durchführung ein separates Thema ist.

Die Vorteile des BI gegenüber dem Kelly-Kriterium (KK) lassen sich also mit dem Argument zusammenfassen, dass das KK von einem konstanten Marktvorsprung ausgeht, was in Fällen mit einem sehr langen Zeithorizont zutreffen kann. Das Ignorieren von Transaktionskosten und Slippage ist ein weiteres ähnliches Argument gegen KK, und obwohl beides auf lange Sicht ignoriert werden könnte, ist es fair zu sagen, dass die meisten Märkte so aufgebaut sind, dass jemand im Namen von oder mit dem Kapital eines anderen handeln kann. Dies bedeutet, dass diese kurzfristigen Ausschläge mit einem gewissen Maß an Sensibilität betrachtet werden müssen, da sie darüber entscheiden können, ob dem Händler oder Anleger das eingesetzte Kapital noch anvertraut wird.

Trailing-Stop-Klasse

Zum Schluss sehen wir uns eine nutzerdefinierte Implementierung einer Trailing-Klasse an, die ebenfalls BI verwendet. Unsere Zeitreihe wird sich dabei auf die Preisspanne konzentrieren, da diese immer ein guter Indikator für die Volatilität ist, eine wichtige Kennzahl für die Anpassung des Stop-Loss-Niveaus für offene Positionen. Wir haben Änderungen in den Zeitreihenwerten verwendet, da wir für das Signal Änderungen im Schlusskurs verwendet haben, während wir für MM das Handelsergebnis (Gewinne im Gegensatz zu den Kontobeständen) verwendet haben, die auch de facto Änderungen in den Kontobeständen sind. Durch die Anwendung der Änderungen auf unsere rudimentäre Clustermethode erhalten wir einen sehr einfachen, aber brauchbaren Satz von Indizes, die für die Gruppierung dieser Fließkommadatenpunkte nützlich sind.

Ein ähnlicher Ansatz für eine Experten-Trailing-Klasse würde sich auf die Veränderungen in der Preisspanne zwischen Hoch und Tief konzentrieren. Unsere Hypothese bei diesem Ansatz wäre, dass wir nach einem Clustering-Index suchen („m_long_cluster“ oder „m_short_cluster“, die beide in dieser Situation des Trailing gleich sein könnten), sodass wir, wenn es wahrscheinlicher ist, dass er in der Zeitreihe folgt, unseren Stop-Loss um einen Betrag verschieben müssen, der proportional zur aktuellen Preisspanne ist.

Wir haben getrennte Eingabeparameter für Kauf- und Verkaufs-Positionen verwendet, aber im Prinzip hätten wir auch nur einen einzigen verwenden können, um sowohl die Stop-Loss-Anpassung für Long- als auch für Short-Positionen zu bedienen. Unsere Auflistung, die dies umsetzt, finden Sie unten für Kauf-Positionen:

//+------------------------------------------------------------------+
//| Checking trailing stop and/or profit for long position.          |
//+------------------------------------------------------------------+
bool CTrailingBAYES::CheckTrailingStopLong(CPositionInfo *position,double &sl,double &tp)
  {
//--- check

...

//---
 
...

//---
   sl=EMPTY_VALUE;
   tp=EMPTY_VALUE;
   //
   
   vector _h_new, _h_old, _l_new, _l_old, _s;
   _h_new.CopyRates(m_symbol.Name(), m_period, COPY_RATES_HIGH, 0, m_series_size);
   _h_old.CopyRates(m_symbol.Name(), m_period, COPY_RATES_HIGH, 1, m_series_size);
   _l_new.CopyRates(m_symbol.Name(), m_period, COPY_RATES_LOW, 0, m_series_size);
   _l_old.CopyRates(m_symbol.Name(), m_period, COPY_RATES_LOW, 1, m_series_size);
   _s = (_h_new - _l_new) - (_h_old - _l_old);
   matrix _series;
   _series.Init(_s.Size(), 2);
   for(int i = 0; i < int(_s.Size()); i++)
   {  _series[i][0] = _s[i];
   }
   SetCluster(_series);
   double _cond = GetPosterior(m_long_cluster, _series);
   //
   delta=0.5*(_h_new[0] - _l_new[0]);
   if(_cond>0.5&&price-base>delta)
     {
      sl=price-delta;
     }
//---
   return(sl!=EMPTY_VALUE);
  }

Ein Vergleich mit alternativen Trailing-Stop-Klassen, wie z. B. den in der MQL5-Bibliothek integrierten, ist im Abschnitt Tests und Berichte unten zu finden.

Tests und Berichte

Wir führen Tests für EUR JPY auf dem 4-Stunden-Zeitfenster für das Jahr 2022 durch. Da wir 3 separate, nutzerdefinierte Klassen entwickelt haben, die in Wizard-Experten verwendet werden können, werden wir nacheinander 3 separate Expert Advisor zusammenstellen, wobei der erste nur die Signalklasse hat, während das Geldmanagement feste Lots verwendet und kein Trailing-Stop verwendet wird; der zweite wird die gleiche Signalklasse haben, aber mit dem Zusatz der Geldmanagementklasse, die wir oben kodiert haben, und ohne Trailing-Stop; während der letzte Expert Advisor alle 3 Klassen haben wird, die wir oben kodiert haben. Eine Anleitung für die Zusammenstellung dieser Klassen mit Hilfe des Assistenten finden Sie hier.

Wenn wir Tests mit allen drei Expert Advisors durchführen, erhalten wir die folgenden Berichte und Kapitalkurve:

Bericht und Kapitalkurve des Expert Advisorss nur mit der Signalklasse BI.

Bericht und Kapitalkurve des Expert Advisorss nur mit der Signalklasse BI und der Klasse MM.

Bericht und Kapitalkurve des Expert Advisors mit BI-Signalklasse, MM und Trailing-Klasse.

Es hat den Anschein, dass mit zunehmender Anpassung der BI von der Signalklasse über MM bis zur Trailing-Klasse die Gesamtleistung tendenziell positiv korreliert. Diese Tests werden mit echten Ticks durchgeführt, aber wie immer sind unabhängige Tests über längere Zeiträume ideal, und das sollte der Leser im Hinterkopf behalten. Zur Kontrolle können wir 3 separate Expert Advisors optimieren, die die Bibliotheksklassen verwenden. In all diesen Testläufen verwenden wir keine Ausstiegskursziele und verlassen uns nur auf das Signal der Eröffnungs- und Schlusskurse, um die Ausstiege zu kontrollieren. Wir wählen die Signalklasse des Awesome Oszillators, die größenoptimierte Geldmanagementklasse und die gleitenden Durchschnitts-Trailing-Klassen als das, was wir in dem „Control Expert Advisor“ verwenden. Ähnliche Testläufe wie oben führen zu den folgenden Ergebnissen:

Bericht und Kapitalkurve des Expert Advisors mit nur der Klasse des Awesome Oszillator.

Bericht und Kapitalkurve des Control Expert Advisors mit 2 der ausgewählten Klassen.

Bericht und Kapitalkurve des Control Expert Advisors mit allen 3 ausgewählten Klassen.

Die Leistung unserer Kontrolle bleibt hinter der des BI-Experten zurück, mit Ausnahme des dritten Laufs. Unsere Wahl der alternativen Signal-, MM- und Trailing-Klassen hat dieses „Ergebnis“ ebenfalls stark beeinflusst. Das übergeordnete Ziel war es jedoch festzustellen, ob es signifikante Leistungsunterschiede zwischen unserem BI Expert Advisor und dem, was in der MQL5-Bibliothek verfügbar ist, gibt, und die Antwort ist eindeutig.

Schlussfolgerung

Abschließend haben wir die Rolle der Bayes'schen Inferenz beim Aufbau eines einfachen Expert Advisors getestet, indem wir ihre grundlegenden Ideen in die drei verschiedenen Säulenklassen der mit dem MQL5-Assistenten zusammengestellten Expert Advisors integriert haben. Unser Ansatz hier war rein einführend und deckte nicht viel ab, insbesondere was die Verwendung von komplexeren Clustering-Algorithmen oder sogar mehrdimensionalen Datensätzen betrifft. Dies sind alles Wege, die erforscht werden können und die einem einen Vorteil verschaffen könnten, wenn sie über einen angemessenen Zeitraum mit qualitativ hochwertigen Tickdaten getestet werden. Mit Bayes'scher Inferenz kann noch viel mehr getestet werden, und der Leser ist herzlich eingeladen, dies zu erkunden, da die von den Assistenten zusammengestellten Experten ein zuverlässiges Werkzeug für das Testen und Prototyping von Ideen bleiben.