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
Ya está, la solución es sencilla: introducimos otra comprobación para cambiar el historial, así no se perderá nada y funcionará al 100%
Esto puede incluso utilizarse como un OnTrade() incompleto
Supongo que no soy lo suficientemente inteligente).
¿Cómo lo aplico?
Sólo hay un problema y es extremadamente raro, lo encontré hoy por primera vez en un par de años, puede haber sido antes, sólo que no lo noté
Me refería al cálculo de la suma de hash - cómo se puede añadir un nombre de carácter al valor de la suma de hash - calcular los valores de los códigos de letras que componen el nombre de carácter.
Ya está, la solución es sencilla: introducir otra comprobación de cambios en el historial, así no se perderá nada y funcionará al 100%
Aquí hay un extracto de mi artículo #3:
-------
Centrémonos más en la cantidad de hash como parte de la estructura.
Consideremos un billete. Añadir/eliminar una orden pendiente cambiará la cantidad total de ticks en la cuenta, activar una orden pendiente no cambiará la cantidad total de ticks en la cuenta.No basta con conocer el número de órdenes y posiciones para poder determinar con precisión lo que ha cambiado en la cuenta - una orden pendiente puede ser eliminada, y en este caso el número total de órdenes y posiciones en la cuenta cambiará. Pero... Una orden pendiente puede activarse y convertirse en una posición. En este caso, la cantidad total de órdenes y posiciones no cambiará (para cuentas de cobertura y MQL4) - el número de posiciones ha aumentado, pero el número de órdenes ha disminuido, por lo que la cantidad total sigue siendo la misma. Esto no funciona para nosotros.
Veamos el volumen total. Ha colocado o eliminado una orden pendiente - el importe total en la cuenta ha cambiado; la hemos abierto o cerrado, o hemos cambiado la posición - el importe total en la cuenta ha cambiado. Parece ser adecuado, pero una vez más, la activación de una orden pendiente no cambiará el volumen total.
Así que veamos una propiedad más de la posición - tiempo de su cambio en milisegundos: la apertura de una nueva posición cambiará el tiempo total de cambio de la posición, el cierre parcial cambiará el tiempo de cambio de la posición, la adición de volumen a una cuenta de compensación cambiará el tiempo total de cambio de la posición.¿Cuál de estos métodos es adecuado para determinar la ubicación precisa de los cambios en la cuenta? Billete + hora del cambio de posición. Vamos a comprobarlo:
En este caso, sin embargo, no añadí un símbolo a la suma de hash - no había precedentes para ello. Pero tengo que funciona en conjunto con el historial de cheques. Por lo tanto, debería funcionar sin errores. Sin embargo, lo comprobaré alguna vez.
La solución es sencilla: introducir otra comprobación de cambios en el historial, así no se perderá nada y funcionará al 100%.
Y sí, lo hará. Si el número de órdenes abiertas no cambia, entonces el número en el historial cambiará. (No me importan los pedidos pendientes - no los uso) Y no tendremos que pasar todo el día para coger un solo evento.
Y si el usuario ha recibido un mensaje de texto y ha decidido mostrar el historial en el terminal en lugar de todo sólo para el último mes, será una comprobación adicional con el intento de todas las órdenes, que no es fatal.
Parece ser una buena solución. Y sin hacer referencia a nada más que a lo que tenemos, que es una cuenta comercial y un terminal.
Este es un extracto de mi artículo #3:
-------
Vamos a detallar la cantidad de hash como parte de la estructura.
Considera un billete. Añadir/eliminar una orden pendiente cambiará la cantidad total de tickets en la cuenta, activar una orden pendiente no cambiará la cantidad total de tickets en la cuenta.No es suficiente conocer la cantidad de órdenes y posiciones que han cambiado en la cuenta para poder determinar con precisión este cambio - una orden pendiente puede ser eliminada y en este caso, la cantidad total de órdenes y posiciones en la cuenta cambiará. Pero... Una orden pendiente puede activarse y convertirse en una posición. En este caso, la cantidad total de órdenes y posiciones no cambiaría (para las cuentas de cobertura y MQL4) - el número de posiciones ha aumentado, pero el número de órdenes ha disminuido, por lo que la cantidad total sigue siendo la misma. Esto no funciona para nosotros.
Considera el volumen total. Ha colocado o eliminado una orden pendiente - ha cambiado el volumen total de la cuenta, ha abierto, ha cerrado o ha cambiado de posición - ha cambiado el volumen total de la cuenta. Parece ser adecuado, pero una vez más, la activación de una orden pendiente no cambiará el volumen total.
Así que veamos una propiedad más de la posición - tiempo de su cambio en milisegundos: la apertura de una nueva posición cambiará el tiempo total de cambio de la posición, el cierre parcial cambiará el tiempo de cambio de la posición, la adición de volumen a una cuenta de compensación cambiará el tiempo total de cambio de la posición.¿Cuál de estos métodos es adecuado para determinar la ubicación precisa de los cambios en la cuenta? Billete + hora del cambio de posición. Vamos a comprobarlo:
En este caso, sin embargo, no añadí un símbolo a la suma de hash - no había precedentes para ello. Pero tengo que funciona en conjunto con el historial de cheques. Por lo tanto, debería funcionar sin errores. Sin embargo, lo comprobaré alguna vez.
Solución gorda, todavía no es necesaria esa variante.
Gracias.
Decisión gorda, aún no es necesaria esa opción.
Gracias.
"Audaz" porque no se hizo para una solución local, sino como una parte de un reemplazo completo de OnTradeXXXX. Hay más obras con historia.
Y esto es una gran ventaja - tenemos datos listos para la búsqueda y clasificación de cualquier orden y posición en el programa (no necesitamos buscar órdenes y posiciones de nuevo para satisfacer las necesidades del programa - todo está ya en las listas). Otra ventaja es que el programa sabe qué orden originó la posición en MQL4, lo que no se puede hacer en las versiones mencionadas anteriormente.
Repito, la biblioteca está hecha para facilitar las cosas a quienes tienen demasiado tiempo y dinero para hacerlo todo por sí mismos. No insisto en nada, por supuesto :)
Y así es. Si el número de órdenes abiertas no cambia, el número en el historial sí lo hará. (No meimportan las órdenes pendientes - no las uso). Y no tienes que molestar a tu abuela con revisar las órdenes todo el día para coger un solo evento.
Y si el usuario ha recibido un mensaje de texto y ha decidido mostrar el historial en el terminal en lugar de todo el último mes, será una comprobación adicional con el intento de todas las órdenes, que no es fatal.
Parece ser una buena solución. Si tienes una cuenta de trading y un terminal, puedes usar sólo lo que tienes sin estar atado a nada.
Con el fin de no pasar por todo el día, se puede comprobar sólo cuando las condiciones que pueden conducir a los cambios, la apertura, el cierre de posiciones, es decir, centrarse en la consecución de los precios que el Asesor de Expertos utiliza para abrir, TP, SL. Bueno, depende de la lógica del Asesor Experto, ya sabes que es más barato.
Para evitar pasar por todo el día, puede comprobar sólo cuando las condiciones que pueden conducir a un cambio, la apertura, el cierre de una posición se han cumplido, es decir, para centrarse en la consecución de los precios que el Asesor de Expertos utiliza para abrir, TP, SL. Bueno, sí, depende de la lógica del Asesor Experto, ya sabes que es más barato.
Un EA (en un ordenador, en un continente) comercia. La otra (en otro ordenador, en otro continente) se ocupa de sus funciones. Ya se ha encontrado una solución.
Te agradecería que me dieras algún ejemplo reproducible (sin sondear el historial de operaciones).
Esto es lo que ha surgido (aunque está fuera de tema aquí, pero se pidió aquí).
Cortar para vivir. Sin compatibilidad con MT4 (por supuesto), sin manejo de errores, etc.
El comercio es primitivo, abre la COMPRA, cierra en el SL/TP. El único punto es demostrar OnTradeTransaction() frente a "sondear el servidor".
A mí me costó 2,34s frente a 3,06s pasar en el intervalo dado. La diferencia es pequeña debido a la baja carga de las funciones del servidor (sólo una posición, no hay comprobación de magik y símbolo). En la EA real la diferencia será mucho mayor. La diferencia se suavizará ligeramente mediante el cálculo de las señales y la adición de trailing stops, pero no es necesario hacerlo en cada tick. Mi ATR se calcula en M1, pero para 6 horas (es decir, hay espacio para ampliar el TF). Y el trailing y el Breakeven se calculan en H3. Todo depende de la estrategia.
Estás irremediablemente atrasado.
Estos eventos están garantizados desde hace mucho tiempo.
Supongamos que se produce un evento en OnTradeTransaction() tras el cual se debe realizar alguna acción, pero se produce un error en el primer intento de realizar esta acción. ¿Qué hacer? Obviamente, debe repetirse, y para ello es necesario guardar en algún lugar los datos sobre la necesidad de repetir esta acción - lo más probable es que estos datos se guarden en las variables globales habituales del Asesor Experto o en funciones estáticas. Y de repente tuve que reiniciar el terminal... los datos han desaparecido.
Y cuando se analiza la situación actual y la historia, nada va a ninguna parte.