Errori, bug, domande - pagina 616

[Serj]

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.

[Victor Kirillin]

x100intraday:

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>):

int PeriodToTimeframeFlag(ENUM_TIMEFRAMES period)
  {
   flags=0;
   static ENUM_TIMEFRAMES _p_int[]={PERIOD_M1, PERIOD_M2, PERIOD_M3, PERIOD_M4, PERIOD_M5, PERIOD_M6,
                                    PERIOD_M10,PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,
                                    PERIOD_H1, PERIOD_H2, PERIOD_H3, PERIOD_H4, PERIOD_H6, PERIOD_H8,PERIOD_H12,
                                    PERIOD_D1, PERIOD_W1, PERIOD_MN1};
//--- cycle for all timeframes
   for(int i=0;i<ArraySize(_p_int);i++)
      if(period==_p_int[i])
        {
         //--- at the same time generate the flag of the working timeframe
         flags=((int)1)<<i;
         break;
        }
   return(flags);
  }

[Aleksey Lebedev]

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)

ENUM_TIMEFRAMES TF[21]={PERIOD_M1,PERIOD_M2,PERIOD_M3,PERIOD_M4,PERIOD_M5,PERIOD_M6,PERIOD_M10,
                     PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,PERIOD_H1,PERIOD_H2,PERIOD_H3,
                     PERIOD_H4,PERIOD_H6,PERIOD_H8,PERIOD_H12,PERIOD_D1,PERIOD_W1,PERIOD_MN1};

int Visibility[21]={1,3,7,15,31,63,127,255,511,1023,2047,4095,8191,
            16383,32767,65535,131071,262143,524287,1048575,2097151};

Considerare TF[i], impostare Visibilità[i]...

o visibilità=(int)(MathPow(2,i+1)-1);

[x572intraday]

Swan:

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...

[x572intraday]

uncleVic:

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.

[x572intraday]

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...

[Victor Kirillin]

x100intraday:

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:

int result=0;
//---
switch(period)
  {
   case PERIOD_M1: result=OBJ_PERIOD_M1; break;
   case PERIOD_M2: result=OBJ_PERIOD_M2; break;
   case PERIOD_M3: result=OBJ_PERIOD_M3; break;
   case PERIOD_M4: result=OBJ_PERIOD_M4; break;
   case PERIOD_M5: result=OBJ_PERIOD_M5; break;

//--- и так далее

   default: print("Что-то новенькое");
  }

[Aleksey Lebedev]

x100intraday:

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.

zioVic:

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...)

[Serj]

Non riesco a capire cosa c'è che non va.

double VirtualSL;
MqlTick tick;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
   VirtualSL=0.0;
   return(0);
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
   trail();
  }
//+------------------------------------------------------------------+
void trail()
  {
   double stopcal;

   SymbolInfoTick(_Symbol,tick);
   stopcal=tick.bid;

//   if((VirtualSL!=0.0 && stopcal>VirtualSL) || VirtualSL==0.0) // так все работает

   if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL)) // так не хочет работать
     {
      VirtualSL=stopcal;
      Print("use Ok!");
     }
   if(VirtualSL<stopcal) Print("o_O ((((( stopcal = ",stopcal,"   VirtualSL = ",VirtualSL);
  }
//+------------------------------------------------------------------+

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

[Ilyas]

her.human:

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

if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL))
if(VirtualSL<stopcal)

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.