Nouveau MQL4 avec propriété # stricte

Bonne journée,

Je m'interroge sur ce "MQL4 with #property strict", que j'inclus dans le code mais dont la compilation est toujours entachée d'erreurs. Pouvez-vous m'expliquer comment cela peut être corrigé ? Je veux dire, avoir un code avec cette nouvelle condition de "#property strict".

Merci de votre attention !

Bonjour,

Nous prévoyons d'ajouter la prise en charge de la propriété stricte afin que vous puissiez proposer vos stratégies et éventuellement les télécharger sur le marché MQL. L'objectif est de rendre cela disponible dans la prochaine version 129 ou dans la version suivante. Nous espérons que cette fonctionnalité sera disponible dans l'une de ces versions.

Parfait ! Merci de votre attention !

Excellente nouvelle
Excellent, vous offrez toujours du nouveau et du spécial. Continuez ainsi et nous vous soutiendrons toujours.

les regards,

Bonjour,

J'ai vérifié la nouvelle version, mais je vois que le #property strict est toujours en attente.

Je me demande si je fais quelque chose de mal ou si ce n'est pas inclus dans la nouvelle version.

Merci de votre attention !

Bonjour, je suis d'accord pour dire que c'est une demande pertinente. Il ne s'agit pas seulement d'une question de rigueur, mais si je me souviens bien, certains indicateurs utilisent l'ancienne structure de codage de MT.

Y a-t-il une demande formelle de fonctionnalité ?

Enyx

Bonjour,

La mise en œuvre est en cours. Vous serez en mesure de fournir la version spéciale du code de la stratégie qui répond aux exigences du marché MQL.

Est-ce que ce sera aussi le cas pour la licence PROFI ou seulement pour la licence ULTIMATE ?

Bonjour Tomas,

Nous vous remercions.

Si je dois m'étendre un peu sur le sujet.

D'autres produits concurrents (comme FXB) ont une structure d'indicateurs OOB très bien définie qui rend le codage des indicateurs logique et facile. Le code exporté du conseiller expert est également bien structuré et plus facile à déboguer. Actuellement, seules les options de trading sont proches de cette approche.

Voici comment j'imaginerais la situation :

1) Les indicateurs du SQX sont basés sur l'OOB

2) Le code expert SQX est basé sur l'OOB

3) Un modèle d'indicateur SQX basé sur OOB qui suit la structure du code Java personnalisé de SQ. N'oublions pas qu'un indicateur personnalisé doit être implémenté à la fois en MQL et en Java. J'ai déjà une tentative de codage de ce type que je serai heureux de partager avec l'équipe de SQ. Les avantages sont nombreux. Échange facile de code entre l'implémentation Java et MQL. Même structure. Moins de codage, de bogues et des tests plus faciles. Cela permet également de réutiliser/inclure des composants dans les deux plateformes. C'est la raison d'être de l'OOB.

Code Java :

@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)) {
// Dans le canal
tendance = 0 ;
} else {
if (cc < clow) { trend = -1 ; }
if (cc > chigh) { trend = 1 ; }
}

// Retourne le résultat normalisé
Lower.set(0, calcLow.getValue(0,0,true)) ;
Upper.set(0, calcHigh.getValue(0,0,true)) ;
Trend.set(0, trend) ;
}
}

Code MQL :

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)) {
// Dans le canal
tendance = 0 ;
} else {
if (cc < clow) { trend = -1 ; }
if (cc > chigh) { trend = 1 ; }
}

Enyx

Enyx, je ne suis pas sûr de suivre. Qu'entendez-vous par OOB ? Orienté objet ?

Les indicateurs SQX en Java sont orientés objet, parlez-vous de leurs versions MQL4/5 ?

C'est subjectif, mais je dirais que la structure du code Java pour les indicateurs dans SQ est simple à comprendre, elle est plus simple que dans MQL.

La raison pour laquelle le code MQL des indicateurs personnalisés dans SQ n'est parfois pas orienté objet est simplement que certains d'entre eux ne sont pas les nôtres - nous les avons réimplémentés en Java pour SQ, mais MQL est original.

Je ne vois pas l'intérêt de les réimplémenter en conception orientée objet dans MQL, mon opinion étant que la conception orientée objet pour des indicateurs simples est une surcharge inutile.

Mais je suis ouvert à la discussion et à l'écoute de vos arguments 🙂 .

Bonjour Mark,

1) Je dois admettre que votre point de vue est (en grande partie) valable pour la base de code des indicateurs existants. D'un autre côté (pour autant que je me souvienne), la base de code de SQX MQL pour MT4 et MT5 est en grande partie différente. Nous avons donc 3 bases de code - SQX Java snippet, code MT4, code MT5. Comment s'assurer que tous ces codes fonctionnent dans tous les cas (y compris les cas limites) ? Il existe une option de "validation", mais disons que son utilisation n'est pas triviale et que, du moins dans le passé, la suite de tests pour les indicateurs internes ne passait pas complètement.

Le test manuel d'un expert généré et la vérification croisée avec MT sont des efforts laborieux. Et oui, ce n'est même pas possible pour MT4 multi tf/symbols. Multipliez cela pour un gros portefeuille...

Cela laisse donc quelques doutes sur la table. La validité ou non peut être un facteur subjectif, mais les résultats doivent être identiques dans la simulation et dans le commerce réel. Une base de code identique rendrait l'ensemble du processus plus contrôlé. Dans le commerce, on peut faire confiance, mais il faut valider. Je pense donc qu'il vaut la peine d'unifier la base de code de SQX. Est-ce un effort insignifiant ? Non, mais cela en vaut la peine à tous points de vue.

2) Oui, je parle de l'approche orientée objet. La question n'est pas de savoir si le code Java ou MQL est plus simple, mais de connaître les efforts et les coûts liés à la prise en charge des deux bases de code. Et je ne suis pas d'accord pour dire que c'est trivial pour les deux plateformes, car je développe des indicateurs personnalisés. Dois-je fournir des preuves pour justifier mon point de vue ?

Enyx

Et j'ai rapidement exécuté des tests d'indicateurs sur la dernière version 129dev6 - Stochastiques, Fibo, Pivots ne passent PAS la validation interne de SQ. Est-ce que cela rend mon point de vue plus valide ?

Enyx

Pour être complet. Sauf erreur de ma part, la suite de tests fournie par SQ n'existe que pour MT4. Ou bien je me trompe ?

Enyx

nous examinerons les différences entre les tests.

Enyx a écrit :

Pour être complet. Sauf erreur de ma part, la suite de tests fournie par SQ n'existe que pour MT4. Ou bien je me trompe ?

la suite de tests compare les données, et vous pouvez exporter les données de l'indicateur également à partir de Tradestation/MultiCharts. Je dois vérifier si nous avons une fonction ou un exemple pour cela, honnêtement je ne sais pas pour l'instant.

Marquer,

Ne tenons pas compte de mes cris pour l'instant.

Le fournisseur doit garantir la fonctionnalité des indicateurs intégrés pour MT4/MT5 et s'assurer que les tests de validation sont terminés et réussis pour toutes les plates-formes prises en charge.

Et bien sûr, l'idéal serait de disposer d'un script officiel (MT est facile) générant un ensemble de cas de test dans différents délais et gammes de paramètres, ainsi que des instructions faciles à suivre pour la validation croisée de ces cas. Je me fiche de savoir s'il s'agit de 20000 tests à exécuter en une heure, à moins que ce ne soit semi-automatique.

Peut-être une fonction sqcli pour un auto-contrôle rapide ?

Addendum : Les snippets intégrés (et indirectement ceux de l'utilisateur) ont déjà des définitions de métadonnées (plages, type, etc.). N'avez-vous jamais pensé à l'étendre un peu et à générer automatiquement des jeux de tests ?

Enyx

J'ai testé l'indicateur MT5 SqADX avec des paramètres d'entrée variables en utilisant toutes les données disponibles dans le MQ (77MB testset).

Le taux de réussite au test est de 41%. Il s'agit d'un problème d'arrondi.

Enyx