Nuovo MQL4 con #proprietà rigorosa

Buona giornata,

Mi sto chiedendo di questo "MQL4 con #property strict", che ho incluso nel codice ma la compilazione è sempre con errori. Potete spiegarmi come si può risolvere questo problema? Voglio dire, per avere un codice con questa nuova condizione di "#property strict".

Grazie!

Salve,

abbiamo in programma di aggiungere il supporto per la proprietà rigorosa, in modo che possiate offrire le vostre strategie ed eventualmente caricarle anche nel mercato MQL. L'obiettivo di renderla disponibile è la prossima build 129 o quella successiva. Speriamo di renderlo pronto in una di queste build.

Perfetto! Grazie!

Grandi notizie
Eccellente, offrite sempre il nuovo e lo speciale. Continuate così e vi sosterremo sempre.

saluti,

Buon pomeriggio,

Stavo controllando la nuova release ma vedo che la proprietà # strict è ancora in sospeso.

Mi chiedo se sto sbagliando qualcosa o se non è incluso nella nuova versione.

Grazie!

Salve, sono d'accordo che si tratta di una richiesta pertinente. Non si tratta solo di strict, ma se non ricordo male alcuni indicatori utilizzano la vecchia struttura di codifica della MT.

Esiste una richiesta formale di funzionalità?

Enyx

Salve,

l'implementazione è in fase di lavorazione. Sarete in grado di fornire la versione speciale del codice della strategia che soddisfa i requisiti nel mercato MQL.

sarà anche per la licenza PROFI o solo per ULTIMATE?

Ciao Tomas,

Grazie.

Se devo ampliare un po' l'argomento.

Altri prodotti della concorrenza (come FXB) hanno una struttura di indicatori OOB molto ben definita che rende la codifica degli indicatori logica e semplice. Anche il codice dell'expert advisor esportato è ben strutturato e più facile da debuggare. Attualmente solo le opzioni di trading si avvicinano a questo approccio.

Ecco come immaginerei la situazione:

1) Gli indicatori SQX sono basati su OOB

2) Il codice esperto SQX è basato su OOB

3) Un modello di indicatore SQX basato su OOB che segue la struttura del codice Java personalizzato di SQ. Non dimentichiamo che un indicatore personalizzato deve essere implementato sia in MQL che in Java. Ho già un tentativo di codifica di questo tipo che sarò lieto di condividere con il team SQ. I vantaggi sono numerosi. Facile scambio di codice tra l'implementazione Java e MQL. Stessa struttura. Meno codifica, bug e test più semplici. Inoltre, consente di riutilizzare/includere componenti in entrambe le piattaforme. Ecco a cosa serve OOB...

Codice 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)) {
// Nel canale
tendenza = 0;
} else {
se (cc < clow) { trend = -1; }
if (cc > chigh) { trend = 1; }
}

// Restituzione del risultato normalizzato
Lower.set(0, calcLow.getValue(0,0,true));
Upper.set(0, calcHigh.getValue(0,0,true));
Trend.set(0, trend);
}
}

Codice 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)) {
// Nel canale
tendenza = 0;
} else {
se (cc < clow) { trend = -1; }
if (cc > chigh) { trend = 1; }
}

Enyx

Enyx, non sono sicuro di seguirti. Cosa intendi per OOB? Orientato agli oggetti?

Gli indicatori SQX in Java sono orientati agli oggetti, si riferisce alle versioni MQL4/5?

È soggettivo, ma direi che la struttura del codice Java per gli indicatori in SQ è semplice da capire, è più semplice che in MQL.

Il motivo per cui il codice MQL degli indicatori personalizzati in SQ a volte non è orientato agli oggetti è semplicemente che alcuni di essi non sono nostri - li abbiamo reimplementati in Java per SQ, ma MQL è originale.

Non vedo il motivo di reimplementarli in un design orientato agli oggetti in MQL; la mia opinione è che il design orientato agli oggetti per gli indicatori semplici sia un sovraccarico inutile.

Ma sono aperto alla discussione e ad ascoltare le vostre argomentazioni 🙂

Ciao Mark,

1) Sono d'accordo che il tuo punto di vista è (per lo più) valido per la base di codice degli indicatori esistenti. D'altra parte (per quanto mi ricordo) il codice base di SQX MQL per MT4 e MT5 è per lo più diverso. Quindi abbiamo 3 basi di codice - SQX Java snippet, codice MT4, codice MT5. Come facciamo a garantire che tutti questi codici funzionino in tutti i casi (compresi quelli di bordo)? Esiste un'opzione di "convalida", ma diciamo che non è di uso banale e almeno in passato la suite di test per gli indicatori interni non passava completamente.

Il test manuale di un esperto generato e il controllo incrociato con la MT è uno sforzo così minuzioso. E sì, non è nemmeno possibile per MT4 multi tf/simboli. Moltiplicate questo per un grande portafoglio...

Quindi lascia alcuni dubbi sul tavolo. La validità o meno può essere un fattore soggettivo, ma i risultati devono essere identici nella simulazione e nel trading reale. Una base di codice identica renderebbe l'intero processo più controllato. Nel trading ci si può fidare, ma bisogna convalidare. Ecco quindi il mio punto di vista: vale la pena di unificare il codice base di SQX. È uno sforzo banale? No, ma vale la pena sotto ogni aspetto.

2) Sì, intendo un approccio orientato agli oggetti. Non si tratta di stabilire se il codice Java snipped o MQL sia più semplice, ma dello sforzo e del costo di supportare entrambe le basi di codice. E non sono d'accordo che sia banale per entrambe le piattaforme, dato che sviluppo indicatori personalizzati. Devo fornire prove per giustificare il mio punto di vista?

Enyx

E ho eseguito rapidamente il test degli indicatori sull'ultima release 129dev6 - Stocastici, Fibo, Pivot NON passano la validazione interna di SQ. Questo rende il mio punto di vista più valido?

Enyx

Per completezza. Se non sbaglio esiste una suite di test SQ solo per MT4. Oppure mi sbaglio?

Enyx

esamineremo le differenze tra i test.

Enyx ha scritto:

Per completezza. Se non sbaglio esiste una suite di test SQ solo per MT4. Oppure mi sbaglio?

la suite di test confronta i dati ed è possibile esportare i dati degli indicatori anche da Tradestation/MultiCharts. Devo verificare se esiste una funzione o un esempio per questo, sinceramente ora non lo so.

Mark,

Ignoriamo per il momento le mie urla.

Il fornitore deve garantire la funzionalità degli indicatori integrati per MT4/MT5 e assicurare che i test di convalida siano completati e superati per tutte le piattaforme supportate.

E naturalmente l'ideale sarebbe avere uno script ufficiale (MT è facile) che generi una serie di casi di test in diversi intervalli di tempo e parametri e poi istruzioni facili da seguire per la convalida incrociata. Non mi interessa se si tratta di 20000 test da eseguire in un'ora, a meno che non sia semi-automatico.

Potrebbe essere una funzione sqcli per un rapido autocontrollo?

Addendum: gli snippet incorporati (e indirettamente quelli dell'utente) hanno già definizioni di metadati (intervalli, tipo, ecc.). Si è mai pensato di estendere un po' questo sistema e di generare automaticamente degli insiemi di test?

Enyx

Da quando ho esportato il codice del mio indicatore personalizzato, ho testato l'indicatore MT5 SqADX con parametri di input variabili utilizzando tutti i dati disponibili in MQ (77MB testset).

Il tasso di superamento del test di successo è 41%. È un problema di arrotondamento.

Enyx