Il problema del trasferimento da MT4 a MT5. O, più precisamente, l'impossibilità di eseguire alcuni algoritmi in MT5 senza 'err. - pagina 7
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
L'assurdità sta nell'organizzare la propria copia dei dati, che è già disponibile nel terminale.
Ci sono molte di queste sciocchezze. Quando MT4 è stato rilasciato nell'agosto 2005, è apparso l'indicatore ZigZag. Ci sono molti errori. In un caso potrebbe appendere il terminale sul mercato veloce in quel momento. E spesso mostrava gli estremi nell'aria, non legati ai minimi/massimi delle barre.
In un post lo sviluppatore di questo zigzag ha detto che questo - (per favore non prendete altre emozioni) è una manifestazione della logica fuzzy........
Ma fino ad oggi, sono passati 14 anni dal lancio di MT4, nell'indicatore dello zigzag c'è un parametro - Deviation - che non produce alcuna azione. Cioè, non importa quale valore di questo parametro imposti, il disegno dello zigzag sul grafico non cambierà.
Molti programmi si basano su questo indicatore. La maggior parte degli sviluppatori include questo parametro nei loro programmi. È un parametro inutile. Gli sviluppatori mostrano una fantastica indifferenza nei suoi confronti. Questo parametro, tra l'altro, mangia le risorse del computer.
Ci sono stati molti momenti simili in varie altre occasioni.
Continuerò.
Quegli estremi a zig zag sospesi nell'aria sono esattamente della stessa natura di quelli che abbiamo quando accediamo alle serie temporali.
È solo che l'accesso alle serie temporali non è stato negato in MT4. Alcune funzioni non funzionavano correttamente lì (forse lo fanno ancora adesso). Avevo una spiegazione per il mio uso interno. Ne ho anche fatto uno forzato per conto mio. E tutto ha cominciato a funzionare senza errori, senza carico della CPU. Anche l'uscita di diverse decine di zigzag sui grafici non ha causato il blocco del terminale...
Se tutto funzionasse, non ci sarebbero un milione di topic dedicati a questo problema.
La logica si è rivelata più complicata di quanto gli utenti del terminale siano disposti a gestire.
E ci devono essere degli errori, ma gli sviluppatori non hanno il tempo di cercarli, e nessuno vuole nemmeno riprodurli e provarli tra gli utenti.
Andrei, suggerisco di iniziare con quello che abbiamo. E visto che abbiamo quello di cui parli, è meglio parlarne o evitarlo?
Penso che ci siano abbastanza problemi, ma piuttosto che parlarne di ramo in ramo (che è anche utile - a volte vengono risolti), ma fare il workaround.
E ho suggerito una buona opzione: mettere in cache le serie temporali necessarie al momento della loro piena disponibilità. E poi ricevere tutti i dati necessari da serie temporali pronte e sempre disponibili. E completarli solo con nuovi dati. Quando sono disponibili - lentamente e non necessariamente nel momento in cui ne avete bisogno.
Almeno in questo modo le cose andranno avanti. E le conversazioni possono essere lasciate per dopo - quando non c'è niente da fare.
Continuerò.
Quegli estremi a zig zag sospesi nell'aria sono esattamente della stessa natura di quelli che abbiamo quando accediamo alle serie temporali.
È solo che l'accesso alle serie temporali non è stato negato in MT4. Alcune funzioni non funzionavano correttamente lì (forse lo fanno ancora adesso). Avevo una spiegazione per il mio uso interno. Ne ho anche fatto uno forzato per conto mio. E tutto ha cominciato a funzionare senza errori, senza carico della CPU. Anche l'emissione di diverse decine di zigzag sui grafici non ha causato il blocco del terminale...
Se l'accesso alla serie temporale è negato, significa che è in fase di sincronizzazione. Dovete aspettare fino alla prossima spunta.
Nella tua situazione - meglio mettere in cache le serie temporali - saranno sempre disponibili senza aspettare, e alla prima richiesta.
Cache all'avvio dell'indicatore - quando c'è tempo per "aspettare la sincronizzazione" e in attesa di richiedere i dati per la prossima serie temporale.
Andrei, sto suggerendo che dovremmo andare con quello che abbiamo. E visto che abbiamo quello di cui parli, è meglio parlarne o aggirarlo?
Penso che ci siano abbastanza problemi, ma piuttosto che parlarne di ramo in ramo (che è anche utile - a volte vengono risolti), ma fare il workaround.
E ho suggerito una buona opzione: mettere in cache le serie temporali necessarie al momento della loro piena disponibilità. E inoltre - per ricevere tutti i dati necessari da serie temporali pronte e sempre disponibili. E completarli solo con nuovi dati. Allo stesso tempo, quando sono disponibili - non in fretta, e non necessariamente nel momento in cui sono necessari.
Almeno in questo modo le cose andranno avanti. E le conversazioni possono essere lasciate per dopo - quando non c'è niente da fare.
Allora è già più efficace fare un esempio riproducibile per gli sviluppatori da correggere.
Andrei, sto suggerendo che dovremmo andare con quello che abbiamo. E visto che abbiamo quello di cui parli, è meglio parlarne o aggirarlo?
Penso che ci siano abbastanza problemi, ma piuttosto che parlarne di ramo in ramo (che è anche utile - a volte vengono risolti), fate il workaround.
E ho suggerito una buona opzione: mettere in cache le serie temporali necessarie al momento della loro piena disponibilità. E poi ricevere tutti i dati necessari da serie temporali pronte e sempre disponibili. E completarli solo con nuovi dati. Allo stesso tempo, quando sono disponibili - non in fretta, e non necessariamente nel momento in cui sono necessari.
Almeno in questo modo le cose andranno avanti. E le conversazioni possono essere lasciate per dopo - quando non c'è niente da fare.
E perché gli sviluppatori del terminale non possono farlo? Non c'è comunque accesso alle serie temporali al momento dell'aggiornamento. Lasciate che tutti abbiano accesso a questa, diciamo, cronologia nella cache. Che differenza farebbe? Cioè, in modo che non ci sia mai un'interruzione dell'accesso. Beh, forse ci sarebbero dei ritardi alla barra zero. Il resto della storia sarebbe sempre disponibile.
Ho suggerito una buona opzione: mettere in cache la serie temporale necessaria al momento della sua piena disponibilità. E poi ricevere tutti i dati necessari da serie temporali pronte e sempre disponibili. E completarli solo con nuovi dati.
Questa è una brutta variante, bisogna ripetere interamente la logica di costruzione e sincronizzazione delle serie temporali nel terminale - è arrivato un nuovo tick, la sincronizzazione non è stata terminata... poi un errore di connessione
ZS: Sì, e perché farlo? - Non so quanti nella vita, ho un cellulare, una macchina, e anche un portafoglio con uno solo, ma un sacco di casi nella vita? - bisogno di un'assicurazione? .... "Tre registratori, tre cineprese straniere, tre portasigarette nazionali, giacca... scamosciata... Tre. Giacche" )))
Se l'accesso alla serie temporale è negato, significa che è in sincronia. Devi aspettare il prossimo tick.
Hai ragione! Ma è necessario fermare il programma MQL in qualsiasi punto e uscire dal terminale fino al prossimo tick... periodicamente suggerisco qualcosa come in Delphi "Abort() o Halt()" - ottenere un errore di accesso alla serie temporale una volta - èun errore critico, che non ha senso gestire molte volte - comunque, fino a quando il terminale non può regolare l'interazione con il programma MQL "è inutile" ))).
SZZ: non creo questo errore (errore di accesso alle serie temporali) - è creato dal terminale, ma tutti i programmatori MQL dovrebbero essere pronti a debuggare l'errore generato dal terminale... (quando il codice consiste di un paio di centinaia di linee) è facile giocarci, ma quando il codice è grande ed è conveniente usare l'accesso alle serie temporali da diverse sezioni del programma - e richiede 999 modi per uscire da qualsiasi sezione e non perdere i calcoli precedenti? - Sì, è possibile, ma richiede un piano chiaro (algoritmo) con cui il codice sorgente sarà scritto... E se il codice sorgente viene raffinato aggiungendo funzioni (classi) già pronte? - cioè ogni volta dovrai capire cosa c'è dentro... un compito generalmente dispendioso in termini di tempo per i grandi progetti per fornire tutto, imho
Se un programma è stato creato in 14 anni, tradurlo con il nuovo metodo di progettazione è più facile che darsi la zappa sui piedi. E anche il debugging dei collegamenti multipli è difficile. Il controllo dell'accessibilità ai tempi dà seri ritardi se non c'è accesso. Andrebbe bene se lecostruzioni grafiche automatiche fossero abilitate. La ricostruzione in modalità automatica è un fenomeno poco frequente. Qui si può anche non notare i ritardi. Tuttavia, anche in questo caso, quando l'accesso alle serie temporali è interrotto, le costruzioni grafiche sono talvolta emesse in forma troncata. Alcuni elementi hanno tempo per essere costruiti e altri no... Oppure, la filtrazione frattale taglia alcuni tf.
***
Se un programma è stato creato in 14 anni, tradurlo con il nuovo metodo di progettazione è più facile che darsi la zappa sui piedi. E anche il debugging dei collegamenti multipli è difficile. Il controllo dell'accessibilità ai tempi dà seri ritardi se non c'è accesso. Andrebbe bene se le costruzioni grafiche automatiche fossero abilitate. La ricostruzione in modalità automatica è un fenomeno poco frequente. Qui si può anche non notare i ritardi.
Ma il problema è quando la regolazione viene eseguita tramite interfaccia grafica. L'utente preme il pulsante e... deve aspettare il prossimo tick. Oppure l'utente preme il pulsante più volte fino a quando si verifica la risposta desiderata. Qual è la risposta dell'utente...? -***
E non ci sono questi problemi in MT4.
Ti capisco molto bene, quindi ho deciso di sostenere la discussione
funzioni iClose()...iXXX() per accedere alle serie temporali - grande!
Che siano funzioni sincrone, cioè l'accesso alle serie temporali sarà più lungo ma garantito a livello di terminale. Oppure gli sviluppatori di U.V. dovrebbero aggiungere la direttiva del precompilatore che darà un tick al programma MQL solo se il terminale è pronto ad accedere ai dati storici (OHLC) - nessun tick altrimenti.
....
ma l'unico scopo è quello di sbarazzarsi degli infiniti controlli di prontezza dei grafici OHLC, questo problema è stato risolto dalla comparsa di MT5 solo a livello di controlli all'interno del programma MQL, è un processo che richiede tempo e a mio parere gli utenti si aspettano che il terminale riceva i dati delle serie temporali senza problemi e garantiti in qualsiasi momento, in qualsiasi sezione di codice
questa è una cattiva opzione, è necessario ripetere completamente la logica di costruzione e sincronizzazione delle serie temporali nel terminale - poi è arrivato un nuovo tick, poi la sincronizzazione non è finita...poi un errore di connessione
ZS: Sì, e perché farlo? - Non so quanti nella vita, ho un cellulare, una macchina, e anche un portafoglio con uno solo, ma un sacco di casi nella vita? - bisogno di un'assicurazione? .... "Tre registratori, tre cineprese straniere, tre portasigarette nazionali, giacca... scamosciata... Tre. Giacche" )))
Va bene! Ma il programma MQL deve fermare i calcoli in qualsiasi punto e uscire dal terminale fino al prossimo tick... Ogni tanto suggerisco qualcosa come in Delphi "Abort() o Halt()" - hai un errore di accesso alla serie temporale - è un errore critico, che non ha senso elaborare molte volte - comunque, finché il terminale non stabilisce un'interazione con il programma MQL "è inutile" ))).
SZZ: non creo questo errore (errore di accesso alle serie temporali) - è creato dal terminale, ma tutti i programmatori MQL dovrebbero essere pronti a debuggare l'errore generato dal terminale... (quando il codice consiste di un paio di centinaia di linee) è facile giocarci, ma quando il codice è grande ed è conveniente usare l'accesso alle serie temporali da diverse sezioni del programma - e richiede 999 modi per uscire da qualsiasi sezione e non perdere i calcoli precedenti? - Sì, è possibile, ma richiede un piano chiaro (algoritmo) con cui il codice sorgente sarà scritto... E se il codice sorgente viene raffinato aggiungendo funzioni (classi) già pronte? - cioè ogni volta dovrai capire cosa c'è dentro... ...compito che richiede tempo per grandi progetti, imho
Se il programma viene eseguito da un clic del mouse, non importa se c'è o non c'è un accesso: bisogna reagire. Si può scrivere molto su come tutto è fatto male, ma in questo caso è meglio avere la propria cache, da cui si può sempre accedere su richiesta.
Immaginate il programma, che invece di dare qualcosa sui dati storici calcolati a lungo con un clic del mouse, dice - andate a fumare - prendo i dati attuali, di cui non avete bisogno ora, e ricostruisco la serie temporale...
In ogni caso, se dovete accontentarvi di quello che avete, è meglio produrre quello che c'è nella cache e poi ricostruirlo dopo aver sbloccato l'accesso alle serie temporali.