Tutte le domande dei nuovi arrivati su MQL4 e MQL5, aiuto e discussione su algoritmi e codici - pagina 1857
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
raccogliere (o ricordare/conoscere) tutto, ordinare per tempo aperto. Questo è quanto, ma il tempo aperto non cambia :-)
Se la logica EA contiene più di 1 ordine (per esempio griglia), allora dovrai ricordarli tutti. O dovrete rallentare cercando di ricordarli tutti ad ogni starnuto
Potete dirmi se il profitto nella storia è cerchiato in blu, questo include la commissione e lo swap?
Si ottengono l'ora e il prezzo dell'ordine da selezionare con la funzione OrderSelect().
Per quanto ne so, non c'è alcuna menzione di questo nella documentazione. Quindi è meglio andare sul sicuro. Non peggiorerà le cose.
Ci sono state lamentele sul fatto che questa procedura richiede molto tempo alla CPU.
Per quanto riguarda SL e TP, sono calcolati. E quindi devono assolutamente essere normalizzati secondo il valore delle cifre.
Qui, in ogni caso, è necessario scoprire l'intenzione dell'autore.
Ci sono state lamentele sul fatto che questa procedura richiede molto tempo alla CPU.
La normalizzazione degli SL e degli AT calcolati richiede il doppio del tempo. Ma non direi che ha un grande impatto sull'ottimizzazione e ancor meno sul test dei robot.
La documentazione dice nero su bianco di normalizzare i livelli calcolati! E quale potrebbe essere "l'intento dell'autore"? Cosa non è normalizzare SL e TP? Non ho intenzione di discutere con te perché i fatti sono evidenti qui!
Se si tratta di una domanda, allora prendi il biglietto del primo, seleziona il primo e i successivi che hanno il biglietto !=primo.
Ci vuole il doppio del tempo per normalizzare gli SL e gli AT calcolati. Ma non direi che ha un grande impatto sull'ottimizzazione e ancor meno sul test dei robot.
Lo fa, e ci sono state domande su questo forum sulla semplificazione di questa procedura.
Non conosco un caso in cui i prezzi ricevuti non normalizzati abbiano causato un errore.
Per riferimento:
E quale potrebbe essere "l'intenzione dell'autore" in questo caso? Che non per normalizzare SL e TP? Non ho intenzione di discutere con te perché i fatti sono evidenti!
Un ripensamento potrebbe essere l'arrotondamento. In teoria questo non viene fatto, ma in questo modo nel caso di arrotondamento a meno cifre , nel caso i prezzi saranno corretti per SL e TP, funzionerà. Quindi bisogna scoprire cosa si intende in ogni caso.
Ho provato a risolverlo da solo, aggiungendo approssimativamente il codice di questo indicatore, ma non funziona. Anche se si compila e non ci sono errori.
Forse dovremmo usare iCustom e gestire l'indicatore?
Se cerchi di identificare il problema e poi descrivi in modo più dettagliato cos'è esattamente che non puoi fare, allora la probabilità di ottenere una risposta sarà molto più alta.
Ci vuole il doppio del tempo per normalizzare gli SL e gli AT calcolati. Ma non direi che ha un grande impatto sull'ottimizzazione, per non parlare dei test sui robot.
Non solo, ma alcune persone trascurano controlli semplici come
pensando che possa consumare molto tempo di CPU :)
Ma in realtà sono funzioni come ObjectCreate e ObjectDelete che consumano il tempo del processore. Se un programmatore ha, per esempio, un array di oggetti grafici e questo viene cancellato e ricreato ad ogni tick, bisogna fare qualcosa. Mentre i semplici controlli e calcoli sono di poco tempo. Questo è il motivo per cui molti programmatori stanno cercando nel posto sbagliato.
Lo fa, e ci sono state domande su questo forum sulla semplificazione di questa procedura.
Non so chi colpisca o cosa colpisca. Non ho mai avuto problemi con NormaizeDouble. Semmai, qualsiasi codice influisce sulla velocità di un'applicazione. Ma se tutto è così critico, potete lasciare i gestori OnTick o OnCalculate vuoti. In questo caso la vostra applicazione non volerà affatto. :) Oppure riscrivere le funzioni in assembler, compilare in DLL e collegarle all'applicazione.
Non conosco casi in cui i prezzi ricevuti e non normalizzati hanno causato un errore.
Ma la documentazione sì! E ignorate i consigli della documentazione. Fai come vuoi. Sono affari suoi. Penso che sia ovvio e non ho intenzione di discutere con voi su questo, lo dirò di nuovo!
L'arrotondamento può essere un ripensamento.
Non è l'arrotondamento, è il taglio di tutto ciò che supera le due cifre decimali.
Non conosco nemmeno l'idea dell'autore. Ma non ne ho bisogno. Penso che possa capirlo da solo.