Errori, bug, domande - pagina 3131

Nuovo commento
 
x572intraday #:

Posso solo rispondere per &= immediatamente:

Guida di riferimento MQL5 / Fondamenti del linguaggio / Operazioni ed espressioni / Operazioni di assegnazione:

In analogia con la variabile cumulativa y:


Ma questa è la mia prima esperienza con &=, quindi potrei sbagliarmi.

In primo luogo, tutte le condizioni logiche sono sommate in h_plus accumulativo all'interno di for e la somma bool risultante è inserita in if che non ha nulla a che fare con for interno.
Ma comunque, sarebbe più corretto non 
h_plus&=high[i]>high[i+increment];
ma 
h_plus = h_plus && high[i]>high[i+increment];
 
Alexey Viktorov #:

Nel vostro caso non è così, poiché entrambe le condizioni devono essere soddisfatte. Ma se metti questo

allora, sì. Se la condizione "a" è soddisfatta, la seconda condizione non sarà controllata. Questo è stato combattuto per anni, e ora stai suggerendo di tornare al secolo scorso...

Anche se... mi sbaglio in questa mia affermazione. A quanto pare non ho capito bene quello che è scritto qui.

x572intraday #:

Non oso chiamarlo un bug. Per questo dirò semplicemente che ho notato una particolarità dell'operatore if. Sospetto che possa essere rilevante anche per altre lingue scritte.

Se a risulta essere vero, il controllo salta a Array[over_index] e qui il terminale inizia a sbattere con la parte'array out of range', che è abbastanza vera. Ma se a risulta essere falso, il terminale non controllerà la condizione Array[over_index] e quindi la ridondanza dell'indice, e se salterà ulteriormente e il codificatore non saprà che c'è un array con un indice inesistente nel suo programma... o piuttosto uno esistente ma ridondante.

Forse ci dovrebbe essere una correzione per questo in modo che il controllo per 'array out of range' venga effettuato fino alla fine del ciclo if e venga emesso lo stesso messaggio? O ridurrà significativamente la velocità dell'operatore?

Anche se la condizione && e la prima condizione non sono soddisfatte, la seconda non sarà controllata. Quindi, scusatemi se ho fuorviato qualcuno...

 
x572intraday #:

Ho già provato sia la rottura che il ritorno in fretta e furia, ma ha solo peggiorato le cose. Cercherò di semplificare ancora un po' il codice e di ripensarlo con la pausa...

for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus =  high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Come questo.

 

Quando si ridimensiona il grafico muovendo il mouse lungo la linea temporale, il grafico scorre a sinistra o a destra, a seconda della direzione del mouse, così che tutto ciò che è al centro dell'attenzione dell'utente spesso scompare oltre i confini del grafico. Questo è terribilmente scomodo, perché poi devi cercare il posto giusto, e questo è stato il caso da quando ho familiarità con MT.

Era logico supporre che forse cliccando sull'icona della lente d'ingrandimento il grafico sarebbe stato ridimensionato al centro, ma no, il comportamento è lo stesso del ridimensionamento del mouse - il grafico si sposta a sinistra (compressione) o a destra (espansione).

Cari sviluppatori! Vi chiediamo seriamente di cambiare il comportamento in scala del grafico, è necessario lasciare il centro del grafico al centro.

Tutti quelli con cui ho discusso di questo inconveniente di lavorare con il grafico sono d'accordo con me, quindi ho una buona possibilità di essere obiettivo su questo problema.

Ho cercato di abituarmi per 14 anni - non ci sono riuscito.

 
JRandomTrader #:
for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus = high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

È qualcosa del genere.

Un'idea fresca, la proverò.

Per quanto riguarda l'opzione precedente:

for(int i=start; i<rates_total-3 && !IsStopped(); i++)
{
   bool h_plus=true; //false?
   for(int increment=1; increment<=n; increment++)
     {
      h_plus&=high[i]>high[i+increment];
      if(!h_plus)break;
     }
   if(h_plus) {...}
   ...
}

senza nemmeno provarlo, è già chiaro che

if(!h_plus)break;

è dopo la somma, il che significa che il terminale vedrà prima la linea precedente e capirà che c'è un array con un indice eccessivo e darà lo stesso messaggio'array out of range'. Questa è la seconda cosa. E la prima è che dovremmo controllare non per !h_plus ma per ArraySize(high)<=i+increment e uscire dal ciclo nel caso in cui l'indice sia superato. Ho provato tutto questo ieri, ma ho fallito in alcune sottigliezze. Sì, non c'era nessun messaggio, ma anche l'indicatore ha iniziato a fare confusione.

 
x572intraday #:

Per quanto riguarda l'opzione precedente:

senza nemmeno provarlo, è già chiaro che

è dopo la somma, il che significa che il terminale vedrà prima la linea precedente e capirà che c'è un array con un indice eccessivo e darà lo stesso messaggio'array out of range'. Questa è la seconda cosa. Il primo è che dovremmo controllare non per !h_plus ma per ArraySize(high)<=i+increment e uscire dal ciclo nel caso in cui l'indice sia superato. Ho provato tutto questo ieri, ma ho fallito in alcune sottigliezze. Sì, il messaggero se n'era andato, ma anche l'indicatore ha cominciato a fare un casino.

Quindi il problema qui è

i<rates_total-3
Ho scritto 
i<rates_total-n
per una ragione, e l'uscita anticipata dal ciclo è precisamente per simulare il calcolo if()
 
x572intraday #:

Non oso chiamarlo un bug. Quindi dirò solo che ho notato una particolarità dell'istruzione if. Sospetto che questo possa valere anche per altre lingue.

Se a risulta essere vero, il controllo salta a Array[over_index] e qui il terminale inizia a sbattere con la parte'array out of range', che è abbastanza vera. Ma se a risulta essere falso, il terminale non controllerà la condizione Array[over_index] e quindi la ridondanza dell'indice, e se salterà ulteriormente e il codificatore non saprà che c'è un array con un indice inesistente nel suo programma... o piuttosto uno esistente ma ridondante.

Forse ci dovrebbe essere una correzione per questo in modo che il controllo per 'array out of range' venga effettuato fino alla fine del ciclo if e venga emesso lo stesso messaggio? O ridurrà significativamente la velocità dell'operatore?


Se impostate la variabile a su false, il controllo viene passato e non influenza l'array o il codice tra parentesi dopo if, perché nel vostro caso

if(a && Array[over_index]>val) {...}

il controllo sarà passato alla parte destra della condizione solo se la parte sinistra (a) è vera

se, per esempio, fate

if(check(over_index) && Array[over_index]>val) {...}

dove la funzione check controlla l'array Array, non otterrete mai"array out of range". Quindi, potete controllare l'indice dell'array e indirizzarlo in un if. Ma passare il controllo alla seconda parte dell'if con l'operatore &&, se la prima parte è falsa, difficilmente è possibile in qualsiasi linguaggio di programmazione esistente...

 

C'è un problema, appare casualmente e occasionalmente.

Appare quando si lavora nel tester con diverse valute.

In ogni ciclo richiedo prezzi reali per i simboli. Se per qualche motivo il tester non riceve le quotazioni per un particolare simbolo, usa le quotazioni ottenute in precedenza per un altro simbolo.

Dovrei aprire una posizione se il prezzo è superiore a quello specificato. Dovrei aprire la posizione se ho ricevuto dati sbagliati da un altro simbolo.

Il simbolo EURCAD si apre se il prezzo è superiore a 1,45117. 1.74425>1.45117? Sì, è più alto ma è il prezzo di un altro simbolo.

Abbiamo rilevato 7 ordini errati su 500.

 
Yury Lemeshev #:

C'è un problema, appare casualmente e occasionalmente.

Appare quando si lavora nel tester con diverse valute.

In ogni ciclo richiedo prezzi reali per i simboli. Se per qualche motivo il tester non riceve le quotazioni per un particolare simbolo, usa le quotazioni ottenute in precedenza per un altro simbolo.

Dovrei aprire una posizione se il prezzo è superiore a quello specificato. Sto usando dati sbagliati di un altro simbolo per l'apertura.

Simbolo EURCAD se il prezzo è sopra 1,45117 allora si apre. 1.74425>1.45117? Sì, è più alto ma è il prezzo di un altro simbolo.

Abbiamo rilevato 7 ordini di errore su 500.

Il problema è nel codice, ma i telepati stanno già festeggiando e quando usciranno dal loro sonno, diranno che l'errore è nella linea 123652

 
Alexey Viktorov #:

Problemi nel codice, ma i telepati stanno già festeggiando, e quando usciranno dalla loro abbuffata, diranno che l'errore è nella linea 123652

Non c'è nessun errore nel codice, il codice è stato riscritto per eliminare l'errore, e l'errore non appare regolarmente, è completamente caotico

1...312431253126312731283129313031313132313331343135313631373138...3184
Nuovo commento