Errori, bug, domande - pagina 3121

 
x572intraday #:
Se lo sai, per favore dimmelo. Se si carica una nuova versione di un codice esistente su CodeBase, il divieto di votare di nuovo sarà resettato per gli sviluppatori precedenti e potranno votare di nuovo per la nuova versione? Io stesso ne dubito fortemente, ma se fosse possibile sarebbe giusto azzerare la valutazione precedente al posto di quella nuova (che ipoteticamente non dovrebbe essere inferiore alla precedente), poiché il codice si sta sviluppando e la nuova versione potrebbe soddisfare maggiormente il votante, mentre la vecchia valutazione per il vecchio codice diventerebbe non valida. (È vero, man mano che la funzionalità cresce anche il codice cresce, quindi ci possono essere nuovi bug e glitch, ancora più fastidiosi. Tutto può succedere... e il nuovo voto potrebbe essere più basso, ma questo mi va bene).

Smettila di strapparti i capelli per la bassa valutazione dei tuoi ...codici. Se una persona dà al vostro codice un punteggio di 1, non significa che sia quello che è. Bene, rifallo almeno 100 volte... e tutte e 100 le volte questo codice sarà valutato così. È così difficile da capire?

 
Alexey Viktorov #:

Smettila di strapparti i capelli per la bassa valutazione dei tuoi ...codici. Se una persona dà al vostro codice un punteggio di 1, non significa che sia quello che è. Bene, rifallo almeno 100 volte... e tutte e 100 le volte questo codice sarà valutato così. È così difficile da capire?

Forse il suo curriculum riflette la realtà del voto e questo è triste. Ma non sono triste per me stesso - quelle stelle virtuali non possono essere bevute con il tè e messe nel mio portafoglio, sono frustrato dal concetto del modo in cui i prodotti sono presentati ai nuovi utenti, preoccupandomi di loro in particolare. Se non c'è una valutazione credibile, gli utenti semplicemente non saranno in grado di cercare efficacemente il prodotto che vogliono in base al criterio "ordina per valutazione". Si scopre che il sistema di valutazione è un sistema vuoto e si rimane alla ricerca del prodotto giusto per nome/descrizione piuttosto che fidarsi dell'inutile numero di stelle. Altrimenti continueranno a pescare roba... quello che galleggia in superficie (meritatamente o no) e quello di cui hanno veramente bisogno sarà trascurato. Stavo solo suggerendo che questo dovrebbe essere cambiato per essere più riflessivo. Ma se nessuno ha intenzione di combattere questa realtà, me ne lavo le mani.

 
x572intraday #:

Il tuo riassunto può riflettere la realtà del voto, e questo è deludente. Ma non è per me che sono triste - quelle stelle virtuali non possono essere bevute con il tè e messe nel mio portafoglio, sono deluso dal concetto del modo in cui i prodotti vengono presentati ai nuovi utenti, preoccupandosi proprio di loro. Se non c'è una valutazione credibile, gli utenti semplicemente non saranno in grado di cercare efficacemente il prodotto che vogliono in base al criterio "ordina per valutazione". Si scopre che il sistema di valutazione è un sistema vuoto e si rimane alla ricerca del prodotto giusto per nome/descrizione piuttosto che fidarsi dell'inutile numero di stelle. Altrimenti continueranno a pescare roba... quello che galleggia in superficie (meritatamente o no) e quello di cui hanno veramente bisogno sarà trascurato. Stavo solo suggerendo che questo dovrebbe essere cambiato per essere più riflessivo. Ma se nessuno ha intenzione di combattere questa realtà, me ne lavo le mani.

Diamo un'occhiata al tuo codice.

   int calculated=iBars(_Symbol,PArray[0]);

   if(calculated<=0)
      return(0);

   if(!GlobalVariableGet(_Symbol+": PSR_bars_calculated") || calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated") ||
      calculated>GlobalVariableGet(_Symbol+": PSR_bars_calculated")+1)
   {
      if(!GlobalVariableGet(_Symbol+": PSR_SingleActuation") || (GlobalVariableGet(_Symbol+": PSR_SingleActuation") &&
         calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated")))
      {
         for(int p=0; p<ArraySize(PArray); p++)
         {

Ogni tick innesca l'accesso alle variabili globali, 4 richieste alla volta.

Ne consegue che NON potete usare questo codice sulla vostra macchina personale, potete usarlo da qualche altra parte, dove non risparmiate il vostro disco rigido.

In loop in un ciclo durante la ricerca 3 volte ArraySize dovrebbe essere chiamato , mentre ce ne sono due, questo è un carico aggiuntivo sul processore, questo è anche indesiderabile, le prestazioni del codice diminuiscono.

DeInite cancella gli oggetti in modo strano, non c'è niente di sbagliato qui, ma è un cattivo esempio per i principianti, se lo fai normalmente, dovresti inserire un prefisso quando crei gli oggetti ecancellarli senza eccessivi ricalcoli.

Do 2 punti per il tuo codice.

Per il lavoro dell'indicatore - non lo so, non l'ho eseguito.

Obiettivo?

 
Vitaly Muzichenko #:

Bene, diamo un'occhiata al tuo codice.

Ad ogni tick viene attivato l'accesso alle variabili globali, 4 richieste alla volta

Ne consegue che NON potete usare questo codice sulla vostra macchina personale, potete usarlo da qualche altra parte, dove non risparmiate il vostro disco rigido.

In loop in un ciclo durante la ricerca 3 volte ArraySize dovrebbe essere chiamato , mentre ce ne sono due, questo è un carico aggiuntivo sul processore, questo è anche indesiderabile, le prestazioni del codice diminuiscono.

DeInite cancella gli oggetti in modo strano, non c'è niente di sbagliato qui, ma è un cattivo esempio per i principianti, se lo fai normalmente, dovresti inserire un prefisso quando crei gli oggetti ecancellarli senza eccessivi ricalcoli.

Do 2 punti per il tuo codice.

Per il lavoro dell'indicatore - non lo so, non l'ho eseguito.

Obiettivo?

1. Ad ogni tick c'è una chiamata al GP, quindi ad ogni tick, e anche ad ogni reinizializzazione (per esempio, transizioni attraverso i TF) il codice principale e più pesante inOnCalculate() non viene eseguito, e l'indicatore lavora più velocemente. Il calcolo di nuovi dati - solo con la comparsa di una nuova barra bassa D1, che è molto più raro, che su ogni tick.

2. Ho lavorato attentamente e accuratamente sul codice, ma ho lasciato alcune operazioni di confronto ridondanti in if() perché so per certo che non influenzerà le prestazioni.

3. Circa il MUST non essere, è molto esagerato. Potete scaricarlo e vedere voi stessi: l'indicatore vola.

4. Non sapevo che i GP sono scaricati nell'AF e poi letti dalla stessa posizione ogni volta che si accede in una sessione MT5 in corso. Penso ancora che siano letti dall'LCD alla RAM una volta quando avvio il terminale e ci vivo, e l'indicatore accede ad essi nella RAM, non all'LCD.

5. Non credo che ArraySize() sia una funzione costosa. E anche se è costoso, non lo noterete in questo particolare codice. Probabilmente ottimizzerei questa funzione nel mio primo indicatore dove è usata abbastanza spesso, mentre l'indicatore stesso è molto più complesso e richiede molte risorse.

6. In OnDeinit() uso:

ObjectsDeleteAll(0,StringSubstr(EnumToString(PArray[p]),7)+" "+line_types[lt]+" l",0,-1);

dove c'è solo la rimozione con il prefisso "l" (i nomi " label" e " line" sono stati utilizzati durante la creazione degli oggetti.

7. Ora avete fatto quello che un utente che ha scaricato e capito il codice dovrebbe fare. Avete trovato i difetti - anche questo fa parte dell'apprendimento del MQL.

8. In conclusione: 1.) il mio argomento principale del codice non ideale di questo indicatore - semplicità, compattezza e velocità... più il lavoro perfetto; 2.) il mio secondo argomento principale del codice imperfetto - mancanza di analoghi anche cattivi in termini di velocità e versatilità (vedere la discussione degli originali altrui) e disponibilità di miglioramenti rispetto all'originale, che, tra l'altro, è stretto e non è piegato in loop compatti in termini di grande numero di blocchi ripetuti in modo simile.

9. Nonostante il punto 7, non hai capito bene il codice di qualcun altro. Il tuo punteggio di 2 è troppo basso. Non vi consiglio ancora di valutare i prodotti software in base al loro codice. Non dirò nulla sull'obiettività perché è impossibile aspettarsi un'obiettività da un singolo utente. Una stima oggettiva (rating) è possibile solo come somma di stime di diversi utenti sani di mente e certamente non deve essere necessariamente alta.

 
x572intraday #:

1. Ad ogni tick c'è un riferimento al GP in modo che ad ogni tick, così come ad ogni reinizializzazione (per esempio, transizioni attraverso TF) l'intero codice principale e più pesante inOnCalculate() non viene eseguito, e l'indicatore lavora più velocemente. Calcolo di nuovi dati - solo con la comparsa di una nuova barra bassa D1, che è molto più rara, che su ogni tick.

2. Ho lavorato attentamente e accuratamente sul codice, ma ho lasciato alcune operazioni di confronto ridondanti in if() perché so per certo che non influenzerà le prestazioni.

3. Circa il MUST - molto esagerato. Potete scaricare e vedere voi stessi che l'indicatore vola.

4. Non sapevo che i GP vengono scaricati sull'HDD e poi letti da lì ogni volta che si accede a una sessione MT5 in corso. Continuo a pensare che vengono letti dall'HD alla RAM una volta quando avvio il terminale e vivono lì, e l'indicatore accede ad essi nella RAM, non all'HD.

5. Non credo che ArraySize() sia una funzione costosa. E anche se è costoso, non lo noterete in questo particolare codice. Probabilmente ottimizzerei questa funzione nel mio primo indicatore dove viene usata abbastanza spesso, mentre l'indicatore stesso è molto più complesso e richiede molte risorse.

6. In OnDeinit() uso:

dove c'è solo la rimozione con il prefisso "l" (i nomi " label" e " line" sono stati utilizzati durante la creazione degli oggetti.

7. Ora avete fatto quello che un utente che ha scaricato e capito il codice dovrebbe fare. Avete trovato i difetti - anche questo fa parte dell'apprendimento del MQL.

8. In conclusione: 1.) il mio argomento principale del codice non ideale di questo indicatore - semplicità, compattezza e velocità... 2.) il mio secondo argomento principale del codice imperfetto - l'assenza di analoghi in termini di velocità e versatilità (vedi la discussione sull'originale di qualcun altro) e la disponibilità di miglioramenti rispetto all'originale, che, tra l'altro, è stretto e non è piegato in loop compatti in termini di grande numero di blocchi ripetuti in modo simile.

9. Nonostante il punto 7, non hai capito bene il codice di qualcun altro. Il tuo punteggio di 2 è troppo basso. Non vi consiglio ancora di valutare i prodotti software in base al loro codice. Non dirò nulla sull'obiettività perché è impossibile aspettarsi un'obiettività da un singolo utente. Una stima oggettiva (rating) è possibile solo come somma delle stime di alcuni utenti sani di mente e non deve essere necessariamente alta.

La cancellazione per prefisso è la seguente: ObjectsDeleteAll(0, "pref_"); // "pref_label" e " pref_line"

Aggiungere almeno la prima linea a OnCalculate per indirizzare su una nuova barra e non su ogni tick come è ora

 
Vitaly Muzichenko #:

Cancellare per prefisso, è così: ObjectsDeleteAll(0, "pref_"); // "pref_label" e " pref_line"

Aggiungete almeno la prima linea a OnCalculate, in modo che il riferimento sia su una nuova barra, e non su ogni tick, come è ora

A proposito, riguardo al punto 7: ho incontrato errori anche nella documentazione di MQL5, che non sono stati corretti per molti anni.

 
Vitaly Muzichenko #:

Cancellare per prefisso è così: ObjectsDeleteAll(0, "pref_"); // "pref_label" e " pref_line"

Cancellarlo nel modo che suggerisci non è ragionevole perché l'inizio del prefisso è dinamico: o{D1}, o {W1}, o{MN1} e poi viene il prefisso immutabile come " l...". Puoi scambiare i prefissi dinamici e statici e rimuoverli in modo sicuro secondo la tua versione. Ma non è ragionevole perché è scomodo prendere informazioni come "R1{D1}", mentre è più conveniente usare "{D1} R1". Ci ho pensato molto tempo fa e ho fatto esattamente come ho fatto.

 
x572intraday #:

Non c'è un modo sensato di cancellarlo come suggerisci tu, perché l'inizio del prefisso è dinamico: o{D1} o {W1} o{MN1}, e poi c'è un prefisso immutabile come " l...". Puoi scambiare i prefissi dinamici e statici e rimuoverli in modo sicuro secondo la tua versione. Ma non è ragionevole perché è scomodo prendere informazioni come "R1{D1}", mentre è più conveniente usare "{D1} R1". Ci ho pensato molto tempo fa e ho fatto esattamente come ho fatto.

DrawTheLine("pref"+line_types[lt], St
 
Vitaly Muzichenko #:

Comunque, sì, in linea di principio si potrebbe fare così. Mi sono spiegato avventatamente sopra, pensando in quel momento a:

ObjectSetString(0,tf+" "+LineType+" label",OBJPROP_TEXT,"{"+tf+"}   "+LineType);

non sui nomi degli oggetti. Il grafico legge esattamente ciò che è impostato conOBJPROP_TEXTper le etichette, ma i nomi degli oggetti possono essere firmati in un modo meno leggibile, perché sono nascosti e raramente letti.

D'altra parte, nella "Lista degli oggetti" (Ctrl+b) è meglio vedere nomi di oggetti leggibili, quindi il mio modo è più preferibile. Inoltre, ci sono casi in cui i nomi degli oggetti devono essere estremamente lunghi, quindi un"pref_" extra sarà completamente inaccettabile.
 
x572intraday #:

Comunque, sì, in linea di principio, si potrebbe fare così. Mi sono spiegato avventatamente sopra, pensando in quel momento a:

non sui nomi degli oggetti. Il grafico legge esattamente ciò che è impostato conOBJPROP_TEXTper le etichette, ma i nomi degli oggetti possono essere firmati meno leggibili, perché sono nascosti e raramente letti.

D'altra parte, nella "Lista degli oggetti" (Ctrl+b) è auspicabile vedere nomi di oggetti leggibili, quindi la mia versione è ancora preferibile. Inoltre, ci sono casi in cui i nomi degli oggetti devono essere estremamente lunghi, quindi un"pref_ " extra sarebbe completamente inaccettabile.

e se qualcuno avrà ancora un programma con oggetti grafici, il vostro tipo di prefisso "l" < dove basta eliminare dal prefisso " l" (i nomi "label" e "line" erano usati quando gli oggetti venivano creati >

Ucciderà tutti gli oggetti che iniziano con"l" in un programma di terze parti. Questa non è una buona soluzione