Errores, fallos, preguntas - página 2450
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Sin embargo, dice exactamente lo mismo sobre los tropiezos con las macros. No obstante, lo comprobaremos, por supuesto.
El desarrollo de este proyecto todavía tiene un enorme potencial, sobre todo en lo que se refiere a la mejora del lenguaje utilizando sus propios recursos, porque muchas cosas en MQL no se han implementado todavía y muchas cosas funcionan mal (bugs) y los desarrolladores, según tengo entendido, no tienen planes de mejorar nada en el propio lenguaje.
Para procesar las macros tengo que implementar una capa adicional en algún lugar cerca del principio de toda la cadena - describir la gramática de las macros, analizarlas en el código fuente einterpretarlas (obtener el resultado fuente/valor para cada macro). Esto es complicado, y la aplicación sólo es necesaria para algunos programadores de MQL, por lo que no hay desarrollo.
En cuanto al uso de hash para identificar los cambios en los productos, no creo que sea una solución (o no tengo ni idea de qué caso de uso estamos hablando). Por lo general, se necesita un año o dos después de la generación de algún archivo ex para entender qué versión tenía un módulo incrustado en particular y su fuente. Para ello, es probable que tenga que vincular el proceso de construcción con los sistemas de control de versiones. El hashtag no es una opción.
Ayúdame con OnTradeTransaction(). ¿Es normal el comportamiento descrito a continuación? Lo he comprobado en el probador - es así :( ¿Y en una cuenta "real"?
OnTick() tiene un bucle que cierra las posiciones en orden.
La función OnTradeTrancaction() calcula el número de posiciones abiertas.
El Asesor Experto lo hace así: primero cierra el bucle hasta el final, luego va a OnTradeTransaction y realiza los cálculos en el mismo orden.
En otras palabras, no
а
es decir, funciona de forma secuencial en lugar de en paralelo.
Si lo descrito anteriormente es normal, resulta que OnTradeTransaction() puede ser utilizado con seguridad sólo en Asesores Expertos que abren/cierran una sola orden. Si hay una cuadrícula o una cuadrícula multisímbolo (o una cuadrícula multisímbolo, que es donde se encuentra :) ) - el algoritmo se rompe.
Cita de la documentación
Una solicitud de operación enviada manualmente desde el terminal o a través de las funciones OrderSend()/OrderSendAsync() puede generar varias operaciones consecutivas en el servidor de operaciones. Además, el orden de llegada de estas transacciones al terminal no está garantizado, por lo que no podemos construir nuestro algoritmo de negociación esperando la llegada de una transacción comercial tras otra.
En consecuencia, todo se calculará, pero no en la secuencia esperada.
¿Puede explicar por qué decidió contar el número de posiciones en OnTradeTrancaction()? Si el cálculo no se organiza correctamente, no podemos descartar que haya operaciones innecesarias. Al fin y al cabo, si se cierran varias posiciones en el bucle, no es necesario recalcularlas todas después de cerrar cada posición. Basta con contarlos una vez que el bucle haya terminado. O bien, organizar en OnTradeTrancaction() de tal manera que la cantidad aumente en 1 cuando se establezca el tipo IN, y disminuya cuando se establezca el tipo OUT. E incluso en este caso, si la posición no está cerrada del todo, hay que tenerlo en cuenta.
¿Puede explicar por qué decidió contar el número de posiciones en OnTradeTrancaction()?
Si se cuenta con cada tic - es intensivo en recursos, especialmente notable en el probador de estrategias. ¿No sería más correcto contar sólo en el evento de Comercio, es decir, cuando algo en la lista de posiciones abiertas realmente cambia? Con OnTradeTransaction(), es más fácil controlar la intervención del usuario en el EA. (Hay algunos precedentes :)
En este robot estaba probando la posibilidad de cerrar la parrilla por el esquema: Pérdida + beneficio > X , luego cerrar ambos (normalmente en diferentes símbolos). Pero se produce un fallo, porque aunque están cerradas, el probador no se da cuenta y pasa a la siguiente iteración, "emparejando" por error las existentes con las ya cerradas. Es decir, he tenido que añadir un recálculo después de cada cierre.
Tengo el recálculo con un contador a cero y sobre todos los abiertos primero, no +1 / -1
Cita de la documentación
Estoy de acuerdo, era demasiado arriesgado usar OnTradeTransaction() inicialmente. De hecho, probablemente lo rechazaría en los casos en que las peticiones no son asíncronas, sólo hay problemas por ello.
Para una red multisímbolo, la asincronía es buena. Por eso elegiría la segunda opción.
Ya estoy pensando en esa dirección ;)
***
En este robot he probado la posibilidad de cerrar parrillas según el esquema: pérdida + beneficio > X , luego cerrar ambas (normalmente en símbolos diferentes).
***
Si usted sabe que quiere cerrar exactamente estas dos posiciones, es mejor memorizar los tickets de estas posiciones, y cerrarlas hasta que las cierre (ATENCIÓN: no hay while y Sleep - dar órdenes de cerrar, salir de OnTick, comprobar si hay más posiciones con estos tickets - si es así, tratar de cerrar de nuevo y salir de OnTick).
Si usted sabe que necesita cerrar exactamente estas dos posiciones, es mejor recordar los tickers de estas posiciones y cerrarlas hasta que las cierre (NOTA: no hay while y Sleep - dar órdenes de cerrar, salir de OnTick, comprobar si hay más posiciones con estos tickers - si hay, entonces tratar de cerrar de nuevo y salir de OnTick).
Esta es una idea valiosa. Tal vez el OnTick() forma un array con el ticket y trata de cerrarlo una vez, y OnTimer() comprueba si hay más y cierra, si lo hay.
Pueden pasar varios minutos entre ticks, así que pasemos la tarea al temporizadorUna idea valiosa. Tal vez sea así: OnTick() genera un array con los tickets e intenta cerrarse una vez, mientras que OnTimer() comprueba si todavía están presentes y se cierra si lo están.
Entre un tic y otro pueden pasar varios minutos, así que pasemos la tarea a un temporizadorAbandonaría TODOS los tiempos, Sleep y OnTimer para la tarea de cerrar posiciones. Haría lo siguiente: disparar órdenes de cierre - salida OnTick, en el siguiente tick comprobaría si las posiciones con entradas necesarias siguen vivas - de nuevo disparar órdenes de cierre, y así sucesivamente a través del bucle vía entrada/salida a OnTick.
La lógica es la siguiente: el cierre de una posición es la primera prioridad, por lo que el bucle de cierre está al principio de OnTick. Y la formación de una matriz de billetes cerrados puede situarse en cualquier parte deTick, incluso al final.
***
Pueden pasar varios minutos entre ticks, así que pasemos la tarea al temporizadorPor lo tanto, no hay nada que podamos hacer: sólo tenemos que esperar una nueva garrapata.
OnTick() genera un array con los tickets e intenta cerrarlos una vez, y OnTimer() comprueba si aún están presentes y se cierra si lo están.
Otra opción (para el mundo real - esto es lo mejor) es ejecutar el EA en un entorno virtual (hay una ejecución perfecta), y en el mundo real sólo la sincronización con el virtual.
Así que no hay nada que puedas hacer, sólo esperar al siguiente tic.
Si, por ejemplo, hay un fallo en la red, esperar al siguiente tick es una oportunidad perdida para cerrar.
Si, por ejemplo, hay un fallo en la red, esperar al siguiente tic es perder la oportunidad de cerrar.
Fallo de la red == desconexión? Si no hay Internet, no se puede cerrar ni abrir nada: ¿qué clase de oportunidad perdida es esa?
En general, si el sistema de comercio es muy sensible a cada estornudo (un fallo de conexión o algo así) - entonces que se joda tal sistema de comercio.