Tester di supporto agli script e ai consulenti MG4 - pagina 10
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
Non ho detto questo.
Non ho toccato affatto questo argomento e non ho intenzione di entrarci.
A quanto pare, mi è sembrato:
E gli stoplots e i takeprofits integrati sono in realtà virtuali e vengono lanciati per l'esecuzione sul mercato al momento opportuno. Questa soluzione ha un lato positivo - risparmia sul CS (collaterale, margine).
Pensate a cosa forniscono le nuove funzioni di accesso ai dati e perché questo è il caso.
MetaTrader 4 ha una profondità limitata della storia, timeframes separati e accesso diretto alle barre del suo simbolo tramite Open/High/Low/Close/Time[xxx]. Tale accesso diretto è molto costoso da implementare in termini di risorse e di costo della CPU. Considera che ogni Expert Advisor ha la propria copia locale di questi dati per evitare conflitti con altri Expert Advisor e con il terminale stesso.
Quando il numero di simboli cresce (per esempio, in MT5 si possono avere 5 000-10 000 simboli), e utilizzando la storia profonda di un minuto come base di tutti i timeframes, non è più possibile in linea di principio utilizzare i metodi di MT4. Non c'è abbastanza RAM, e copiare grossi pezzi uccide le prestazioni. Ecco perché MT5 non mantiene più automaticamente una copia nascosta e costosa del grafico per ogni ecpert.
Invece siamo passati a funzioni CopyXXX molto economiche dove lo sviluppatore richiede esattamente all'array locale quanti dati gli servono, non l'intero grafico disponibile. Poi c'è la gestione più veloce possibile dei dati locali (invece del vecchio piuttosto costoso Open/High/Low/Close/Time[xxx]), in più l'autore può mettere in cache quei dati e usarli con parsimonia nella prossima chiamata. Il risparmio di memoria e di CPU è enorme. Inoltre, la piattaforma stessa è particolarmente libera di gestire vasti database - l'accesso ad essi è sempre su richiesta (invece di un accesso diretto non supervisionato) e questo permette una gestione flessibile delle cache.
Va anche notato che la semplicità delle chiamate Open/High/Low/Close/Time[xxx] in MQL4 era limitata al simbolo e al timeframe corrente, e tutti gli altri dati per altri simboli e timeframe erano ottenuti usando le funzioni iClose/iLow(...), che causavano gravi ritardi. La transizione in MQL5 ad un unico modello di funzione CopyXXX ha migliorato radicalmente la situazione, permettendo agli sviluppatori di ottenere i pezzi di dati richiesti con una sola richiesta, e di non fare più chiamate bloccate (pensate a tutti i blocchi in ogni singola chiamata a iClose).
...
E le prestazioni del CopyXXX?
In termini di risparmio di memoria - nessuna domanda. Ma è più costoso chiamare CopyXXX per ogni tick che copiare un array di quotazioni nel buffer una volta e accedervi tramite un indice diretto di tipo Rates[X]. Qui abbiamo un classico dilemma di programmazione: "Risparmiare memoria vs. risparmiare tempo di CPU".
Non meno di un MT5. Ora rivolgete la stessa domanda a voi stessi, solo che sostituite una B con una A.
Andate a imparare cos'è il MERCATO! Commerciante, sai....
Quindi stai dicendo che MT4 può, diciamo, memorizzare la storia degli spread o "conoscere" i volumi reali (senza tutte le stampelle e altre soluzioni totalmente inadeguate)?
Siete d'accordo che nel mercato reale lo spread non è chiaramente fisso? Vai e nel tester MT4 prova a testare l'EA su quotazioni con spread variabile, poi ne riparliamo.
Non mi interessa tanto il resto del mondo quanto gli interessi dello sviluppo di esperti con logiche complesse. ;)
La soluzione di compromesso sarebbe quella di organizzare gli ordini virtuali a livello di MT5. Poi ci sarebbero sia le reti che servono a qualcuno, sia la vecchia logica del lavoro con gli ordini.
Si assumerà i rischi di una tale "visualizzazione"?
In MT5, tutti quelli che volevano hanno usato a lungo la soluzione di copertura con trade su diversi strumenti con un alto grado di correlazione.
Sì, questo può richiedere molto più margine che in MT4, ma il buon senso dice bene.
Naturalmente, nessuno ha cancellato lo schema "virtuale" in questo caso.
Quindi stai dicendo che MT4 può, diciamo, memorizzare la storia degli spread o "sapere" dei volumi reali (senza tutte le stampelle e altre soluzioni inadeguate)?
Siete d'accordo che nel mercato reale lo spread non è chiaramente fisso? Vai e nel tester MT4 prova a testare l'EA su quotazioni con spread variabili, poi ne riparliamo.
Vi assumerete i rischi di tale "visualizzazione"?
In MT5, tutti quelli che volevano stanno usando una soluzione di copertura utilizzando trade in diversi strumenti con un alto grado di correlazione.
Grazie a Dio, c'è MT4 per ora. :) Potete usarlo su un solo strumento, se lo desiderate. Si possono usare diversi strumenti.
Quali sono i rischi secondo lei?
E le prestazioni di CopyXXX?
In termini di risparmio di memoria - nessuna domanda. Ma è più costoso chiamare CopyXXX per ogni tick che copiare un array di quotazioni in un buffer una volta e accedervi tramite un indice diretto di tipo Rates[X]. Qui abbiamo un classico dilemma di programmazione: "Risparmiare memoria vs. risparmiare tempo di CPU".
CopyXXX ha la stessa velocità delle funzioni iClose/iOpen/iXXXX. Solo iXXX restituisce un elemento alla volta, mentre CopyXXX ne restituisce molti ed è quindi più efficiente e veloce.
Probabilmente, non consideri che MT4 copia forzatamente _tutta_ la storia del grafico locale nell'ambiente di mercato locale (cache) dell'EA prima di ogni avvio del tick handler. E questo è molto costoso, anche se abbiamo un metodo per l'aggiornamento economico di queste informazioni. La funzione speciale RefreshRates in MQL4 causa il refresh forzato delle cache e della storia del grafico locale.
Chiamare CopyXXX è molto più efficiente, e gli sviluppatori hanno un meccanismo molto accurato e preciso di memorizzazione dei dati precedentemente richiesti. Per esempio, non c'è bisogno di ri-richiedere la storia profonda ad ogni tick, ma immagazzinarla/scriverla localmente e accedervi il più rapidamente possibile.
Se confrontiamo i vecchi metodi di accesso "diretto" (in realtà non accesso diretto) Open/High/Low/Close e il lavoro con l'array locale doppio locale[xxxx], quest'ultimo è molte volte più veloce. Pertanto, è meglio copiare su se stessi localmente e poi avere un accesso locale veloce ai dati ripetutamente interrogati.
Grazie a Dio c'è un MT4 per ora. :) Con esso, è possibile utilizzare uno strumento alla volta. Si possono usare diversi strumenti.
Quali sono i rischi secondo lei?
Quando si sviluppano/utilizzano "piattaforme di trading" ci sono certi costi e rischi, che qualcuno alla fine si assume.
Per quanto riguarda la "virtualizzazione" nel software di altri sviluppatori
Questa è una buona cosa, a patto che tutto sia usato per se stesso e che le persone che implementano la soluzione capiscano cosa stanno facendo.
I costi principali saranno: denaro speso per sviluppare il sistema, denaro speso per mantenerlo in funzione e tempo speso per implementare il progetto.
I rischi principali: si spenderà troppo tempo o denaro per implementare un progetto fattibile (il progetto non pagherà), il progetto non sarà efficace rispetto ad altre soluzioni, verranno introdotti errori nascosti nel codice o negli algoritmi durante l'implementazione del progetto.
Sì, le banche e altri attori del mercato ricorrono allo sviluppo del proprio software con le funzionalità necessarie, ma spendono una quantità enorme di tempo e risorse. Nel frattempo, si assumono assolutamente tutti i rischi.
Per quanto riguarda il lavoro con MT5 (diverse varianti che utilizzano MT5)
Qui ovviamente MQ ha fatto la maggior parte del lavoro, ma ha anche introdotto alcune restrizioni sulla funzionalità.
I costi principali saranno: il denaro speso per mantenere le prestazioni del sistema e il tempo dedicato al progetto.
I rischi principali: il progetto non sarà efficiente rispetto ad altre soluzioni, ci saranno errori nascosti nel codice o negli algoritmi durante l'implementazione del progetto, dovrai monitorare costantemente le prestazioni dell'intero sistema (proteggerlo da problemi software e hardware; monitorare la qualità della comunicazione, l'alimentazione, la sicurezza dei dati, ecc.)
Si può naturalmente pensare a un'applicazione commerciale (permettendo ad altre persone di usarla), con certe limitazioni e avvertenze.Vorrei dare un'occhiata a
Ecco un esempio in cui la semplicità e la facilità d'uso di OOP nella scrittura di programmi semplici è particolarmente evidente.