Neue MQL4 mit #-Eigenschaft streng

Guten Tag,

Ich wundere mich über diese "MQL4 mit #property strict", die ich in den Code enthalten, aber Kompilieren ist immer mit Fehlern. Können Sie erklären, wie kann dies behoben werden? Ich meine, um einen Code mit dieser neuen Bedingung der "#property strict" zu haben.

Ich danke Ihnen!

Hallo,

Wir planen, die Unterstützung für die strikte Eigenschaft hinzuzufügen, damit Sie Ihre Strategien anbieten und möglicherweise auch in den MQL-Markt hochladen können. Das Ziel, dies verfügbar zu machen, ist der nächste Build 129 oder der übernächste Build. Wir hoffen, dass wir es in einem dieser Builds bereitstellen können

Perfekt! Ich danke Ihnen!

Tolle Neuigkeiten
Ausgezeichnet, Sie bieten immer das Neue und das Besondere. Machen Sie weiter so und wir werden Sie immer unterstützen.

Grüße,

Guten Tag,

Ich habe mir die neue Version angesehen, aber ich sehe, dass die #property strict noch aussteht.

Ich frage mich, ob ich etwas falsch mache oder ob es in der neuen Version nicht enthalten ist.

Ich danke Ihnen!

Hallo, ich stimme zu, dass es eine relevante Anfrage ist. Es ist nicht nur über strenge, aber wie ich mich erinnere einige Indikatoren sind mit alten MT Codierung Struktur.

Gibt es einen formellen Antrag auf eine Funktion?

Enyx

Hallo,

An der Umsetzung wird derzeit gearbeitet. Sie werden in der Lage sein, die spezielle Version des Strategiecodes, die den Anforderungen entspricht, auf dem MQL-Markt anzubieten

wird es auch für die PROFI-Lizenz oder nur für ULTIMATE sein?

Hallo Tomas,

Ich danke Ihnen.

Wenn ich das Thema ein wenig ausweiten soll.

Einige andere Konkurrenzprodukte (wie FXB) haben eine sehr gut definierte OOB-Indikatorstruktur, die die Indikatorcodierung logisch und einfach macht. Auch exportierte Expert Advisor Code ist gut strukturiert und leichter zu debuggen. Derzeit nur Trading-Optionen sind Art der Nähe zu diesem Ansatz.

Ich würde mir die Situation folgendermaßen vorstellen:

1) SQX-Indikatoren sind OOB-basiert

2) Der SQX-Expertencode basiert auf OOB

3) Eine OOB-basierte SQX-Indikatorvorlage, die der benutzerdefinierten Java-Code-Struktur von SQ folgt. Vergessen wir nicht, dass ein benutzerdefinierter Indikator sowohl in MQL als auch in Java implementiert werden muss. Ich habe bereits einen solchen Codierungsversuch, den ich gerne mit dem SQ-Team teilen würde. Die Vorteile sind zahlreich. Einfacher Austausch von Code zwischen Java-Implementierung und MQL. Gleiche Struktur. Weniger Kodierung, Bugs und einfacheres Testen. Es ermöglicht auch die Wiederverwendung/Einbindung von Komponenten in beiden Plattformen. Dafür ist OOB da...

Java-Code:

@Override
protected void OnBarUpdate() throws TradingException {
this.Calls++;

calcLow.onBarUpdate(Input.Low.get(0), CurrentBar);
calcHigh.onBarUpdate(Input.High.get(0), CurrentBar);

int trend = 0;

double clow = calcLow.getValue(0);
double chigh = calcHigh.getValue(0);
double cc = Input.Close.get(0);

if ((cc >= clow) && (cc <= chigh)) {
// Im Kanal
Trend = 0;
} sonst {
if (cc < clow) { trend = -1; }
if (cc > chigh) { trend = 1; }
}

// Normalisiertes Ergebnis zurückgeben
Lower.set(0, calcLow.getValue(0,0,true));
Upper.set(0, calcHigh.getValue(0,0,true));
Trend.set(0, trend);
}
}

MQL-Code:

for(int idx=ix_start; idx<=ix_end && !_StopFlag; idx++)
{
calcLow.onBarUpdate(low[idx],idx);
calcHigh.onBarUpdate(high[idx],idx);
UpdateExternalBuffers(idx);

int trend = 0;

double clow = calcLow.getValue(0,0,true);
double chigh = calcHigh.getValue(0,0,true);
double cc = close[idx];

if ((cc >= clow) && (cc <= chigh)) {
// Im Kanal
Trend = 0;
} sonst {
if (cc < clow) { trend = -1; }
if (cc > chigh) { trend = 1; }
}

Enyx

Enyx, ich bin nicht sicher, ob ich Ihnen folgen kann. Was verstehst Du unter OOB? Objektorientiert?

SQX-Indikatoren in Java sind objektorientiert. Meinen Sie ihre MQL4/5-Versionen?

Es ist subjektiv, aber ich würde sagen, die Struktur des Java-Codes für Indikatoren in SQ ist einfach zu verstehen, sie ist einfacher als in MQL.

Der Grund, warum der MQL-Code der benutzerdefinierten Indikatoren in SQ manchmal nicht objektorientiert ist, liegt einfach darin, dass einige von ihnen nicht von uns sind - wir haben sie in Java für SQ neu implementiert, aber MQL ist das Original.

Ich sehe keinen großen Sinn darin, sie in objektorientiertem Design in MQL zu reimplementieren. Meiner Meinung nach ist objektorientiertes Design für einfache Indikatoren ein unnötiger Overhead.

Aber ich bin offen für Diskussionen und für Ihre Argumente 🙂

Hallo Mark,

1) Ich muss zustimmen, Ihr Punkt ist (meist) gültig für bestehende Indikator-Code-Basis. Auf der anderen Seite (so lange ich mich erinnere) SQX MQL-Code-Basis für MT4 und MT5 ist meist anders. Wir haben also 3 Code-Basen - SQX Java-Snippet, MT4-Code, MT5-Code. Wie stellen wir sicher, dass diese in allen Fällen funktionieren (einschließlich der Randfälle)? Es gibt eine Option für die "Validierung", aber sagen wir, es ist nicht trivial, und zumindest in der Vergangenheit war die Testsuite für interne Indikatoren nicht vollständig erfolgreich.

Das manuelle Testen eines generierten Experten und der Abgleich mit MT ist ein mühsamer Aufwand. Und ja, es ist nicht einmal möglich für MT4 multi tf/symbols. Multiplizieren Sie dies für ein großes Portfolio...

Es bleiben also einige Zweifel offen. Ob sie gültig sind oder nicht, mag ein subjektiver Faktor sein, aber die Ergebnisse müssen in der Simulation und im realen Handel identisch sein. Eine identische Codebasis würde den gesamten Prozess kontrollierter machen. Beim Handel kann man vertrauen, aber man muss es auch überprüfen. Ich bin also der Meinung, dass es sich lohnt, die SQX-Codebasis zu vereinheitlichen. Ist es ein trivialer Aufwand? Nein, aber es ist in jeder Hinsicht lohnenswert.

2) Ja, ich meine den objektorientierten Ansatz. Es geht nicht um die Frage, ob Java-Snipped- oder MQL-Code einfacher ist, sondern um den Aufwand und die Kosten für die Unterstützung beider Codebasen. Und ich würde nicht zustimmen, dass es für beide Plattformen trivial ist, da ich benutzerdefinierte Indikatoren entwickle. Muss ich Beweise liefern, um meinen Standpunkt zu begründen?

Enyx

Und ich habe schnell Indikator-Tests auf der neuesten Version 129dev6 ausgeführt - Stochastics, Fibo, Pivots passieren NICHT SQs eigene interne Validierung. Macht es mein Punkt jetzt mehr gültig?

Enyx

Der Vollständigkeit halber. Wenn ich mich nicht irre, gibt es die von SQ bereitgestellte Testsuite nur für MT4. Oder liege ich falsch?

Enyx

werden wir uns die Testunterschiede ansehen.

Enyx schrieb:

Der Vollständigkeit halber. Wenn ich mich nicht irre, gibt es die von SQ bereitgestellte Testsuite nur für MT4. Oder liege ich falsch?

das Testpaket vergleicht Daten, und Sie können Indikatordaten auch aus Tradestation/MultiCharts exportieren. Ich muss prüfen, ob wir eine Funktion oder ein Beispiel dafür haben, ehrlich gesagt weiß ich es jetzt nicht.

Mark,

Ignorieren wir mein Geschrei für den Moment.

Der Anbieter muss die Funktionalität der integrierten Indikatoren für MT4/MT5 garantieren und sicherstellen, dass die Validierungstests für alle unterstützten Plattformen abgeschlossen und bestanden sind.

Und natürlich idealerweise für ein offizielles Skript (MT ist einfach), das eine Reihe von Testfällen in verschiedenen Zeitrahmen und Parameterbereichen generiert und dann eine einfach zu befolgende Anleitung zur Kreuzvalidierung dieser Fälle enthält. Es ist mir egal, ob es sich um 20000 Tests handelt, die in einer Stunde ausgeführt werden müssen, es sei denn, es ist halbautomatisch.

Vielleicht eine sqcli-Funktion zur schnellen Selbstkontrolle?

Nachtrag: Eingebaute Snippets (und indirekt auch benutzerdefinierte Snippets) haben bereits Metadaten-Definitionen (Bereiche, Typ, etc.). Haben Sie schon einmal darüber nachgedacht, dies ein wenig zu erweitern und automatisch Testsätze zu generieren?

Enyx

Da ich einige meiner benutzerdefinierten Indikator-Export-Code hatte, habe ich MT5 SqADX Indikator mit variablen Input-Parameter mit allen verfügbaren Daten in MQ (77MB testset) getestet.

Die Erfolgsquote für den Test beträgt 41%. Das ist ein Rundungsproblem.

Enyx