Cosa si dovrebbe aggiungere per un ulteriore supporto dei calcoli matematici universali in MQL5 e MQL5 Cloud Network? - pagina 7
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
per utilizzare il mio PC in Cloud Computing in
MQL5 Cloud Network. Ma ecco il problema, il mio account suhttp://www.mql5.com non mostra agenti, il che significa che non mi verrà addebitato l'uso del mio PC. In MT5MetaTrader 5 Agents Manager stesso ho inserito il nome del mio conto.
Ma ecco il problema nel mio account suhttp://www.mql5.com non vengono visualizzati gli agenti, il che significa che la tassa non gocciola per l'utilizzo del mio PC. Nello stessoMetaTrader 5 Agents Manager di MT5, ho inserito il nome del mio conto.
Da qui la domanda - quali altre funzioni dovrebbero essere incluse per migliorare le capacità della griglia di fatturazione?
Probabilmente metodi di classi che possono essere chiamati a distanza e ottenere i loro valori da agenti: Remote Procedure Call (RPC). Qualcosa del genere:
Insieme a una chiamata di metodo, naturalmente, abbiamo bisogno di passare all'agente i valori correnti dei campi dell'oggetto che chiama il metodo a distanza.
L'idea è che l'istanza della classe principale chiama qualche metodo, e all'interno del metodo, vengono create istanze di altre classi, che inviano compiti al cloud. Il risultato o i risultati sono restituiti.
Per esempio, un compito viene creato sotto forma di calcolo di diverse mosse di scacchi. Nel metodo principale, che viene eseguito in remoto, vengono create varie combinazioni con un conteggio per una mossa sotto forma di oggetti di qualche classe e inviate. Questi a loro volta, se la mossa non si è conclusa con un risultato o la profondità di calcolo non ha superato il limite, chiamano nuovamente lo stesso metodo. E così via.
Senza il coinvolgimento del terminale, questa è una buona cosa.
Chi genererà i dati per questo "uno degli agenti"? Uno script o un indicatore sarà in grado di farlo?
Qualsiasi agente può generare dati grezzi per gli altri. Può inviare in fordcast a tutti o a un agente selezionato.
Qualsiasi agente sarà in grado di inviare frame di dati a qualsiasi altro agente.
Qual è lo scopo della comunicazione da agente ad agente, illuminate l'ignorante se potete.
Per compiti correlati in cui i dati/risultati di calcoli precedenti devono essere scambiati.
Non deve essere per forza nel cloud. Potete creare una rete di agenti ad alta velocità nella vostra area locale ed eseguire un compito complesso con un sacco di scambio di dati su di essa.
Di conseguenza, è possibile costruire una rete potente senza alcun supercomputer.
Probabilmente i metodi di classe che possono essere chiamati da remoto e ottenere i loro valori dagli agenti. Qualcosa del genere:
Qui, naturalmente, insieme a una chiamata di metodo, dovremmo passare all'agente anche i valori attuali dei campi dell'oggetto che chiama questo metodo da remoto.No, l'unica opzione praticabile e realistica è lo scambio di frame di dati. L'esecuzione remota di funzioni non è seria, perché nessuno sano di mente replicherebbe l'ambiente informativo.
Come parte del lavoro di inquadramento, la funzionalità può essere estesa:
Solo nel caso in cui per informazioni:
Il costo della latenza di rete è tale che per ottimizzare il processo complessivo, dovreste impegnarvi nel batching esplicito dei risultati e trasferire i dati il meno frequentemente possibile. Per esempio, se c'è un problema matematico ad alta velocità (entro frazioni di secondo) per 100.000.000 di passaggi, è meglio ottimizzare immediatamente il processo algoritmicamente in porzioni di 1.000-10.000 passaggi e scrivere codice di elaborazione batch con risultati restituiti in un batch. Questo darebbe un enorme vantaggio rispetto a 100.000.000 di ritorni, dove si passerebbe molto tempo sulla rete.
Da parte nostra, noi stessi aiutiamo seriamente nei casi di compiti ad alta velocità facendo il batching dell'output in decine o centinaia di passaggi per ogni agente e anche il batching delle risposte. Questo dà un enorme risparmio sulla trasmissione di rete e mantiene la latenza di rete al minimo.
No, l'unica opzione praticabile e realistica è lo scambio di frame di dati. L'esecuzione remota di funzioni non è seria, perché nessuno sano di mente replicherebbe un ambiente informatico.
Non tutti i compiti possono essere impacchettati, perché in alcune applicazioni e compiti molto impegnativi in termini di risorse il risultato può essere l'unico o può non essere rilevato affatto, e i compiti futili vengono scartati lungo la strada, cioè i risultati mancanti non dovrebbero nemmeno essere restituiti.
Allora c'è un altro modo per farlo. Cioè, il compito principale genera compiti dalla sua parte, informa gli agenti su di esso. E gli agenti chiamano metodi remoti con compiti, calcolano e se ottengono risultati, chiamano metodi remoti per restituire i risultati.
Per esempio, il compito: cercare i divisori primi dei numeri di Fermat. Forse non ci sarà nessun risultato, o uno, o diversi. Il punto è che la ricerca di questi divisori molto potenziali è un compito che richiede molte risorse, perché prima è necessario creare un oggetto sotto forma di un grande numero (nel compito è possibile specificare solo due numeri come interi: primo e mantissa, per ridurre il costo di trasferimento delle informazioni). Poi il numero da controllare per primo (eseguire un test semplificato, che rivelerà che il numero in più del 90 per cento non è primo). E poi, se il test di semplicità viene superato con successo, nel ciclo, la quadratura del modulo cerca una corrispondenza. Se la condizione prima della fine del ciclo non coincide, allora non ci sarà alcun risultato e non ci sarà nulla da restituire. In questo caso, l'agente deve richiedere da remoto il lavoro successivo chiamando da remoto il metodo appropriato dall'applicazione host. Se trova il risultato, deve chiamare un altro metodo e passare lo stesso risultato.
Cioè i compiti sono diversi e le strutture del telaio non sono adeguate per tutti. E anche il costo della latenza di rete nell'esempio precedente è trascurabile, poiché un compito consiste nel passare due interi a un agente.
Non tutti i compiti possono essere raggruppati, poiché in alcune applicazioni e compiti molto intensivi in termini di risorse ci può essere solo un risultato o nessun risultato, e i compiti inconcludenti vengono scartati man mano che il gioco procede, cioè i risultati mancanti non devono nemmeno essere restituiti.
Se si usa uno schema a frame, basta non restituire risultati vuoti all'"agente del server" o semplicemente restituire il flag "pacchetto calcolato, nessun dato".
Sei consapevole di come funziona la modalità frame? L'intestazione EA inizia proprio nella finestra del terminale e aspetta le risposte (frame di dati) dagli agenti remoti. Cioè, la parte server si siede sul grafico, riceve i dati e può visualizzare qualsiasi cosa.
Leggete e provate voi stessi: https://www.mql5.com/ru/code/914
Se si usa uno schema a cornice, basta non restituire risultati vuoti all'"agente del server".
Beh, questa è solo la base. I compiti principali, che sono molto intensivi dal punto di vista computazionale, sono ricorsivi. E la nuvola non è destinata a questi compiti perché è progettata solo per la ricerca completa. In molti compiti applicati non usiamo la forza bruta perché non ha prospettive. I compiti ricorsivi sono necessari per la ricerca in profondità e in larghezza e in profondità con larghezza. Per esempio, la sintesi delle molecole. Cioè un albero di potenziali soluzioni è costruito nel corso del gioco, ogni ramo è computazionalmente impegnativo. Ma non tutti i rami sono efficaci. Cioè la ricerca si ferma da qualche parte, ma allo stesso tempo, la ricerca continua per altri potenziali rami in profondità o larghezza.
La ricerca completa non è praticamente mai usata da nessuna parte, poiché per la maggior parte dei compiti applicativi non impiegherà abbastanza tempo per trovare una soluzione (per esempio il problema dell'analisi delle mosse degli scacchi). Ma i metodi ricorsivi con il taglio dei rami di soluzione non prospettici danno un'alta velocità, specialmente nei calcoli distribuiti. Ecco perché se volete attirare gli ingegneri applicativi verso il cloud, dovreste adattare il cloud ai loro compiti, invece di pensare che lasceranno tutto e proveranno tutte le varianti in fila, indipendentemente dalle loro prospettive. Sarebbe più facile per loro creare la propria rete di calcolo distribuito, anche se è meno veloce in termini di gigaflops e ha meno computer, ma è più efficiente, perché cercherà solo nelle aree promettenti e troverà la soluzione necessaria molto più velocemente di Cloud Network. E molti linguaggi di programmazione hanno un toolkit per questo, cioè implementazioni RPC già pronte.
Per esempio, la stessa ricerca dei divisori primi dei numeri di Fermat può essere suddivisa in sottocompiti. L'applicazione principale genera i compiti. Il livello successivo crea gli oggetti ed esegue un rapido controllo di semplicità su di essi dai compiti rimanenti. Il livello successivo cerca le condizioni, cioè se si trova o meno un divisore di un numero di Fermat. I lavori sono di nuovo generati dai numeri trovati. Il livello successivo esegue un controllo di semplicità completo, e se il numero non è primo, genera dei lavori. Se è primo, restituisce il risultato all'applicazione principale. Lo strato successivo fattorizza i divisori non semplici dei numeri di Fermat e genera da essi i lavori per lo strato precedente.
Questo crea un trasportatore, dove ogni agente di livello esegue i suoi compiti. Non è chiaro se il risultato sarà trovato. Ciò che è importante è che i numeri consapevolmente senza speranza per l'ulteriore ricerca di soluzioni vengono scartati nel trasportatore. In altre parole, risparmia un sacco di risorse computazionali, invece di cercare di ammucchiare migliaia di agenti su compiti poco promettenti e cercare di macinarli.
Questa è solo la base. I compiti principali sono ricorsivi e richiedono molte risorse per i calcoli. E la nuvola non è destinata a questi compiti perché è progettata solo per la ricerca completa. In molti compiti applicati non usiamo la forza bruta perché non ha prospettive. I compiti ricorsivi sono necessari per la ricerca in profondità e larghezza e in profondità con larghezza. Per esempio, la sintesi di molecole. Cioè un albero di potenziali soluzioni è costruito nel corso del gioco, ogni ramo è computazionalmente impegnativo. Ma non tutti i rami sono efficaci. Cioè da qualche parte la ricerca viene interrotta, ma allo stesso tempo, la ricerca continua per altri potenziali rami in profondità o in larghezza.
Calcoli in batch in 1.000-10.000 passaggi, e restituisce solo i risultati significativi. Questa è una tecnica algoritmica molto efficace.
Ne ho scritto specificamente sopra.
La ricerca completa non è quasi mai usata, perché per la maggior parte dei problemi applicati non ci vorrà abbastanza tempo per trovare una soluzione (per esempio, un problema di analisi delle mosse di una partita di scacchi). Ma i metodi ricorsivi con il taglio dei rami di soluzione non prospettici danno un'alta velocità, specialmente nei calcoli distribuiti. Ecco perché se volete attirare gli ingegneri applicativi verso il cloud, dovreste adattare il cloud ai loro compiti, invece di pensare che lasceranno tutto e proveranno tutte le varianti in fila, indipendentemente dalle loro prospettive. Sarà più facile per loro creare la propria rete di calcolo distribuito, anche se è meno veloce in termini di gigaflops e ha meno computer, ma sarà più efficiente, perché cercherà solo in direzioni promettenti e troverà la soluzione necessaria molto più velocemente di Cloud Network. E molti linguaggi di programmazione hanno un toolkit per questo, cioè implementazioni già pronte di RPC.
Per esempio, la stessa ricerca dei divisori primi dei numeri di Fermat può essere suddivisa in sottocompiti. L'applicazione principale genera i compiti. Il livello successivo crea gli oggetti ed esegue un rapido controllo di semplicità su di essi dai compiti rimanenti. Il livello successivo cerca le condizioni, cioè se si trova o meno un divisore di un numero di Fermat. I compiti sono di nuovo formati dai numeri trovati. Il livello successivo esegue un controllo di semplicità completo, e se il numero non è primo, genera dei lavori. Se è primo, restituisce il risultato all'applicazione principale. Lo strato successivo fattorizza i divisori non primi dei numeri di Fermat e genera lavori per lo strato precedente.
Leggete sopra sullo scambio di dati e sull'esempio demo:
Viene proposta un'ulteriore estensione allo scambio di dati in modo che il processo master possa passare anche altri dati personalizzati a qualsiasi agente. Di conseguenza, è possibile leggere in parti, distribuendo nuove condizioni personalizzate agli agenti remoti. Di conseguenza, può leggere come vuole, cambiando le condizioni ogni volta.
Un'altra possibile estensione, quando gli agenti possono non solo ricevere compiti dal master ma anche scambiare dati tra di loro. Naturalmente è possibile farlo tramite wizard (che può essere molto lento se ci sono molti dati), ma è ancora più efficiente e veloce farlo direttamente tramite i server cloud.
Renat:
Un'altra possibile estensione è che gli agenti non solo ricevano compiti dal wizard, ma anche che trasferiscano dati tra di loro. Naturalmente è possibile farlo attraverso la procedura guidata (che può essere molto lenta se ci sono molti dati), ma è ancora più efficiente e veloce farlo direttamente attraverso i server cloud.
Questo è ciò di cui abbiamo bisogno, cioè il trasferimento ricorsivo di dati da un agente all'altro senza procedura guidata, ma con il ritorno garantito dei risultati al master. Così che l'agente non poteva prendere un compito e smettere di lavorare senza completarlo, per esempio, perché il computer era spento e il ramo potenzialmente efficace della soluzione era rotto.
Cioè, per esempio, il compito di analizzare una partita di scacchi. La procedura guidata dispone i pezzi e genera le assegnazioni per il colore dei pezzi che devono muoversi ora, cioè un pezzo - un'assegnazione. Ogni agente, dopo aver ricevuto un compito per il suo pezzo, scarta le varianti non promettenti per ulteriori analisi, quando un pezzo non può muoversi, e forma nuove formazioni che vengono passate come compiti per i pezzi nemici. E così via, fino a quando non viene superato l'accoppiamento o lo stallo o la profondità di ricerca.
Se tale compito è affidato all'attuale implementazione del cloud, allora è possibile generare solo pacchetti di compiti per la ricerca completa. E il cloud non ha abbastanza agenti per questo, ed è improbabile che la procedura guidata abbia abbastanza memoria per fare il batch di tutti quei lavori. Perché non c'è un meccanismo di selezione delle varianti non promettenti. Per ogni nuova mossa analizzata di pezzi, il numero di compiti cresce esponenzialmente, ma anche una parte considerevole di essi viene scartata e non genera compiti senza senso, come nel completo overkill. E lo si può scoprire in prospettiva solo dopo essersi immersi in una certa profondità o larghezza dell'albero decisionale. E la profondità in questa implementazione della nuvola è 1, cioè dal master all'agente e viceversa.
Il mio punto è questo. Per il commercio, è necessaria anche l'implementazione della ricerca ricorsiva con l'eliminazione dei punti morti. È meglio cercare non solo un singolo estremo, ma un insieme di estremi locali (ce ne sono davvero molti). E lo spazio di ricerca per tutte le possibili varianti è astronomico, cioè nessun agente preso da tutte le reti di calcolo distribuite sarà sufficiente. Per fare questo, ad ogni passo enumeriamo i vicini più vicini di un punto (coordinate del punto - parametri di input dell'EA) ad una certa distanza da esso e distanziati da un certo valore angolare, per vedere se migliorano i risultati rispetto a quello attuale o no. Se uno di essi è peggiore o supera la profondità di ricerca, lo scartiamo. Se migliorano, ricorsivamente guardiamo oltre e formiamo un insieme di ulteriori compiti dai punti migliorati che distribuiamo agli agenti. Se un estremo viene trovato localmente (tutti i punti nel vicinato peggiorano solo il risultato attuale), restituiamo il risultato all'applicazione principale. Una volta che gli estremi sono stati identificati, vengono consegnati alla procedura guidata e analizzati ulteriormente con test forward.
Un tale compito non può essere risolto direttamente, poiché il numero di varianti è astronomico. Un algoritmo genetico inoltre non cerca gli estremi locali (si ferma vicino a quello globale anche nelle immediate vicinanze) e mostra solo i risultati intermedi, indipendentemente dal loro estremo. Per non dire che lo spazio di ricerca dell'algoritmo genetico e dell'algoritmo della forza bruta è limitato e discreto. È la ricerca del numero massimo di estremi locali ma veloce, cioè con il taglio delle generazioni non prospettiche di compiti dal master agli agenti e dall'agente agli altri agenti e con un raggio illimitato (ma in modo che le restrizioni possano essere impostate se necessario, ad esempio la profondità di ricerca in tali algoritmi è sempre limitata). Se il cloud implementasse il trasferimento ricorsivo del lavoro, il problema sarebbe risolto.