dll y el mercado. - página 3

 

О. Supongo que ya era hora y que el iniciador del tema tenía algo que decir. Se calienta.

En resumen. Necesitamos un mecanismo, subrayo lo de bidireccional, para el intercambio de información entre owl on agent (local por ahora, pero prepárense MQ, más adelante los usuarios pedirán también los remotos) y owl on chart.

Los horizontes son comparables a... Los horizontes son comparables a... lanzar la nube y la combinación OCL y mql5.

Daré a las mentes inquietas la oportunidad de calentarse aún más. Al Experto un saludo especial y kudos al cangrejo por intentar inventar la posibilidad de usar plugins para expertos.

 
joo:

Horizons - comparable a... lanzar la nube y la combinación de OCL y mql5.

Andrei, ¿tienes todo listo? ¿En qué fase de implementación?

si la pregunta es sólo sobre el acceso al dll - tal vez podría declarar su problema en su totalidad, por lo que Renat podría sentir sus horizontes... ...y tal vez el MC sugiera una solución.

 
sergeev:

Si sólo se trata de una pregunta sobre el acceso a los dlls, tal vez podrías exponer tu problema en su totalidad, para que Renat pueda palpar tus horizontes... y tal vez MK sugiera una solución.

Vamos, eso es ridículo. Se hundirá de la misma manera que lo hizo (hasta ahora, con el problema de OpenCL con los servicios) con OpenCL.

Parece una maravilla, pero en realidad nadie lo necesita, salvo 3,5 personas.

 
TheXpert:

Parece ser wow, pero en realidad nadie lo necesita excepto 3,5 personas.

Así que estamos hablando de Horizons.

Si surge la posibilidad (Joo intentará llevar el proyecto al MC con colores brillantes), se reunirán y harán la funcionalidad necesaria para ello.

 
sergeev:

Así que se trata de Horizons, ¿no?

Si surge la posibilidad (Joo intentará que los MC conozcan el proyecto con colores vivos), se reunirán con ellos y harán las funciones necesarias para ello.

Horizontes es simple allí (discutido 100 veces), utilizando algún tipo de funcionalidad de comunicación para deslizar el clod su GA.

ZZY Pero los horizontes de la propia funcionalidad de enlace pueden ser más amplios.

 
Urain:

Pero los horizontes de la propia funcionalidad de la vinculación pueden ser más amplios.

A eso me refiero.

 

Lo dices bien. He hablado de la OCL que se ha asentado a su debido tiempo (y de repente ha subido después de algún tiempo) y de lo que se ha discutido 100 veces - la transferencia de información a los agentes y la "estrechez del campo" en el número de parámetros optimizados.

He estado pensando en añadir la funcionalidad necesaria (subrayo - por medio de MQL5) de МТ5 y así ganar algo de dinero (por qué, nadie tiene créditos o hipotecas), pero no - no hay manera.

Este artículo limita el número de parámetros optimizados.

2. Monocriterio de optimización (perdón por acuñar nuevas palabras).

Incapacidad para gestionar el proceso de evaporación de la arena.

Esto no es un reproche a los desarrolladores, en absoluto. Por el contrario, ¡es una fantasía para los desarrolladores de programas MQL5! Si aparece la posibilidad de una transmisión bidireccional, los problemas se solucionan. No será necesario aplicar los tres puntos: todo se arreglará por sí solo.

 
sergeev:

Andrei, ¿está todo listo? ¿En qué fase de implementación?

Si sólo hay una pregunta sobre el acceso a la dll - tal vez usted podría decirnos acerca de su problema en su totalidad, por lo que Renat podría sentir sus horizontes ... ...y tal vez el MC podría proponer una solución.

Está "listo" .... No, no lo está. Siempre tarda en fermentar pero se endurece rápidamente.

Sí, está listo. Está listo en un 95%.

El reto (sin entrar en detalles):

1. Necesitamos un mecanismo establecido de intercambio de información bidireccional entre el "servidor" del gráfico y el "cliente" del agente (necesario en primer lugar)

2. Necesita un mecanismo interno que le permita ejecutar el probador/optimizador interno por el "servidor" en el gráfico (necesario pero no crítico)

Eso es básicamente todo.

Horizontes:

1. No es necesario inventar el lenguaje de control de optimización de scripts de MQ (los usuarios lo pidieron hace tiempo)

2. la nube empezará a utilizarse para tareas no sólo relacionadas con el comercio (y este público es mucho mayor que el actual).

3. No es necesario luchar con el GA interno para limitar el número de parámetros de opt-in.

4...

Se puede seguir sin enumerar más.

¡О! Se me olvidó añadir. El entorno de mercado creado en un probador interno es caro. Por muy sofisticado que sea el probador casero (calculadora), nunca se acercará al probador del personal en cuanto a capacidades y calidad de las pruebas. Hay que tener en cuenta muchas cosas: el diferencial, el canje, la... Y es un mero trabajo de mono corregir la calculadora para cada tarea. Quiero utilizar el probador/optimizador estándar.

 
sergeev:

por favor, añade el modo de servidor MQL a pips. ¿está esto permitido? o ¿también se verá comprometida la seguridad?

Me uno a ellos. También tengo un proyecto con pips colgando.
 
joo:

Todas las llamadas dll están prohibidas en el mercado.

DE ACUERDO. ¿Qué tal si hacemos lo siguiente?

1. El producto en sí se coloca en el mercado.

2. La parte del código responsable de referirse a la dll (win api), la puso en una biblioteca y la puso en codebase. El código puede ser incluso en código fuente.

El punto principal es que es necesario utilizar FileMapping en el producto, es imposible sin él.

Señores, se están equivocando. Piense en cómo crear un producto en el marco de MQ. Si no se puede crear con los medios de un MQL, significa que no es un producto para el Mercado, y no tiene lugar en él. Cree soluciones sencillas e intuitivas, integradas de forma transparente en el ecosistema de MetaTrader. Los productos que tienen "su propio camino", diferente del entorno general integrado de MQ, no tienen futuro.