Errori, bug, domande - pagina 3129

Nuovo commento
 
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. Hanno lottato per molti anni e ora proponete di tornare al secolo precedente...

Stranamente, ma con a=true non solo a || ma anche a && non c'è nessun controllo del resto. Altrimenti come si spiega questo (non cercare il significato nel funzionamento dell'indicatore, stiamo parlando del codice qui):

#property indicator_chart_window
#property indicator_buffers 1
#property indicator_plots   1
#property indicator_type1   DRAW_ARROW
#property indicator_color1  Gray
#property indicator_label1  "Fractal Up"
//--- indicator buffers
double ExtUpperBuffer[];
//--- 10 pixels upper from high price
int    ExtArrowShift=-10;

void OnInit()
  {
//--- indicator buffers mapping
   SetIndexBuffer(0,ExtUpperBuffer,INDICATOR_DATA);
   IndicatorSetInteger(INDICATOR_DIGITS,_Digits);
//--- sets first bar from what index will be drawn
   PlotIndexSetInteger(0,PLOT_ARROW,217);
//--- arrow shifts when drawing
   PlotIndexSetInteger(0,PLOT_ARROW_SHIFT,ExtArrowShift);
//--- sets drawing line empty value--
   PlotIndexSetDouble(0,PLOT_EMPTY_VALUE,EMPTY_VALUE);
  }

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   if(rates_total<5)
      return(0);

   int start;
//--- clean up arrays
   if(prev_calculated<7)
     {
      start=2;
      ArrayInitialize(ExtUpperBuffer,EMPTY_VALUE);
     }
   else
      start=rates_total-5;

   for(int i=start; i<rates_total-3 && !IsStopped(); i++)
     {
      //--- Upper Fractal
      if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>high[i+3] && high[i]>high[i+4])
         ExtUpperBuffer[i]=high[i];
      else
         ExtUpperBuffer[i]=EMPTY_VALUE;
     }

   return(rates_total);
  }

Il terminale è silenzioso. Ma se si cambia

if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>high[i+3] && high[i]>high[i+4])

a

if(high[i]>high[i+4] && high[i]>high[i+2] && high[i]>high[i+3] && high[i]>high[i+1])

il programmatore lo cambia e appare il famigerato messaggio 'array out of range' perché il programmatore si imbatte immediatamente in un array con un indice eccessivo a differenza del primo caso.

 
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?


In quale lingua la sintassi è diversa? "Sintassi significa letteralmente non solo comporre, ma anche disporre...".

Se volete controllare se c'è un 'array out of range', cambiate l'ordine.

if(Array[over_index]>val && a) {...}
 
Lilita Bogachkova #:

In quale lingua la sintassi è diversa?"Sintassi significa letteralmente non solo comporre, ma anche ordinare...".

Se volete controllare se c'è un 'array out of range', cambiate l'ordine.

L'ordinazione è auspicabile in quanto è necessario controllare.

Per esempio, se 'a' viene cambiato più spesso, è meglio metterlo come primo argomento.

 
Vitaly Muzichenko #:

L'ordine è auspicabile in quanto i controlli sono necessari.

Per esempio, se "a" cambia più spesso, è meglio metterlo come primo argomento.

No, la prima dipende dalle condizioni principali, le altre sono solo condizioni aggiuntive.

Per esempio, è irrilevante controllare l'ora del tempo di lavoro corrente se il tempo di lavoro non è ancora iniziato.
 

In effetti, mi sono imbattuto in questa funzione per caso. Non è quello che volevo...

if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>high[i+3] && ... && high[i]>high[i+n])

o

if(high[i]>high[i+1])
   if(high[i]>high[i+2])
      if(high[i]>high[i+3])
         if(...)
            if(high[i]>high[i+n])

Il problema è che n può essere abbastanza grande, quindi volevo avvolgere questa lunga catena di condizioni in una compatta per. Ho provato in questo modo:

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

ma si è rivelato un po' un casino. Beh, almeno perché h_plus con questo algoritmo dovrà prendere l'intera somma delle condizioni controllate, compresa la condizione con il controllo ridondante dell'array di indici, cosa che non accadeva nel primo if non avvolto, senza for. E altre vernici rovinano l'immagine.

Vale la pena prenderlo in considerazione? È possibile farlo?

 
Lilita Bogachkova #:

In quale lingua la sintassi è diversa? "Sintassi significa letteralmente non solo comporre, ma anche ordinare...".

Se volete controllare se c'è un 'array out of range', cambiate l'ordine.

Non sempre si sa in anticipo cosa mettere prima e cosa dopo.

 
Lilita Bogachkova #:

No, la prima determina le condizioni di base, le altre sono solo condizioni aggiuntive.

Per esempio, è irrilevante controllare l'ora del tempo di lavoro corrente se il tempo di lavoro non è ancora iniziato.

Sì, prima controlliamo le condizioni del segnale, passiamo attraverso l'array e confrontiamo, controlliamo il prezzo corrente, e poi si scopre che il tempo non è giusto, ma prima di questo vengono eseguite un sacco di azioni complicate.

Giusto?

 
Vitaly Muzichenko #:

Sì, prima controlliamo le condizioni del segnale, passiamo attraverso l'array e confrontiamo, controlliamo il prezzo corrente, e poi si scopre che il tempo non è giusto, ma un sacco di azioni complicate sono state fatte prima di questo.

Giusto?

Giusto, non dovresti farlo.
 
Vitaly Muzichenko #:

Controlla

Chi vi ha detto che "a" della condizione di cui sopra sarebbe sempre falso?

 
x572intraday #:

In effetti, mi sono imbattuto in questa funzione per caso. Non è quello che volevo...

o

Il problema è che n può essere abbastanza grande, quindi volevo avvolgere questa lunga catena di condizioni in una compatta per. Ho provato in questo modo:

ma si è rivelato un po' un casino. Beh, almeno perché h_plus con questo algoritmo dovrà prendere l'intera somma delle condizioni controllate, compresa la condizione con il controllo ridondante dell'array di indici, cosa che non accadeva nel primo if non avvolto, senza for. E altre vernici rovinano l'immagine.

Vale la pena prenderlo in considerazione? E' possibile sovraccaricarsi di lavoro?

Ecco questo codice che non capisco affatto

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

Cosa significa la scritta & in questo codice? E in quale ciclo if(h_plus) dovrebbe essere eseguito? Non hai perso qualche staffa curva?

1...312231233124312531263127312831293130313131323133313431353136...3184
Nuovo commento