Cualquier pregunta de los recién llegados sobre MQL4 y MQL5, ayuda y discusión sobre algoritmos y códigos - página 1857
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
recoger (o recordar/saber) todo, ordenar por tiempo de apertura. Eso es, pero la hora de apertura no cambia :-)
Si la lógica del EA contiene más de una orden (por ejemplo, una cuadrícula), tendrá que recordarlas todas. O tendrás que ir más despacio intentando recordarlos todos en cada estornudo
¿Puedes decirme si el beneficio en el historial está marcado con un círculo azul, incluye la comisión y el swap?
Se obtendrá la hora y el precio de la orden a seleccionar mediante la función OrderSelect().
Que yo sepa no se menciona en la documentación. Así que es mejor ir a lo seguro. No empeorará las cosas.
Ha habido quejas de que este procedimiento requiere mucho tiempo de la CPU.
En cuanto al SL y el TP, se calculan. Y, por tanto, deberían normalizarse definitivamente según el valor de los dígitos.
Aquí, en cualquier caso, es necesario averiguar la intención del autor.
Ha habido quejas de que este procedimiento requiere mucho tiempo de la CPU.
La normalización de los LS y AT calculados lleva el doble de tiempo. Pero yo no diría que tiene tanto impacto en la optimización y menos aún en las pruebas de los robots.
La documentación dice en blanco y negro que hay que normalizar los niveles calculados. ¿Y cuál podría ser la "intención del autor"? ¿Qué no es normalizar el SL y el TP? No voy a discutir contigo porque los hechos son evidentes.
Si se trata de una pregunta, se obtiene el ticket del primero, se selecciona el primero y los siguientes que tengan el ticket !=primero.
Se necesita el doble de tiempo para normalizar los LS y los AT calculados. Pero yo no diría que tiene tanto impacto en la optimización y menos aún en las pruebas de los robots.
Así es, y ha habido preguntas en este foro sobre la simplificación de este procedimiento.
No conozco ningún caso en el que los precios recibidos que no están normalizados hayan causado un error.
Como referencia:
¿Y cuál podría ser la "intención" del autor en este caso? ¿Que no se normalice la SL y la TP? No voy a discutir contigo porque los hechos son evidentes.
Una idea de última hora podría ser el redondeo. En teoría esto no se hace, pero así en el caso de redondear a menos dígitos , en caso de que los precios sean correctos para SL y TP, funcionará. Así que hay que averiguar qué se pretende en cualquier caso.
Traté de resolverlo yo mismo, más o menos añadir en el código de este indicador, pero no funciona. Aunque se compila y no hay errores.
¿Tal vez deberíamos usar iCustom y manejar el indicador?
Si trata de identificar el problema y luego describe con más detalle qué es exactamente lo que no puede hacer, la probabilidad de obtener una respuesta será mucho mayor.
Se necesita el doble de tiempo para normalizar los LS y los AT calculados. Pero yo no diría que tiene tanto impacto en la optimización, y mucho menos en las pruebas de los robots.
No sólo eso, sino que algunas personas descuidan comprobaciones tan sencillas como
pensando que puede consumir mucho tiempo de la CPU :)
Pero en realidad son funciones como ObjectCreate y ObjectDelete las que consumen tiempo del procesador. Si un programador tiene, por ejemplo, una matriz de objetos gráficos y ésta se borra y vuelve a crear en cada tic, hay que hacer algo al respecto. Mientras que las comprobaciones y los cálculos simples son de poco tiempo. Por eso, muchos programadores buscan en el lugar equivocado.
Así es, y ha habido preguntas en este foro sobre la simplificación de este procedimiento.
No sé a quién afecta ni a qué afecta. Nunca he tenido problemas con NormaizeDouble. En todo caso, cualquier código afecta a la velocidad de una aplicación. Pero si todo es tan crítico, puede dejar vacíos los manejadores OnTick o OnCalculate. En este caso, su aplicación será volar en absoluto. :) O reescribir las funciones en ensamblador, compilar en DLL y conectarlas a la aplicación.
No conozco casos en los que los precios recibidos y no normalizados hayan causado un error.
Pero la documentación sí. Y no hace caso a los consejos de la documentación. Como quieras. Eso es cosa tuya. Creo que es obvio y no voy a discutir contigo sobre ello, ¡lo diré de nuevo!
El redondeo puede ser una idea tardía.
No es redondear, es cortar todo lo que tenga más de dos decimales.
Tampoco conozco la idea del autor. Pero no lo necesito. Creo que puede resolverlo por sí mismo.