![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Sono tutte sciocchezze. Non è che stai facendo girare gigabyte tutto il giorno.
Il sistema operativo e i processi di sistema hanno ordini di grandezza maggiori da fare con il disco.
C'era una domanda
komposter:
... o c'è qualche software da controllare?
...E per quanto ne so, non è la dimensione, ma la posizione del file.
Se il file permanentemente riscrivibile è sempre in un posto (si può riparare lo swap lì) - l'unità inizierà fisicamente a sgretolarsi proprio in questo posto.
(La deframmentazione settimanale su un programma risolverà il problema).
Comunque, non è davvero stupido.
Sono tutte sciocchezze. Non è che stai facendo girare gigabyte tutto il giorno.
Il sistema operativo e i processi di sistema lavorano molto di più con il disco.
Ciao Renat, vorrei chiarire la mia domanda sulla nozione di sandbox di file in MT e quale ruolo gli viene assegnato.
File sandbox è un permesso per Expert Advisor di scrivere o leggere qualcosa solo in un luogo limitato.
Questo è fatto esplicitamente per la sicurezza dei dati informatici.
Significa che restringiamo l'Expert Advisor in una sandbox, in modo che sia impossibile per un Trojan di FileOpen qualsiasi dei dati privati del cliente al di fuori della sandbox.
Altrimenti, richiederebbe ilpermesso esplicito di una DLL per l'Expert Advisor.
OK.
E se permettete all'Expert Advisor di scrivere non su disco, ma almeno su file in memoria?
Perde la sicurezza dell'utente / MK?
E se permettiamo all'Expert Advisor di scrivere non su disco, ma almeno su file in memoria?
Questo perde la sicurezza dell'utente / MC?
Che bisogno c'è di questo?
Abbiamo dato file, pip e variabili globali, tutti gli esperti su un terminale possono comunicare tra loro normalmente e senza problemi. Ma il compito di "comunicare con qualcuno all'esterno in modo libero" non è davanti a noi. Al contrario, il nostro compito è quello di non far mai uscire le informazioni.
ps: cercate dei workaround al metodo di comunicazione tra terminali - non lo faremo.
Ok, grazie.
e altre domande:
1. si possono inserire piani di sviluppo - trasferendo informazioni dall'EA agli agenti locali durante un test?
2. un'applicazione marketplace che usa Pipes sarà certificata?
1. si possono inserire piani di sviluppo - trasferendo le informazioni dall'esperto agli agenti locali durante il test?
Per cominciare, giustificate la necessità di questo tipo di intervento.
A nostro parere, è metodologicamente scorretto passare alcune informazioni aggiuntive all'EA testato oltre a quelle fornite dal tester (set di parametri e file di dati, e anche indicatori personalizzati che ora forniamo su richiesta).
A proposito, gli agenti locali hanno accesso alla cartella condivisa di tutti i terminali client su questo computer.
Per cominciare, giustificate la necessità di questo tipo di intervento.
A nostro parere, è metodologicamente scorretto dare qualsiasi informazione aggiuntiva al tester oltre a ciò che il tester fornisce (set di parametri e file di dati, e anche indicatori personalizzati che ora forniamo su richiesta).
come esempio, il loro GA
Forum sul trading, sistemi di trading automatico e test di strategie di trading
dll e mercato.
joo, 2013.04.18 21:51
Hai ragione. <...> e su ciò che è stato discusso 100 volte - il trasferimento di informazioni agli agenti e la "ristrettezza di campo" nel numero di parametri ottimizzati.
<...>1. Limitare il numero di parametri ottimizzabili.
2. Monocriteri di ottimizzazione (scusate la nuova combinazione di parole).
Impossibilità di controllare il processo di evaporazione della sabbia.
Questo non è affatto un rimprovero agli sviluppatori. Al contrario - è un volo di fantasia per gli sviluppatori di programmi MQL5!
<...> se apparirà la trasferibilità bilaterale - i problemi sono risolti. Non ci sarà bisogno di implementare tutti e tre gli elementi di cui sopra - tutto crescerà da solo.
A proposito, gli agenti locali hanno accesso alla cartella condivisa di tutti i terminali client su questo computer.
Per informazione - i nostri server cloud MQL5 Cloud Network normalmente generano circa 5 terabyte di traffico al giorno , a volte fino a 10 Tb.
Se si lascia entrare in questa rete un traffico personalizzato illimitato con la garanzia di arrivare ad ogni agente, allora la rete non si sentirà molto bene.
1. Oserei dire che il 99,9% del traffico ora consiste in dati storici.
2. Indirizzare ogni agente non è affatto necessario. Vi mostrerò come qui sotto.
...
Abbiamo dato file, pip e variabili globali,tutti gli esperti su un terminale possono comunicare tra loro normalmente e senza problemi. Ma il compito di "comunicare con qualcuno all'esterno in modo libero" non è davanti a noi. Al contrario, il nostro compito è quello di non far mai uscire le informazioni.
ps: Non c'è bisogno di cercare workaround al metodo di comunicazione tra terminali - non lo faremo.
Non so nessuno, ma prima ho detto chiaramente che abbiamo bisogno di uno scambio di informazioni a due vie tra i programmi sulla carta e gli agenti. L'esterno non è necessario. Cioè, all'interno di un solo terminale (e degli agenti che gestisce). Nessun'altra copia in esecuzione dei terminali (con scopi diversi) è coinvolta nello scambio di informazioni.
stringo:
Crediamo che sia metodologicamente scorretto passare qualsiasi informazione aggiuntiva a un Expert Advisor sotto test oltre a quella fornita dal tester(un set di parametri e file di dati, e indicatori personalizzati).
A proposito, gli agenti locali hanno accesso alla cartella condivisa di tutti i terminali client su questo computer.È esattamente su richiesta. Questo non è l'indirizzo dell'agente con il trasferimento delle informazioni ad esso, ma l'agente stesso prenderà un pacchetto indirizzato solo ad esso (e di conseguenza solo inviare questo pacchetto dal tester alla nuvola).
Quindi, avete bisogno di qualcosa come questo:
dove expert_opt_param è una proprietà standard di programmi come EA.
Se CustomData risulta essere non inizializzato, il passaggio viene saltato.
Di conseguenza, il pacchetto di dati indirizzato all'agente deve essere pre-creato dall'Expert Advisor sul grafico in modo che l'agente possa riceverlo:
dove bool OptDataSend() - funzione standard del linguaggio
doppio CustomData - dati utente
int AgentId - id dell'agente, in altre parole - numero di passaggio in modalità "forza bruta" dell'ottimizzatore.
E - come verrà infranta la sicurezza in questo caso? Tutto rigorosamente e in serie, all'interno di un unico sandbox terminale.
all'interno di un EA è risolto da CFastFile (nella cartella MQH\Ctrl, cercatelo).
ma come il test ha mostrato l'uscita bitmap al grafico rispetto agli oggetti è una perdita di tempo. Regole di CView :)
Suppongo che il test non sia molto corretto.
In primo luogo, OpenCL non ha partecipato alla creazione di bitmap (discutibile, naturalmente, per i grandi volumi può essere un vantaggio per quelli piccoli, ma è dubbio),
in secondo luogo scrivere su file e leggere da file sono molto più lenti che accedere alla memoria (e qui con frequenti ricalcoli, per esempio 24 volte al secondo le maggiori perdite, scrivere e leggere file 24 volte al secondo e misurare il tempo), questa è solo la perdita di 1-th bitmap vs 26 etichette.
Ecco perché sono a favore dei file virtuali. È una soluzione versatile. Si può usare in molti algoritmi.
Urain:
Suppongo che il test non sia molto corretto.
Scrivere e leggere da un file è un ordine di grandezza più lento
Non c'è stata alcuna scrittura su file. era ResourceCreate.