Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Domanda per gli sviluppatori:
Perché nel tester non è possibile ottenere il campo della struttura
MqlTradeResultprice;// Prezzo in un trade, confermato dal broker? Dà 0.
Funziona bene sulla demo.
C'è qualche relazione tra la struttura della lista di timeframes e i flag di visibilità degli oggetti (perché anche la lunghezza delle liste è diversa: 22 vs 23)? In generale, lo chiedo per assegnare in modo efficiente e compatto la visibilità degli oggetti sui tempi in un ciclo con dei confini dati, piuttosto che elencare e riassumere le bandiere manualmente. Quale logica usare se un timeframe arbitrario è preso a caso, un oggetto grafico è costruito su di esso e deve essere permesso di essere visibile su tutti i timeframe non più vecchi di quello corrente (cioè quello su cui è stato costruito)? L'algoritmo dovrebbe essere universale, non per un caso particolare. La correlazione dell'indice è già fregata, non c'è nemmeno una corrispondenza dell'indice. L'analisi delle stringhe di nomi e il confronto è di nuovo un fallimento a causa dell'impossibilità di gestire le stringhe in caso di costanti di visibilità. Finora, mi viene in mente un'implementazione complicata, vaga e molto storta.
La relazione ovviamente c'è, ma è così implicita che l'unico modo per scrivere <visibility_flag> = F(<timeframe>):
x100intraday:
Quale logica usare se prendiamo a caso un timeframe arbitrario, costruiamo un oggetto grafico su di esso e dobbiamo permettere la sua visibilità su tutti i timeframe non più vecchi di quello attuale (cioè quello su cui è stato costruito)?
se non è una pedina)
Considerare TF[i], impostare Visibilità[i]...
o visibilità=(int)(MathPow(2,i+1)-1);
Se ne hai bisogno, allora non è una scacchiera)
Considerare TF[i], impostare Visibilità[i]...
o visibilità=(int)(MathPow(2,i+1)-1);
Grazie per la formula Visibility - forse la adatterò. Era ovvio dai valori sui timeframe, che è un grado di qualcosa, ma non ho provato a ricostruire la formula da solo.
Il -1 è necessario? In generale, Visibility[] sembra essere riempito con valori errati, infatti dovrebbe essere ovunque senza -1, cioè: 1, 2, 4, 8, 16...
Naturalmente c'è una relazione, ma è così implicita che l'unico modo per scrivere <visibility_flag>=F(<timeframe>) è fare così:
Grazie, elegante. Questo è esattamente quello che stavo cercando di fare, tranne che per lo spostamento stesso, che è esattamente quello che mi mancava.
E alla fine ho effettivamente affrontato la questione di calcolare i valori delle bandiere su ogni giro del ciclo di regressione su un array di _p_int timeframes (alla fine qualcosa dovrà essere aggiunto nelle bandiere), non solo su quello corrente. Beh, spostando il valore del flag di visibilità al timeframe corrente, e poi ad ogni rotazione di i-- qualcosa dovrebbe cambiare da qualche parte... O vi si applica la formula di esponenziazione o si usa lo stesso principio di spostamento. Non ho ancora capito come...
... Anche se sì, è una funzione con TF-argomento - proverò a mandarla in loop...
Tuttavia, è di nuovo sbagliato. Lasciatemi spiegare. Nell'esempio, c'è ENUM_TIMEFRAMES statico _p_int[] per 21 elementi, ma ecco cosa voglio: ho già un tale array, ma può essere di qualsiasi lunghezza. Si tratta di un array che contiene i timeframe, sui quali verrà costruito qualcosa. Ma dovrebbero essere visibili anche su tutti i timeframe inferiori e nessuno degli array viene riempito con essi separatamente o in aggiunta a quelli esistenti. Quindi qui sto menzionando la necessità di calcolare le bandiere del timeframe corrente e di tutti i timeframe inferiori e sommarle nel ciclo di regressione al volo, ballando dal timeframe corrente. Il trucco non è quello di creare un array completo di valori preimpostati di qualsiasi cosa (anche di timeframes o flag di visibilità) e giocherellare con loro, ma di calcolare nella mia mente per ogni turno solo l'array incompleto di timeframes preimpostati.
Vado per un po' e se mi blocco, chiedo.
Perché non ho fretta di usare (int)(MathPow(2,i+1)-1) o ((int)1)<<i... Se i è lì, potete facilmente sostituirlo in un ciclo ed eseguire... Ma, proprio come nel caso della moltiplicazione e dello spostamento - è sempre sicuro? Supponiamo che gli sviluppatori aggiungano mai nuovi timeframes, l'intera logica non andrà fuori strada? Subito dopo - nell'esempio con uno spostamento ci aspettiamo che il periodo corrente coincida con quello preimpostato:
if(period==_p_int[i])
quindi anche se nel caso reale alcuni tempi della sequenza teoricamente completa vengono omessi o questa sequenza viene estesa dagli sviluppatori, la logica non dovrebbe strisciare. Ma se ci affidiamo alla matematica pura e ci limitiamo ad eseguire il ciclo con la formula da un confine all'altro, senza considerare l'eventuale assenza o presenza di nuove scadenze, allora prima o poi, nella prossima build, verremmo sballati...Perché non ho fretta di usare (int)(MathPow(2,i+1)-1) o ((int)1)<<i... Dato che i è lì, potete facilmente sostituirlo in un ciclo ed eseguire... Ma, proprio come nel caso della moltiplicazione e dello spostamento - sarà sempre sicuro? Supponiamo che gli sviluppatori aggiungano mai nuovi timeframes, l'intera logica non andrà fuori strada? Così su due piedi - nell'esempio con uno spostamento, ci aspettiamo che il periodo corrente sia lo stesso di quello preimpostato:
quindi anche se nel caso reale alcuni tempi della sequenza teoricamente completa vengono omessi o questa sequenza viene estesa dagli sviluppatori, la logica non dovrebbe insinuarsi. Ma se ci affidiamo alla pura matematica e facciamo semplicemente scorrere il ciclo con la formula da un confine all'altro, senza prestare attenzione alla possibile assenza o presenza di nuovi tempi, allora prima o poi, nella prossima build, otterremmo uno skew...Le nostre preoccupazioni sono molto ragionevoli. Il codice qui sopra giustifica il fatto che il flag di visibilità impostato è in realtà una macro.
Sarebbe più corretto lavorare attraverso:
Grazie per la formula di visibilità - forse la adatterò. Ho potuto vedere dai valori sui timeframe che era un grado di qualcosa, ma non ho provato a ricostruire la formula da solo.
Il -1 è davvero necessario? In realtà, Visibility[] sembra essere compilato in modo errato, infatti, dovrebbe essere ovunque senza -1, cioè 1, 2, 4, 8, 16...
1,2,4 ecc. - visibilità dell'oggetto in un periodo di tempo. =MathPow(2,i);
su 1 corrente e più piccolo, 1+2, 1+2+4, 1+2+4+8 ecc., taki =MathPow(2,i+1)-1;
È più chiaro nel codice binario.
Le perplessità sono molto ragionevoli. Il codice di cui sopra giustifica solo il fatto che l'insieme dei flag di visibilità è in realtà una macro.
Il modo corretto è quello di lavorare attraverso di essa:
La stessa cosa in linea di principio. Se cambiate nella lista degli af, dovrete modificare il codice.
Non riesco a immaginare nessuna soluzione universale, e sospetto che sia teoricamente impossibile prevedere i possibili cambiamenti.
x100intraday:
Sbagliato di nuovo, però. Lasciatemi spiegare. Nell'esempio, viene creato un ENUM_TIMEFRAMES statico _p_int[] per 21 elementi, ma ecco cosa voglio: ho già un tale array, ma può essere di qualsiasi lunghezza. Si tratta di un array che contiene i timeframes, sui quali verrà costruito qualcosa. Ma dovrebbero essere visibili anche su tutti i timeframes inferiori e nessuno degli array viene riempito con essi separatamente o in aggiunta a quelli esistenti. Quindi qui sto menzionando la necessità di calcolare le bandiere del timeframe corrente e di tutti i timeframe inferiori e sommarle nel ciclo di regressione al volo, ballando dal timeframe corrente. Il trucco non è quello di creare un array completo di valori preimpostati di qualsiasi cosa (anche di timeframes o flag di visibilità) e fare un loop attraverso di essi, ma di calcolare a mente ad ogni turno solo l'array incompleto di timeframes preimpostati.
No, non lo farai. La corrispondenza tra tempi e visibilità deve essere definita. O due array corrispondenti, o un interruttore.
+array con i TF di cui hai bisogno, +init calcola la visibilità dell'oggetto per ogni TF che usi. Qualcosa del genere...)
Non riesco a capire cosa c'è che non va.
2011.12.29 01:16:07 Core 1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54507 VirtualSL = 1.53378
2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
Mi sono scervellato, non capisco cosa c'è che non va?
È un errore dell'ottimizzatore del compilatore. Grazie per il tuo messaggio, lo sistemeremo.
L'errore si verifica con la seguente costruzione
VirtualSL!=0.0 può essere rimosso dalla seconda parte della prima condizione if,poiché questa espressione è sempre vera dopo che la prima parte è stata controllata. L'errore dell'ottimizzatore scomparirà.Corretto, la correzione sarà inclusa nella prossima build.