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
splxgf:
¿Cómo se puede "aligerar" este ciclo? Se necesita mucho tiempo para contar.
O mejor aún, así:
También está la idea de generar una matriz de valores altos y bajos. ¿Tal vez esto acelere un poco las cosas?
el pedido se selecciona https://docs.mql4.com/ru/trading/OrderSelect - bucle o selección por ticket
entonces la función Order*() busca el parámetro de orden correspondiente
Perdón por las preguntas tan contundentes, pero:
Si utilizamos MODE_HISTORY como fuente de datos para la selección en la función OrderSelect , es decir, la orden se selecciona entre las órdenes cerradas y eliminadas, entonces ¿cómo encontramos el número de la orden que se cerró por última vez? ¿Cómo se numeran estos pedidos en el programa? ¿Es del último al primero o viceversa?
Lo siento, por supuesto, por las preguntas estúpidas, pero:
si la fuente de datos en la función OrderSelect es MODE_HISTORY, es decir, la orden se selecciona entre las órdenes cerradas y eliminadas, ¿cómo puedo encontrar el número de la orden que se cerró por última vez? ¿Cómo se numeran estos pedidos en el programa? ¿Es del último al primero o viceversa?
hay muchas preguntas de este tipo en internet
http://forum.alpari.ru/showthread.php?t=27708
Perdón por las preguntas tontas, pero:
si se utiliza MODE_HISTORY en la función OrderSelect como fuente de datos para la selección, es decir, la orden se selecciona entre las órdenes cerradas y eliminadas, ¿cómo puedo encontrar el número de la orden que se cerró por última vez? ¿Cómo se numeran estos pedidos en el programa? ¿Es del último al primero o viceversa?
La función para encontrar la última de las cerradas es similar a la función para encontrar la orden con el máximo tiempo de cierre
muchas de estas preguntas ya se han formulado en Internet
http://forum.alpari.ru/showthread.php?t=27708
¡О! Lo he encontrado, gracias:
OrderSelect(HistoryTotal()-1,SELECT_BY_POS,MODE_HISTORY);
Así es, ¿no?
¿Cómo "aliviar" este ciclo? Se necesita mucho tiempo para calcular.
Spellbound:
La lógica es que el precio está más a menudo fuera de las barras históricas que dentro.
INS = Interior.
He comprobado la exactitud del código en un folleto. No he comprobado la velocidad del código. Pero estoy seguro de que las variables booleanas dan una buena ventaja.
Spellbound:
La lógica es que el precio está más a menudo fuera de las barras históricas que dentro.
INS = "Inside".
P.D.: He comprobado la corrección del código en un papel. No he comprobado la velocidad del código. Pero estoy seguro de que las variables booleanas dan una buena ventaja.
Sí.
Hay que ser muy retorcido para convertir tres líneas claras de código en un código difícil de entender.
Si se te ocurrió dividir el cheque iLow, iHigh, podías haberlo dividido enseguida:
y no toques nadaEncontrar los niveles de resistencia de un conjunto así no es un problema. Añade nuevas barras y elimina las antiguas al mismo tiempo. Y la obtención de información de la misma es de dos ciclos con una condición o ArrayMaximum dará el valor requerido a la vez.
Sí.
Hay que ser tan retorcido como para convertir tres líneas de código claras en un código difícil de entender.
Si se te ocurriera separar el cheque iLow, iHigh, podrías haberlo dividido enseguida:
y no te metas con nadaUna variante similar a la que sugerí más arriba (separando los si).
Y ni siquiera intentaste entender mi idea (aunque describí brevemente la lógica)... Cuando el precio es alto, hacemos una comprobación en lugar de dos. Lo mismo para el caso de que el precio sea bajo. Y cuando el precio está dentro de las barras históricas (lo cual es bastante raro - ¡esa es la lógica y la idea!), hacemos dos comprobaciones (no hay otra manera).
El cheque es para el precio fuera del bar, no dentro. Antes buscaban una aguja en un pajar, mientras que yo, si no veo otra aguja, tampoco la buscaré... La aguja se mostrará cuando sea necesario. :)))
Una variante similar a la que propuse anteriormente (separando los si).
Y ni siquiera intentaste entender mi idea (aunque describí brevemente la lógica)... Cuando el precio es alto, en lugar de dos cheques hacemos uno. Lo mismo para el caso de que el precio sea bajo. Y cuando el precio está dentro de las barras históricas (lo cual es bastante raro - ¡esa es la lógica y la idea!), hacemos dos comprobaciones (no hay otra manera).