dll e mercato. - pagina 3

 

О. Suppongo che sia ora e che chi ha iniziato l'argomento abbia qualcosa da dire. È riscaldato.

In breve. Abbiamo bisogno di un meccanismo, sottolineo bidirezionale, per lo scambio di informazioni tra owl su agente (locale per ora, ma tenetevi forte MQ, più tardi gli utenti chiederanno anche quelli remoti) e owl su grafico.

Gli orizzonti sono paragonabili a... Gli orizzonti sono paragonabili a... lancio di nuvola e combinazione OCL e mql5.

Darò alle menti curiose l'opportunità di scaldarsi ancora di più. All'esperto un saluto speciale e complimenti al granchio per aver cercato di inventare la possibilità di usare i plugin per gli esperti.

 
joo:

Orizzonti - paragonabile a... il lancio del cloud e la combinazione di OCL e mql5.

Andrei, hai tutto pronto? A che punto dell'implementazione?

se la domanda riguarda solo l'accesso alla dll - forse potresti dichiarare il tuo problema per intero, così Renat potrebbe sentire i tuoi orizzonti... ...e forse l'MC suggerirà una soluzione.

 
sergeev:

Se c'è solo una domanda sull'accesso alla dll, forse potresti dichiarare il tuo problema per esteso, così Renat potrebbe sentire i tuoi orizzonti... e forse MK potrebbe suggerire una soluzione.

Andiamo, è ridicolo. Affonderà nello stesso modo in cui ha fatto (finora, con il problema di OpenCL con i servizi) con OpenCL.

Sembra wow, ma in realtà nessuno ne ha bisogno tranne 3,5 persone.

 
TheXpert:

Sembra essere wow, ma in realtà nessuno ne ha bisogno tranne 3,5 persone.

Quindi stiamo parlando di Horizons.

Se la prospettiva si presenta (Joo cercherà di portare il progetto al MC con colori brillanti), si incontreranno e faranno le funzionalità necessarie per esso.

 
sergeev:

quindi si tratta di Horizons, vero?

Se si presenta la prospettiva (Joo cercherà di far conoscere ai MC il progetto a colori), li incontreranno e faranno le funzionalità necessarie per questo.

Horizons è semplice lì (discusso 100 volte), usando qualche tipo di funzionalità di comunicazione per far scivolare il clod loro GA.

ZZY Ma gli orizzonti della funzionalità di collegamento stessa possono essere più ampi.

 
Urain:

Ma gli orizzonti della funzionalità di collegamento stessa possono essere più ampi.

Ecco di cosa sto parlando.

 

Lo dici bene. Ho parlato di OCL che si è assestato a tempo debito (e improvvisamente si è alzato dopo qualche tempo) e di ciò che è stato discusso 100 volte - trasferimento di informazioni agli agenti e "ristrettezza di campo" nel numero di parametri ottimizzati.

Ho pensato di aggiungere la funzionalità necessaria (sottolineo - per mezzo di MQL5) di МТ5 e così guadagnare un po' di soldi (perché, nessuno ha crediti o mutui), ma no - non c'è modo.

Questo articolo limita il numero di parametri ottimizzati.

2. Monocriterionalità dell'ottimizzazione (scusate se ho coniato nuove parole).

Incapacità di gestire 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! Ma di nuovo, ci sono dei colli di bottiglia, come indicato dal titolo dell'argomento. Se appare la possibilità di trasmissione bidirezionale, i problemi sono risolti. Non ci sarà bisogno di implementare tutti e tre i punti - tutto si prenderà cura di se stesso.

 
sergeev:

Andrei, sei pronto? A che punto dell'implementazione?

Se c'è solo una domanda sull'accesso alla dll - forse potresti raccontarci il tuo problema per intero, così Renat potrebbe sentire i tuoi orizzonti... ...e forse l'MC potrebbe proporre una soluzione.

È "pronto" .... No, non lo è. Mi ci vuole sempre molto tempo per fermentare ma si indurisce rapidamente.

Sì, è pronto, è pronto al 95%.

La sfida (senza entrare nei dettagli):

1. Abbiamo bisogno di un meccanismo stabilito di scambio di informazioni bidirezionale tra il "server" sul grafico e il "client" sull'agente (necessario prima di tutto)

2. Necessità di un meccanismo interno che permetta di eseguire il tester/ottimizzatore interno dal "server" sul grafico (necessario ma non critico)

Questo è fondamentalmente tutto.

Orizzonti:

1. Non c'è bisogno di inventare un linguaggio di controllo per l'ottimizzazione degli script di MQ (gli utenti l'hanno chiesto tempo fa)

2. il cloud inizierà ad essere usato per compiti non solo legati al commercio (e questo è un pubblico molto più grande di adesso).

3. Non c'è bisogno di lottare con la GA interna per limitare il numero di parametri di opt-in.

4...

Si può continuare senza enumerare ulteriormente.

О! Ho dimenticato di aggiungere. L'ambiente di mercato creato in un tester interno è costoso. Non importa quanto sia sofisticato il tester fatto in casa (calcolatrice), non si avvicinerà mai al tester dello staff in termini di capacità e qualità dei test. Ci sono molte cose da considerare - lo spread, lo swap, il... Ed è un lavoro da scimmie correggere la calcolatrice per ogni compito. Voglio usare il tester/ottimizzatore standard.

 
sergeev:

quindi per favore aggiungete la modalità server MQL a pips. è permesso? o anche la sicurezza sarà compromessa?

Mi associo. Ho anche un progetto che utilizza i pips appesi.
 
joo:

Tutte le chiamate dll sono vietate nel mercato.

OK. Che ne dite di fare quanto segue:

1. Il prodotto stesso viene immesso sul mercato.

2. La parte di codice responsabile di fare riferimento alla dll (win api), metterla in una libreria e metterla nel codebase. Il codice può anche essere in codice sorgente.

Il punto principale è che è necessario usare FileMapping nel prodotto, è impossibile senza di esso.

Signori, state facendo la cosa sbagliata. Pensate a come creare un prodotto nel quadro di MQ. Se non può essere creato con i mezzi di un MQL, significa che non è un prodotto per il Marketplace, e non ha posto in esso. Crea soluzioni semplici e intuitive, integrate in modo trasparente con l'ecosistema MetaTrader. I prodotti che hanno un "proprio modo", diverso dall'ambiente generale integrato MQ non hanno futuro.