Argomento interessante per molti: cosa c'è di nuovo in MetaTrader 4 e MQL4 - grandi cambiamenti in arrivo - pagina 9
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
Ora che abbiamo toccato il mercato, mi piacerebbe sentire le opinioni su un argomento...
Secondo la filosofia di MQL5, gli indicatori devono contare e gli EA devono fare trading.
Ma Market vende soluzioni già pronte, come si dice, tutto in uno.
Che ne dite di migliorare il compilatore in modo che gli indicatori siano memorizzati negli EA come risorse?
Altrimenti, dobbiamo trasferire il codice dell'indicatore all'Expert Advisor dove non ha un ambiente adeguato. Anche in questo caso, lo schema "indicatore da indicatore" rende un'intera epopea il trasferimento del codice all'Expert Advisor.
Sono d'accordo,
Penso che sarebbe utile aggiungere una scheda per il Mercato ora - FILES, dove si possono mettere set, istruzioni, ecc,
Penso che sarebbe utile aggiungere una scheda - FILES dove è possibile memorizzare set, istruzioni e così via.
Possiamo perfezionare il compilatore per memorizzare gli indicatori negli EA come risorse?
Altrimenti dobbiamo spostare il codice di un indicatore in un Expert Advisor, dove non ha un ambiente adeguato. Di nuovo, lo schema "indicatore da indicatore" rende tutta un'epopea lo spostamento del codice nell'Expert Advisor.
Vedere MetaTrader 5 Client Terminal build 730 il 24 novembre 2012
8. MQL5: Aggiunto il supporto per la memorizzazione degli indicatori nelle risorse EX5. Allo stesso tempo, gli indicatori di risorse non saranno in grado di lavorare con le proprie risorse.
Vedere il comunicato stampa MetaTrader 5 Client Terminal build 730 del 24 novembre 2012
Questo è esattamente quello che faccio. E ho già scritto delle classi che possono passare all'Expert Advisor la storia personalizzata (invece della storia reale dal server), ma l'Expert Advisor non dovrebbe usare direttamente le funzioni del terminale per implementare pienamente la mia idea. Diciamo, lo stesso OrderSend(). Dovrebbe funzionare solo attraverso un "wrapper", il cui ruolo può essere meravigliosamente svolto dalla Libreria Standard. Scriviamo classi derivate, le infiliamo nell'Expert Advisor, e voilà - ora funziona su dati storici. Se l'Expert Advisor usa direttamente le funzioni del terminale, non sarà in grado di usare la storia.
Beh, forse è dovuto al mio lungo lavoro con la libreria MFC di cui sono stato molto soddisfatto e con la quale trovo molti parallelismi. Sono sicuro che anche gli sviluppatori della Libreria Standard conoscono bene MFC.
Il vantaggio principale della Libreria Standard è il buon supporto dell'ideologia OOP, che permette di passare all'Expert Advisor una storia personalizzata in modo che funzioni correttamente senza alcuna modifica.
Posso chiedere cosa non ti piace della Standard Library (beh, oltre all'ovvio svantaggio - "troppo pigro per imparare")?
Questo non è uno svantaggio, conosco molto bene SB, e questa conoscenza mi fa capire quanto tutto sia macchinoso e inefficiente.
Invece di inviare un ordine, si inizia un nonno per un nonno e un nonno per una rapa.
Ma lo svantaggio principale (secondo Trade) è che non c'è assolutamente alcun controllo dell'esecuzione. Mandano semplicemente un ordine al server e lasciano crescere l'erba. Ma hanno avvolto Send in 10 modi, come per tutte le occasioni, ma i casi sono diventati 100.
Per quanto riguarda l'ideologia: l'eredità per più di 2 generazioni è un errore, oltre si perde sia la comprensione che la flessibilità.
La maggior parte delle classi (hai ragione) non sono state inventate, sono state solo reinventate da MFC, ma questo non è uno svantaggio, perché reinventare la ruota.
Ma penso che lo svantaggio principale sia che non possono fare affidamento su di esso).
Ho scritto sia con che senza SB. Senza di esso si diventa più veloci e trasparenti. È troppo versatile, quindi è lento nelle curve.
In Delphi, per esempio, c'è il concetto di progetto, che implica una compilazione congiunta. E la divisione dei programmi in 3 tipi è un po' dubbia in generale, perché il compilatore, in teoria, può determinare da solo cosa fa il programma, ma dato che si va così lontano che gli indicatori commerciano solo per forza, e per gli EA è necessario implementare il codice all'interno, allora possiamo solo sperare che il cuore degli sviluppatori si scioglierà mai e permetteranno di fare progetti).
distaccato,
Penso che sarebbe utile aggiungere una scheda FILES per il mercato per memorizzare set, istruzioni e così via, per esempio,
anche se la scheda Discussione lo permette, ma non è ancora la stessa cosa.
Vedere MetaTrader 5 Client Terminal build 730 del 24 novembre 2012
Grande, come ho fatto a perdermelo, aaah è la builds pre-festiva.
L'incrocio nel suo post significa che possono già farlo?
È proprio questo lo svantaggio, conosco molto bene SB, e questa conoscenza mi fa capire quanto tutto sia macchinoso e inefficiente.
Grazie per la sua risposta esauriente. Non ho obiezioni categoriche a nessuna delle sue affermazioni. Solo... alcuni commenti...
Invece di mandare un ordine, nonno per nonno, nonno per rapa.
Ma questo è ciò che dà flessibilità al sistema, ed è ciò che ci permette di inviare la storia personalizzata e l'emulazione del server all'EA. Se gli ordini fossero inviati direttamente tramite OrderSend() - dovremmo scrivere questo "Nonna per il nonno, nonno per il nonno"... Non è chiaro cosa sia meglio...
Ma lo svantaggio principale (secondo il Commercio) è che non c'è assolutamente nessun controllo dell'applicazione. Se "batti" un ordine a un server e non te ne frega niente. Ma hanno avvolto Send in 10 modi, come per tutte le occasioni, ma i casi sono diventati 100.
Non ho abbastanza esperienza qui - posso solo teorizzare. Io stesso analizzo i codici di ritorno, ma ho poca esperienza. Sono d'accordo che non c'è abbastanza controllo dell'esecuzione in SB stesso.
Per quanto riguarda l'ideologia: considero l'eredità per più di 2 generazioni un errore, inoltre si perde sia la comprensione che la flessibilità.
Sì, infatti, un'eredità troppo profonda è molto dannosa per la comprensione. Ma sulla flessibilità - trovo difficile essere d'accordo. Ho un mucchio di casi di eredità di 4-5 generazioni, e non sembra causare alcun problema. Ma, posso essere d'accordo che questo è il caso per me, per altri questa profondità di eredità può essere un grande ostacolo.
Ma lo svantaggio principale penso che non è possibile fare affidamento su di esso, si scrive qualcosa su di esso e sarà rielaborato :)
Sì, sono completamente d'accordo.
Ho scritto sia con che senza SB. Ho scritto con SB ma senza di esso sono diventato più veloce e più trasparente. È troppo versatile, quindi è goffo nelle curve.
Mi è piaciuto SB per la sua capacità di creare un modello TC, e successivamente collegare solo le classi di oggetti che descrivono ingressi, manutenzione e uscite ad esso. Temo che senza SB una tale ideologia porterebbe alla creazione dello stesso, solo proprio SB.
A proposito di "più veloce e più trasparente" - mi sembra che tale ideologia sia buona quando abbiamo un qualsiasi TS trattato nel suo insieme. Tuttavia, mi sembra che questo sia un grave errore di algotrading. TS dovrebbe essere visto solo come un insieme di "cubi" - un insieme di generatori di input, determinante dell'input TP-SL, determinante del lotto di input, controllore di trailing e così via... Questa ideologia permette di ottenere molto rapidamente centinaia di diverse varianti di TS, dove noi ne abbiamo solo alcune "più veloci e trasparenti".
Per esempio, avendo scritto cinque diversi TS senza template - per scrivere il sesto dovremo rifare tutto da capo, anche usando parti di questi cinque sistemi. Avendo scritto il template - vi inseriremo questi cinque sistemi solo in parti, e come risultato avremo fino a cinque generatori di input, filtri di input, determinanti TP-SL e così via. Combinandoli si ottengono facilmente un centinaio di TS, tra i quali si possono scegliere i più stabili e redditizi.
Quindi, a mio parere, la lentezza di SB è davvero una "arma a doppio taglio", e la sua applicazione o non applicazione dovrebbe essere decisa in ogni caso individualmente.
Super, come ho fatto a mancare che, ahhhhh sono le builds pre-New Year.
La crocetta nel tuo post significa che possono già farlo?
Fantastico, come ho fatto a perdermelo, ahhh è il builds pre-New Year's.
È stato discusso qui: https://www.mql5.com/ru/forum/3409#comment_408123