Regole della struttura. Imparare a strutturare i programmi, esplorare le possibilità, gli errori, le soluzioni, ecc. - pagina 18
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
Oh, Vladimir, non è così facile con il tuo circuito. Stai dicendo che hai solo bisogno di riscrivere il driver? Beh, ho contato molte più parti che dipendono dalla piattaforma:
Come otterrete la storia del mercato e la storia del commercio? E le informazioni sulla posizione attuale non saranno prese dal terminale, per caso? E se dovete implementare il modulo della volatilità - un'altra API dipendente dalla piattaforma?
Scriverà degli adattatori? Quanti ce ne saranno? Per la storia del mercato - un adattatore, per la storia del trading - un altro, per lavorare con le posizioni - un terzo. Così alla fine ci sono il doppio dei moduli, ma la stessa quantità di codice dipendente dalla piattaforma.
Non è così che vedo il problema.
Proprio tutto ciò che è rosso è abbastanza stabile, tutto ciò che viene dalla piattaforma non cambia nel corso degli anni, se avete bisogno di un'altra piattaforma, c'è anche una API ben consolidata, riscrivere nessun problema.
Ma tutti i moduli con le frecce verdi sono propri, e quasi sempre attiva la rielaborazione (non c'è limite all'ideale).
Il previsore direzionale è stato scritto, poi è arrivata la nuova idea di approfondire ed espandere, bene, come ora è comprare, ma dobbiamo prepararci per vendere, ridurre lentamente il volume.
Così ho iniziato a usare due moduli.
MM Corrector è anche uno schema dinamico, ora funziona con le posizioni, poi improvvisamente ha avuto un'idea e ha deciso di cambiarlo per le posizioni lunghe (ingresso a mercato liscio).
Market Driver dovrebbe essere stabile perché ha l'output di API dipendenti dalla piattaforma, quindi la formalizzazione è chiara, ma sarà davvero disordinato perché API fornisce un sacco di possibilità.
Non è così che vedo il problema.
Proprio tutto ciò che è rosso è abbastanza stabile, tutto ciò che viene dalla piattaforma non è cambiato per anni, se ne hai bisogno per un'altra piattaforma, c'è anche una API ben consolidata, non è un problema riscriverla.
Una delle idee importanti nello schema non è il numero di parti dipendenti dalla piattaforma, ma la loro stretta localizzazione. Cioè: TS stesso (predittori + moduli MM) - è un design indipendente dalla piattaforma, ma le fonti di dati sono indicatori e driver di mercato, rispettivamente dipendenti (la storia commerciale, alimentata all'ingresso del correttore di raccomandazioni - è anche essenzialmente l'indicatore).
La conseguenza - una zona di intervento chiaramente limitata e chiaramente distinguibile e non sovrapposta a
1. Migrazione.
2. Miglioramento del TS, in particolare la scalatura.
Ma tutti i moduli con le frecce verdi sono propri, e quasi sempre una riprogettazione attiva (non c'è limite all'ideale).
Il previsore direzionale è stato scritto, poi è arrivata la nuova idea di approfondire ed espandere, beh, come ora è comprare, ma dobbiamo prepararci a vendere, ridurre lentamente il volume.
Così ho iniziato a usare due moduli.
Il MM Corrector è anche uno schema dinamico, ora lavora con la posizione, poi all'improvviso si è fatto furbo e ha deciso di cambiarla per l'equity (ingresso a mercato liscio).
Il Market Driver dovrebbe essere stabile perché ha l'output all'API dipendente dalla piattaforma, quindi la formalizzazione è chiara, ma ci sarà un sacco di confusione perché l'API fornisce un sacco di funzioni.
Nessuno ha promesso l'assenza di complicazioni :) Ma pensate se tutte quelle chiamate API dirette non sono localizzate nel driver, ma mescolate con codici di predittori e moduli MM.............
;)
Nikolay, il tuo post è molto sensato, tuttavia mi impegno a difendere lo schema proposto (la sua universalità).
Sono d'accordo, voglio solo chiarire (cogliendo l'occasione) per Vasily. Una delle idee importanti nello schema non è il numero di parti dipendenti dalla piattaforma, ma la loro stretta localizzazione. Cioè: TS stesso (predittori + moduli MM) - è un design indipendente dalla piattaforma, ma le fonti di dati sono indicatori e driver di mercato, rispettivamente dipendenti (la storia commerciale, alimentata all'ingresso del correttore di raccomandazioni - è anche essenzialmente l'indicatore).
La conseguenza - una zona di intervento chiaramente limitata e chiaramente distinguibile e non sovrapposta a
1. Migrazioni.
2. Miglioramento del TS. In particolare, scalare.
Tuttavia, se ad ogni modifica ci atteniamo attentamente alla divisione su parti del sistema dipendenti dalla piattaforma/indipendenti, allora per esempio nella nostra situazione attuale possiamo facilmente supportare lo sviluppo di EAs per entrambe le piattaforme (MT4/5), che sarebbe una seccatura nei sistemi di trading dipendenti dalla piattaforma.Ci può essere qualsiasi numero di moduli all'interno dei componenti segnati nello schema. Questo è normale. Penso che sia utile solo la loro chiara disposizione in pipeline, che non dovrebbe essere mescolata all'interno del codice senza una necessità assolutamente inevitabile. cioè Dovresti evitare il più possibile il rimescolamento. Questo ti permette di avere sempre punti di aggancio dei moduli ben definiti e comodi quando si scala verso i multitool. Guarda lo schema da questa angolazione, lo troverai da solo.
Vedi sopra. // Ma l'input del correttore MM è il punto più conveniente per integrare una nuvola di predittori a valuta singola (strumento singolo più precisamente) nella cucina multi-valuta (multi-strumento).Nessuno ha promesso la completa assenza di complessità. :) Ma pensate se tutte queste chiamate API dirette non sono localizzate nel driver, ma mescolate con codici di predittori e moduli MM.............
;)
OK, usiamolo come base (ma aggiungiamo un modulo di stop, sembra ragionevole e nessuno ha obiezioni),
e pensare cos'altro manca in questo schema, o rifarlo.
OK, prendiamolo come base (aggiungete solo un modulo per lavorare con gli stop, sembra ragionevole e nessuno ha obiezioni),
e pensare a cos'altro manca in questo circuito, o rielaborarlo.
Penserò alla rielaborazione-miglioramento (lasciarlo cuocere).
La mancanza è più evidente - questo schema ovviamente manca della GUI (sottosistema di monitoraggio/controllo visivo). Voglio sviluppare uno schema unificato (e conveniente!) di interazione dell'Expert Advisor con la GUI. Finora, sono spontaneo in questa materia, il che mi infastidisce molto. Vorrei raggiungere lo stesso obiettivo (astrazione completa dei dati in entrambe le direzioni). È per questo che ho suggerito il compito dell'interfaccia EA/GUI per la formazione, mi interessa mercantilmente, volevo avere qualche idea dal pubblico.
Ci può essere qualsiasi numero di moduli all'interno dei componenti evidenziati nello schema. Questo è normale. Trovo solo utile organizzarli in una chiara pipeline. Che non dovrebbero essere mescolati all'interno del codice senza una necessità assolutamente inevitabile. Questo permette di avere sempre dei punti di aggancio ben definiti e comodi quando si scala verso i multitool. Guardate il diagramma da questa angolazione e lo troverete voi stessi.
L'espansione illimitata dei moduli porta a gravi problemi in futuro. La logica dell'Expert Advisor è praticamente dispersa in diversi moduli. I moduli stessi interagiranno tra loro, e non c'è garanzia che i collegamenti tra di loro non diventino un groviglio. Imho, tutti i quadrati segnati in verde sono elementi di un sistema di trading. Decomponendoli in diversi moduli si viola uno dei principi principali della programmazione: l'incapsulamento di dati e metodi all'interno di un compito.
Dato che tutti hanno iniziato a pubblicare i loro schemi, continuerò anch'io. Questa volta è uno schema ancora più astratto:
Le frecce nere descrivono relazioni rigide. Quelle grigie sono interrelazioni private all'interno del modulo, non sono importanti. Anche la classe del robot di trading ha il diritto di rivolgersi direttamente all'API della piattaforma, ma questo riduce l'indipendenza dalla piattaforma.
L'espansione illimitata dei moduli porta a gravi problemi in futuro. La logica dell'Expert Advisor è praticamente dispersa in diversi moduli. I moduli stessi interagiranno tra di loro, e non c'è garanzia che i collegamenti tra di loro non diventino un groviglio. Imho, tutti i quadrati segnati in verde sono elementi di un sistema di trading. Decomponendoli in diversi moduli si viola uno dei principi principali della programmazione: l'incapsulamento di dati e metodi all'interno di un compito.
Visto che tutti hanno iniziato a pubblicare i loro schemi, continuerò anch'io. Questa volta si tratta di uno schema ancora più astratto:
Le frecce nere descrivono relazioni rigide. Quelli grigi sono interrelazioni private all'interno del modulo, non sono importanti. Inoltre, la classe del robot di trading ha il diritto di accedere direttamente all'API della piattaforma, ma questo riduce l'indipendenza dalla piattaforma.
Per quanto riguarda la riprogettazione-miglioramento, ci penserò (lascerò che si metta a fermentare).
La mancanza è più evidente - questo schema ovviamente manca di GUI (sottosistema di monitoraggio/controllo visivo). Voglio sviluppare uno schema unificato (e conveniente!) di interazione tra l'Expert Advisor e la GUI. Finora, sono spontaneo in questa materia, il che mi infastidisce molto. Vorrei raggiungere lo stesso obiettivo (astrazione completa dei dati in entrambe le direzioni). È per questo che ho suggerito il compito dell'interfaccia EA/GUI per la formazione, mi interessa mercantilmente, volevo avere qualche idea dal pubblico.
Passare dal compito. Quali sono i compiti più richiesti nella GUI?
Partire da lì. Descrivi ciò che vuoi ottenere, seleziona le voci comuni, fai un quadro, poi aggiungi altre cose, vedi quanto è facile cambiare il quadro.
Allora capirete come dovrebbe essere, riscrivete tutto da capo. Io la vedo così.
MetaDriver dice bene, e il suo sistema è corretto. Dick_fx aggiungerebbe anche che il "driver di trading" dovrebbe lavorare con 10-20 piattaforme per utilizzare i prezzi migliori.
Ma usare un sistema così corretto è conveniente solo in condizioni ideali - nessun errore di strategia, nessun intervento dell'utente, nessuna forza maggiore... E in realtà questo è raramente il caso.
Faccio un esempio di dick_fx: 25 strategie stanno lavorando, l'aggregatore (trade driver) le raccoglie in una posizione netta e le mette sul mercato, tutto è OK. Improvvisamente, qualcosa va storto nella strategia 17-th e dà previsioni malsane - dice di aprire al 50% del deposito. Expert Advisor si apre obbediente.
Cosa fa un banale armadietto alla MT4:
Ora passiamo alla "contabilità corretta". Cosa dovrebbe fare il trader per correggere l'errore (un commercio con il 50% di margine - un ovvio errore logico)?
La domanda è: qual è più facile? Ovviamente, la variante con MT4.
E cosa è più economico? Ovviamente, l'opzione Netting.
Qual è la conclusione? Fare un driver di mercato con una GUI da MT4 ;)
E un'altra cosa.
Questo è tutto il ragionamento dei commercianti "giusti", e anche dei programmatori. Se lo fanno per il loro piacere, sul conto con un buon deposito, allora è l'unico modo per farlo.
Se tocchiamo la scrittura esperta, si scopre che nessuno ne ha bisogno "giusto". Le folle di commercianti-clienti non possono essere cambiate, quindi si deve scrivere "per loro".
L'opzione "lascia il mio lavoro" è accettata! =)
E un'altra cosa.
Questo è tutto il ragionamento dei commercianti "giusti", e anche dei programmatori. Se lo fanno per il loro piacere, sul conto con un buon deposito, allora è l'unico modo per farlo.
Se tocchiamo la scrittura esperta, si scopre che nessuno ne ha bisogno "giusto". Le folle di commercianti-clienti non possono essere cambiate, quindi si deve scrivere "per loro".
L'opzione "lascia il mio lavoro" è accettata! =)