Il mio approccio. Il nucleo è il motore. - pagina 146
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
Реter Konow:
...
Non è una cattiva idea.
Ma cosa ci dà?
Forse riduciamo il carico della CPU e liberiamo i thread. Se abbiamo 10 copie di EA in esecuzione su 10 coppie, e carichiamo ogni motore con la GUI, il carico totale della CPU potrebbe essere troppo alto. Perché ogni GUI richiede il ridisegno degli elementi e questo è un carico pesante per la CPU. Ma in realtà possiamo vedere solo una GUI concreta di una copia. Gli altri sono nascosti.
Quindi è probabilmente la strada giusta da percorrere. Fare un motore comune.
In MT5 i grafici possono essere staccati. E poi devi inventare di nuovo il concetto.
Ogni EA ha la sua copia del kernel dei parametri. Può essere temporaneamente scollegato dalla GUI comune e un altro EA può essere collegato al motore. È importante che siano copie dello stesso EA.
Tuttavia, ci sono alcune difficoltà, che io stesso non ho ancora compreso appieno.
In teoria, la domanda suona così:
Perché abbiamo bisogno di aggiungere un motore con GUI per ogni grafico di una copia di EA se possiamo fare un motore con la GUI comune e collegarlo a tutte le copie dell'EA?
In pratica, incontreremo alcune difficoltà tecniche.
La copia di Expert Advisor può scrivere nuovi valori nella sua copia del kernel dei parametri. Se una delle copie non si collega al motore, il kernel cambierà solo sul lato della copia. Così, quando ci ricolleghiamo, dobbiamo passare l'intero kernel al motore e il motore ridisegnerà tutti gli elementi in tutte le finestre dove richiesto. Questo è possibile in linea di principio.
O rifare il kernel dei parametri stesso rendendolo una risorsa. In questo caso, il motore riceverà tutte le modifiche in una volta sola e ridisegnerà semplicemente gli elementi. Questa non è una cattiva idea.
Ma cosa ci dà?
Forse riduciamo il carico della CPU e liberiamo i thread. Se abbiamo 10 copie di EA in esecuzione su 10 coppie e carichiamo ogni motore con la GUI, il carico totale della CPU potrebbe essere eccessivo. Perché ogni GUI richiede il ridisegno degli elementi che è un carico pesante per la CPU. Ma in realtà possiamo vedere solo una GUI concreta di una copia. Gli altri sono nascosti.
Quindi è probabilmente la strada giusta da percorrere. Fare un motore comune.
Lasciate che le copie EA comunichino al motore il loro indirizzo con frequenza. Una stringa breve. Il motore reagirà e "parlerà" con la copia che ha lo stesso indirizzo di quella attuale. Lo scambio standard avrà luogo. Se l'indirizzo cambia nel motore, inizia a "scambiare" con la copia che imposta l'indirizzo corrispondente. Allo scambio standard di 'etere' aggiunge consiglieri o indicatori per esporre il suo indirizzo breve. Diversi byte. E la funzione "ascolta gli indirizzi del motore si avvia quando l'utente ha premuto il pulsante "riconfigura" sulla GUI del motore. Forse è qualcosa del genere.
In MT5 è possibile staccare i grafici. E poi devi inventare di nuovo il concetto.
Solo che non ne sono consapevole. Il grafico è staccato puramente "territorialmente", diventa libero dalle coordinate della finestra principale del terminale? Nei flussi di scambio, è ancora collegato al terminale per intero?
Solo che non ne sono consapevole. Il grafico è staccato puramente "territorialmente", diventa libero dalle coordinate della finestra principale del terminale? E nei flussi di scambio con il terminale, è ancora collegato al terminale per intero?
Il grafico è staccato, ma non cambia l'essenza. Stanno facendo un casino per niente). Non ha senso fare copie della GUI per ogni copia dell'EA. Non che io possa vedere, comunque. Ma sarebbe bello spostare una GUI tra i grafici delle copie.
Se c'è un grafico del centro di controllo della copia EA con il motore e l'interfaccia grafica principale, sarebbe utile.
La GUI dell'EA dovrebbe essere fatta con l'aspettativa che l'EA avrà molte repliche impostate su diversi strumenti.
SZY. Il grafico rimane nella stessa finestra, solo la finestra stessa può essere "tirata fuori", dal terminale.
Che le copie dei consiglieri comunichino al motore il loro indirizzo con frequenza. Una stringa breve. Il motore reagirà e "parlerà" con la copia che ha lo stesso indirizzo di quella attuale. Lo scambio standard avrà luogo. Se l'indirizzo cambia nel motore, inizia a "scambiare" con la copia che imposta l'indirizzo corrispondente. Allo scambio standard di 'etere' aggiunge consiglieri o indicatori per esporre il suo indirizzo breve. Diversi byte. E la funzione "ascolta gli indirizzi del motore si avvia quando l'utente ha premuto il pulsante "riconfigura" sulla GUI del motore. Forse va più o meno così.
Lei vede correttamente l'essenza. Solo i dettagli non sono esatti.
Cambiare la "comunicazione" stessa non è un problema. Ma, quando si cambia, bisogna reinizializzare l'intera GUI. Dopo tutto, le finestre e gli elementi di diverse copie hanno valori diversi. Quindi, è necessario ridisegnare quasi tutto.
I valori dei parametri di ogni copia sono memorizzati nel kernel dei parametri. Questo è un array. Finché la copia è scollegata dal motore, i cambiamenti di valori avverranno solo nella copia del kernel dei parametri di Expert Advisor. Non appena il motore è collegato, tutto deve essere trasferito ad esso da questo kernel. Sincronizzare le copie del Parameter Kernel nell'Engine e nell'Expert Advisor collegato. Quindi, è necessario trasferire una grande quantità di informazioni (Parameter Core), e ridisegnare le finestre. Dopo di che, sarà possibile regolare l'Expert Advisor collegato e gli altri andranno in modalità indipendente. Poi si farà una connessione con loro e succederà la stessa cosa.
Sarà così. Tuttavia, ci sono molte sfumature tecniche.
Peter. Con un periodo di N ms l'EA riceve qualcosa dal motore, e dopo passa al motore qualcosa di preparato. Il consulente attende quindi l'arrivo della zecca o di un nuovo lotto di scambio di domande. Giusto?
Quasi giusto. La comunicazione e l'attesa che il tic, o altri eventi, accadano in modo asincrono.
L'orario è staccato, ma non cambia il punto. È una perdita di tempo).
...
SZY. Il grafico rimane nella stessa finestra, solo la finestra stessa può essere "tirata fuori", dal Terminale.
E secondo la tua concezione che solo un grafico corrente è comunque visibile alla volta, e solo esso può essere aggiornato, sarà rotto - ci saranno tanti grafici visibili quanti sono staccati.
Certamente non è un incubo, ma nemmeno un bene - solo uno dei grafici visibili "vivrà", e il resto?
Pensi che questo sia normale? Beh, se è così, ancora una volta sono convinto della mancanza di serietà nel risolvere i bug - se c'è, non è per risolverli, ma per nasconderli.
Quasi giusto. La comunicazione e l'attesa di un tick, o di altri eventi, avviene in modo asincrono.
Che ne dite di questo. I consulenti, ognuno con frequenti alcuni (OnTimer), inviano al motore la sua stringa di codice. Tutte le linee di codice sono diverse. Il motore analizza internamente le stringhe in arrivo e ne "riconosce" una, per esempio quella dell'Expert Advisor numero 3. In risposta a questo EA, invia un "segnale" per iniziare la trasmissione principale. Il motore funziona con questo Expert Advisor.
Se una persona preme il pulsante Switch, il motore analizza i consigli consentiti, e sono indicizzati, sotto i numeri. Dice all'EA corrente di passare allo stato di impostazione di un indirizzo, come se lo spegnesse dal flusso di lavoro, sceglie la stringa di codice con l'indice di 1 in più e aspetta l'arrivo della stessa stringa di codice da qualsiasi altro EA. Quando l'indirizzo corrisponde, invia un segnale all'Expert Advisor per smettere di esporre l'indirizzo e iniziare lo scambio. L'unico Expert Advisor e la serie di copie, che non è in modalità di fatturazione, riceveranno lo scambio. In breve, qualcosa come.
Se il motore riceve un indirizzo, fa un timeout per impedire la ricezione di indirizzi. In modo che gli indirizzi non si sovrappongano.
Che ne dite di questo. Gli Expert Advisors, ciascuno con una frequenza di qualche tipo (OnTimer), inviano al motore la propria stringa di codice. Tutte le linee di codice sono diverse. Il motore analizza internamente le stringhe in arrivo e ne "riconosce" una, per esempio quella di Expert Advisor numero 3. In risposta a questo EA, invia un "segnale" per iniziare la trasmissione principale. Il motore funziona con questo Expert Advisor.
Se una persona preme il pulsante Switch, il motore analizza i consigli consentiti, e sono indicizzati, sotto i numeri. Dice all'EA corrente di passare allo stato di impostazione di un indirizzo, come se lo spegnesse dal flusso di lavoro, seleziona una stringa di codice con l'indice di 1 in più e aspetta l'arrivo della stessa stringa di codice da qualsiasi altro EA. Quando l'indirizzo corrisponde, invia un segnale all'Expert Advisor per smettere di esporre l'indirizzo e iniziare lo scambio. L'unico Expert Advisor e la serie di copie, che non è in modalità di fatturazione, riceveranno lo scambio. In breve, qualcosa come.
Se il motore riceve un indirizzo, il tempo di inibizione dell'indirizzo si esaurisce. In modo che gli indirizzi non si sovrappongano.
Questo non è l'approccio giusto. Lasciatemi spiegare:
Ogni copia di EA non smette di scrivere i suoi messaggi al motore nella sua risorsa separata. Allo stesso tempo, ogni copia dell'EA inizializza i valori dei propri elementi nella sua copia dei parametri del kernel. Cioè, anche quando è disconnesso dal motore, tutte le copie dell'EA dovrebbero funzionare correttamente.
Quando il motore cambia le connessioni tra le copie dell'EA, deve sincronizzare i suoi parametri del kernel con il kernel dell'EA connesso. Dopo di che, ridisegna gli elementi nelle finestre, in modo che visualizzino le informazioni effettive.
Per quanto riguarda la comunicazione con l'Expert Advisor selezionato, tutto è semplice. La risorsa per ricevere messaggi dal motore (così come la risorsa di messaggi per il motore), ogni EA avrà la sua. Cioè, il motore registrerà semplicemente i suoi messaggi nell'altra risorsa, e leggerà i messaggi dall'altra risorsa. Quella risorsa appartiene all'EA collegata.