Regole della struttura. Imparare a strutturare i programmi, esplorare le possibilità, gli errori, le soluzioni, ecc. - 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
Non crediate che io faccia il furbo, ma date un'altra occhiata a questa architettura della scrittura di un TC di combattimento. Non c'è feedback.
Ci sono posizioni virtuali e c'è un ambiente di trading reale che si adatta alla virtualità.
In questo caso, non importa nemmeno se il netting è nella piattaforma o in un altro sistema contabile.
Penso che sia una struttura molto interessante, soprattutto per le strategie ad alta velocità che non possono essere controllate sul normale tester.
Solo che non è del tutto chiaro il "sincronizzatore intelligente". Probabilmente intendono un copiatore adattivo di ordini di trading il cui compito, se ho capito bene, è quello di regolare la redditività virtuale / redditività della strategia e lo stato attuale del mercato - liquidità, velocità di esecuzione, ecc.
In generale, sarebbe bene avere un tale tester e sincronizzatore non costruito monoliticamente nell'Expert Advisor, ma come un modulo separato ed esterno.
In questo caso, qualsiasi Expert Advisor o diversi possono essere collegati ad esso e anche utilizzare selettivamente i segnali più appropriati.
Mi chiedo se questo è realistico usando solo MQL...
Questo è un modulo separato in termini di logica.
Per esempio, il servizio Signals è un modulo separato, non collegato al TS in alcun modo:
Traduce semplicemente le posizioni di origine virtuale (sono virtuali per voi) nel vostro ambiente di trading.
Curiosamente (non in modo ottimale), naturalmente, ma si traduce.
Questo è un modulo separato in termini di logica.
Per esempio, il servizio Signals è un modulo separato, non collegato al TS in alcun modo:
Traduce semplicemente le posizioni di origine virtuale (sono virtuali per voi) nel vostro ambiente di trading.
Curiosamente (non in modo ottimale), naturalmente, ma si traduce.
Si scopre che c'è un traduttore di Google che traduce in modo storto, ma lo farà se non avete bisogno di capirlo, ma se avete bisogno di capirlo con precisione - imparate la lingua).
Sarei soddisfatto di un'opzione intermedia - un traduttore personale di alta qualità (modulo), quando la traduzione è buona e non c'è bisogno di scrivere codice in ogni EA.
Capire come strutturare un programma viene con l'esperienza. Ognuno qui ha esperienze diverse, e quindi l'ordine e le regole di strutturazione saranno uniche. Inoltre, queste regole cambieranno nel tempo - cioè, ciò che sembrava una struttura ideale un paio di anni fa, oggi potrebbe non resistere nemmeno alla critica più leggera.
La struttura dei programmi in MQL è una canzone a parte, perché è in sostanza un DSL, controllato da eventi dal terminale (anche se sono stati fatti enormi passi per avvicinarlo ai linguaggi general purpose). Imho, per la descrizione delle strategie di trading il modo migliore è una macchina a stati, e ci sono già stati alcuni articoli su di essa qui. Infatti, la struttura degenera in un grande caso con un sacco di encludes per ogni caso.
Astraendo dai compiti commerciali, di solito alloco una parte centrale, che non sa nulla delle specifiche dell'interazione con l'utente. Il suo scopo è quello di fornire un modo per riempirsi di dati, risolvere il problema sulla base dei dati ricevuti e produrre il risultato. Il nucleo può consistere fisicamente in diversi file, ma tutti devono essere collegati logicamente e fornire all'esterno solo metodi di ricezione dei dati e metodi di restituzione dei dati e nient'altro. L'analogia più semplice è un tritacarne.
La seconda cosa che penso sia importante è localizzare le parti da cambiare (o le parti che potrebbero potenzialmente essere cambiate) e separarle in un'astrazione separata. Con questo approccio, possiamo passare senza soluzione di continuità tra diverse implementazioni del meccanismo (per esempio, cambiando il meccanismo di apertura delle posizioni, possiamo virtualizzare il trading). Diverse implementazioni sono convenientemente memorizzate in una cartella separata con un nome generico.
La struttura del progetto assomiglierà a un albero con il suo tronco (Core) composto da diversi sottosistemi (Subsystems) e rami di comportamento modificabile (Behaviour) che divergono da esso. E accanto ad esso ci sarà un binocolo (Reporting, GUI) per guardare questo albero dall'angolo necessario e un'ascia e una motosega (Actions, GUI) per fornirci l'interazione necessaria con questo albero.
Semplici macchine a stati al servizio dello sviluppatore
Semplici macchine a stati al servizio dello sviluppatore
Dai almeno un esempio approssimativo da applicare alle nostre realtà.
Sei davvero qualcosa :) L'implementazione di qualsiasi strategia è essenzialmente una macchina a stati.
Ho capito, ho chiesto un esempio di una tale macchina alla luce dell'articolo sulla charabra.
Oh, ok. C'era un articolo in cui il tizio faceva un "analogo" di una macchina a stati. E spingeva questa tecnologia come un'innovazione di programmazione all'avanguardia).
Ma non ricordo nessun articolo sostanziale sulle macchine a stati qui. Non lo ricordo qui.
Fate almeno un esempio approssimativo applicato alle nostre realtà.
Ahaha, mi ricorda "quale sarà la tua prova".
Ho cercato su Google "state machine", ho scelto il contenuto che mi piaceva di più e l'ho caricato qui.
Non provando nulla, non confutando nulla. Articolo interessante.
In generale, sono contro i dogmi: se una persona lo usa, non significa che vada bene per un'altra.
Ma quando leggo il codice di qualcun altro mi imbatto spesso in analogie con le macchine a stati. Solo un'osservazione.