Ihre Symbole und Ihre Datafeeds in Metatrader 5 - Seite 11
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich werde eine weitere Testfunktion hinzufügen, die zwei gleichmäßige Plateaus mit Höchstwerten enthält:
z = abs(tanh(x) + tanh(y))
Wenn Sie X,Y von -20 auf +20 mit Schritt 0,1 ändern, dauert die gesamte Iteration 160801 Iterationen.
Im Test werden beide Plateaus in 1400 Iterationen erreicht, was weniger als ein Prozent der gesamten Suche ausmacht.
Wird das jemand bei GA machen? Interessant zu vergleichen.
Ich werde eine weitere Testfunktion hinzufügen, die zwei gleichmäßige Plateaus mit Höchstwerten enthält:
z = abs(tanh(x) + tanh(y))
Wenn Sie X,Y von -20 auf +20 mit Schritt 0,1 ändern, dauert die komplette Iteration 160801 Iterationen.
Im Test werden beide Plateaus in 1400 Iterationen erreicht, was weniger als ein Prozent der gesamten Suche ausmacht.
Wird das jemand bei GA machen? Interessant zu vergleichen.
Suchen Sie nicht mit GA?
Die Arbeit mit zwei Argumenten einer optimierten Funktion ist überhaupt nicht aussagekräftig. Nicht nur, weil der Suchraum klein ist, sondern auch, weil die "schlechten" Eigenschaften des Suchalgorithmus selbst auftreten können.
Wandeln Sie die Formel in eine Form mit mindestens 10 Argumenten um, und alle positiven und negativen Eigenschaften des Algorithmus werden sichtbar.
Suchen Sie nicht mit GAs?
Die Arbeit mit zwei Argumenten einer optimierten Funktion ist überhaupt nicht aussagekräftig. Nicht nur, weil der Suchraum klein ist, sondern auch, weil die "schlechten" Eigenschaften des Suchalgorithmus selbst auftreten können.
Konvertieren Sie die Formel in eine Form, die aus mindestens 10 Argumenten besteht - alle positiven und negativen Eigenschaften des Algorithmus werden auf einmal angezeigt.
Dies ist nicht GA, es gibt einen Link zu dem Artikel in diesem Thema.
Oben habe ich ein Beispiel mit sechs Parametern angegeben. Das ganze Problem mit der Anzeige vieler Parameter.
Wenn Sie eine Funktion mit mehr Parametern vorschlagen, werde ich einen Test machen.
Wenn Sie eine Funktion mit mehr Parametern vorschlagen - ich werde einen Test machen.
Y=a+b;
wo:
a=Haut(x1, y1)+Haut(x2, y2)+Haut(x3, y3)+Haut(x4, y4)+Haut(x5, y5);
b=Haut(x6, y6)+Haut(x7, y7)+Haut(x8, y8)+Haut(x9, y9)+Haut(x10, y10);
Sie wissen bereits, wo Sie die Funktion Skin finden.
Es gibt also 20 Variablen, und die Y-Funktion ist sehr einfach zu visualisieren. Sie können dieses Prinzip nutzen, um eine Funktion mit einer unbegrenzten Anzahl von Argumenten zu erstellen und sie dennoch visualisieren zu können.
Dementsprechend wird das Endergebnis als Y*2/n gegen den bekannten Wert des Extremums geprüft, wobei n die Gesamtzahl der Argumente ist.
Und können Sie mir ein Beispiel für einen Algorithmus nennen, bei dem bei einem "Untersteuern" ein komplettes Übersteuern in einem Dutzend Stunden und bei MT in Monaten erfolgt?
Bei diesem Ansatz ist die Reihenfolge der Durchläufe von großer Bedeutung, da fast alle Berechnungen zwischengespeichert werden. Für fast jeden (unabhängigen) Eingangsparameter von TC gibt es immer globale Puffer im Optimierer, die die Werte früherer Durchläufe speichern.
Sie verwenden zum Beispiel den MA MA und PriceChannel. Für jeden dieser Indikatoren gibt es eigene unabhängige Eingabeparameter. Deshalb schreiben wir für jeden Indikator die Funktion vor (ein paar Zeilen eigentlich, mit OOP sollte es noch schöner sein), die seinen globalen Puffer füllen soll. Dann vergleichen wir die Ressourcenintensität der einzelnen Indikatoren (PriceChannel ist schwerer als MA). Die Eingangsparameter der schwereren Indikatoren werden in der externen Schleife (erstes for) aufgezählt, die einfachen - in der internen Schleife (in verschachtelten for).
Hier haben wir einen großen Gewinn. Außerdem gibt es C++, ganzzahlige Berechnungen und ein eigenes Bestellsystem ohne unnötige Kontrollen. So erhalten Sie das Ergebnis. Infolgedessen sind einzelne Läufe mindestens eine Größenordnung schneller als MT. Und die Optimierung ist um Größenordnungen schneller.
Was im MT-Optimierer fehlt, ist die Funktion OnOptimization, die einen vollständigen Zugriff auf die erhaltene Matrix der Optimierungsergebnisse ermöglichen würde. Dort führe ich verschiedene Analysen der erhaltenen Matrix durch: Filtern, Kombinieren von Durchläufen eines Auftrags, die sich nicht durch die Handelszeit überschneiden, usw. Noch nützlicher ist jedoch die Berechnung von Gewichtungskoeffizienten für jeden der Durchgänge, um einen Meta-TS in Form eines geeigneten Portfolios zusammenzustellen. OnOptimization verfügt zu diesem Zweck über eine Vektor-Gleichheit für jeden der nicht "hoffnungslosen" Durchgänge.
Aber der Untertester wird nicht in der Phase der Suche nach einem funktionierenden TS erfunden, sondern erst dann, wenn er leider schon gefunden ist. Die Suche selbst ist ein ganz anderes Stadium: ohne Beschreibung.
Kann das jemand bei GA überprüfen? Interessant zu vergleichen.
Y=a+b;
wo:
a=Haut(x1, y1)+Haut(x2, y2)+Haut(x3, y3)+Haut(x4, y4)+Haut(x5, y5);
b=Haut(x6, y6)+Haut(x7, y7)+Haut(x8, y8)+Haut(x9, y9)+Haut(x10, y10);
Sie wissen bereits, wo Sie die Funktion Skin suchen müssen.
Es gibt also 20 Variablen, und die Y-Funktion ist sehr einfach zu visualisieren. Sie können dieses Prinzip nutzen, um eine Funktion mit einer unbegrenzten Anzahl von Argumenten zu erstellen und sie dennoch visualisieren zu können.
Dementsprechend wird das Endergebnis als Y*2/n gegen den bekannten Wert des Extremums geprüft, wobei n die Gesamtzahl der Argumente ist.
Wie viele Durchgänge und mit welchem Schritt von Variablen ist die Berechnung?
Wen kümmert es, wenn Ihnen das Bild nicht gefällt?
Die 64-Bit-GA in MT5 ist sehr gut, es löst jedes Problem, die Hauptsache ist, das Problem richtig zu formulieren.
Ich weiß nicht, von welcher Art von Nerd Sie in diesem Thread über GA sprechen.
Ich glaube nicht, dass das Problem bei der GA liegt, aber der Tester selbst ist unbrauchbar, vor allem an der Börse wegen der falschen Speicherung der Kursdaten und der Unmöglichkeit, die eigenen Daten zu speichern.
Ich hoffe, dass dieses Problem gelöst wird, aber ich fürchte, ich muss noch 3-5 Jahre warten.
Sie verwenden zum Beispiel die MA und den PriceChannel. Jeder dieser Indikatoren hat seine eigenen unabhängigen Eingangsparameter. Daher gibt es für jeden Indikator eine geschriebene Funktion (eigentlich nur ein paar Zeilen, mit OOP muss es noch schöner sein), die den entsprechenden globalen Puffer füllt. Dann vergleichen wir die Ressourcenintensität der einzelnen Indikatoren (PriceChannel ist schwerer als MA). Die Eingangsparameter der schwereren Indikatoren werden in der externen Schleife (erstes for) aufgezählt, die einfachen in der internen Schleife (im verschachtelten for).
Irgendetwas sagt mir, dass dieser Ansatz auch im Rahmen von GA problemlos möglich wäre. Der Arbeitsaufwand ist in etwa der gleiche. Die "innere Schleife" wird bei jedem Durchgang durchlaufen...
Aber vor allem: Wie hoch wäre die Nachfrage? Wie ich vermute, verwendet nicht jeder eine einfache benutzerdefinierte OnTester()-Funktion. Dies ist jedoch ein sehr leistungsfähiges Optimierungsinstrument.
Hier ist zum Beispiel eine meiner Umsetzungen:
double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert)
{
ulong ulTickedTime = pmeExpert.GetTickedTime();
uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions();
double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT);
double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT);
double dProfit = TesterStatistics(STAT_PROFIT);
double dNumOfTrades = TesterStatistics(STAT_TRADES);
double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES);
double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES);
double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR);
double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK;
double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY;
Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2));
Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1));
if(dNumOfTrades == 0)
{
Print("Ни одного трейда !");
return(-100000);
};
if(dMaxNumOfSL > uiIMaxNumOfSeqSL)
return(-10000 - dMaxNumOfSL*100 + dProfit/1000);
double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades;
if((bILongAllow == false) || (bIShortAllow == false))
dBarsPerTrade /= 2;
if(dBarsPerTrade < MIN_BARS_PER_TRADE)
return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor);
Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1));
if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify)
{
Print("Слишком много СЛ подряд !");
return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000;
};
Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1));
if(dBarsPerTrade > MAX_BARS_PER_TRADE)
{
Print("Слишком редкие трейды !");
return(dRecoveryFactor - dBarsPerTrade/100);
};
Print("Profit: ",DoubleToString(dProfit,3));
Print("Profit per day: ",DoubleToString(dProfitPerDay,3));
Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL));
Print("Приемлемая торговля.");
return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);
};
Hier basiert er auf dem Erholungsfaktor, hebt aber Läufe mit einer Mindestanzahl aufeinander folgender SLs und mit recht häufigen Trades hervor.
Aber so wie ich das sehe, nutzen die meisten die Standardoptionen.