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
¿Las sesiones de negociación y cotización no ayudan a resolver el problema?
Por desgracia, no. Según el pliego de condiciones, la sesión de cotización comienza a las 00:00 horas del lunes.
En realidad, aquí Rosh da la respuesta de que el inicio de una sesión de cotización no garantiza la disponibilidad de cotizaciones en ella. Lo cual es, en principio, comprensible.
Hasta ahora estoy utilizando una "muleta" en forma de la siguiente comprobación:
Agradecería que alguien compartiera una solución más elegante (todos los usuarios de multidivisas se habrán encontrado con esto).
P.D.
Konstantin Gruzdev ofrece una variante elegante en su artículo Implementación del modo multidivisa en MetaTrader 5.
Pero esta variante no cumplirá los requisitos para el Campeonato.
Yikes... que tocó un nervio. :)) La última línea fue corregida a mano en un mensaje del foro, así que perdóname. =)
Por cierto, tu código tampoco compiló (olvidé poner un paréntesis de cierre en la última línea). :-Р
Además es 2-3 veces más lento (ahora lo he comprobado en el script), pero la calidad de la comprobación es la misma. :-Р
De todos modos, mientras no haya un código adecuado para determinar el número entero significativo, seguiré el consejo de Composter: normalizar el volumen a 8 decimales.
Esperemos que no haya trampas.
Referencia:
Функцию Sleep() нельзя вызывать из пользовательских индикаторов, так как индикаторы выполняются в интерфейсном потоке и не должны его тормозить.
¿Es realmente imposible, o si realmente quieres, puedes, pero con cuidado? :)
Problema al acceder a los datos de otro símbolo desde el indicador.
si no hay garrapatas)
¿El OrderCheck no ayuda?
No. Escribo una línea antes del intercambio:
Sigue habiendo un error en el registro. :(
¿Y qué pasa con la normalización de los lotes?
Chicos, ¿por qué teorizar?
Una situación en la que el incremento del lote será mayor que el lote mínimo es absurda. Pues bien, imagina: min = 0,1, step = 1,0. Entonces, ¿sólo se permiten los lotes 1.1, 2.1, 3.1, ...? Esto es una tontería.
Si ejercitas la aritmética y la programación, entonces tus opciones ganarán. Pero si hablamos de programación aplicada (en el sentido de trading), entonces a lote_paso > lote_mín hay que terminar el programa con un error crítico y cambiar urgentemente de broker, porque no tiene suficiente dinero ni para el sueldo de una persona que configure normalmente el servidor).
Todo tiene que ser con moderación. Mi variante ha estado trabajando en reales durante más de 5 años, con diferentes corredores, tipos de cuentas, instrumentos - nunca tuvo un error.komposter
¿Por qué es absurdo? Tomemos un ejemplo sencillo: min_lot = 1,0, min_step = 0,3. Los requisitos satisfacen el principio de "no tonterías" (min_lot >= lot_step). :)
Pasa 1,3 lotes de volumen a la función de normalización. De él se devuelven 1,2 lotes.
La versión actualizada devolverá 1.3. Sus pasos son "correctos": desde el lote mínimo, no desde cero.
Otra cuestión es la presencia de pasos "en la vida" distintos de"1,0, 0,1, 0,01, etc.".
En este caso, me parece que el coste de la cuestión (pérdida de rendimiento) es insignificante comparado con la solución de un posible error hipotético. EN MI OPINIÓN.
Al fin y al cabo, es más correcto contar así: pasos desde el lote mínimo, no desde cero.
No. Escribo una línea antes de comerciar:
Sigue habiendo un error en los registros. :(
Visto, en las cuentas del campeonato todos los instrumentos se negocian al mismo tiempo. Registro)
TradeCheckResult.retcode != TRADE_RETCODE_DONE
No estoy tan seguro de esta condición...
No sé si esta condición es correcta o no:
if(precio actual == 0,0) return;
komposter
¿Por qué es absurdo? Tomemos un ejemplo sencillo: lote mínimo = 1,0, paso mínimo = 0,3. Los requisitos cumplen con el principio de "sin tonterías" (min_lot >= lot_step). :)
Pasa 1,3 lotes de volumen a la función de normalización. De él se devuelven 1,2 lotes.
La versión actualizada devolverá 1.3. Sus pasos son "correctos": desde el lote mínimo, no desde cero.
Otra cuestión es la presencia de pasos "en la vida" distintos de"1,0, 0,1, 0,01, etc.".
En este caso, me parece que el coste de la cuestión (pérdida de rendimiento) es insignificante comparado con la solución de un posible error hipotético. EN MI OPINIÓN.
Al fin y al cabo, es más correcto contar así: pasos desde el lote mínimo, no desde cero.
"lote mínimo = 1,0, paso mínimo = 0,3" también es absurdo. Los pasos deben ser un múltiplo del lote mínimo.
Ya he expresado mi opinión: en una competición de matemáticas y programación, la variante de sustracción min_lot ganará, no es necesaria para el comercio real.
No veo el tema para seguir discutiendo, cada uno ha hecho su camino ;)