Errores, fallos, preguntas - página 444

[[Eliminado]]

Interesting:
¿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:

input int TTL = 10; // Время "жизни" котировки
...
void Trade() {
  ...
  if (TimeCurrent() - SymbolInfoInteger(Instrumet, SYMBOL_TIME) > TTL) return;
  ...
  // Далее отправка торгового приказа на сервер.
}

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.

[Vladimir Gomonov]

voix_kas:

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.

:)

[Aleksey Lebedev]

voix_kas:

¿El OrderCheck no ayuda?

[Aleksey Lebedev]

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)

[[Eliminado]]

Swan:
¿El OrderCheck no ayuda?

No. Escribo una línea antes del intercambio:

if (!OrderCheck(TradeRequest, TradeCheckResult) || (TradeCheckResult.retcode != TRADE_RETCODE_DONE)) return;

Sigue habiendo un error en el registro. :(

[Andrey Khatimlianskii]

¿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.

[[Eliminado]]

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.

[Гребенев Вячеслав]

¿Hay algún código listo en algún lugar que compre el máximo número posible de lotes al símbolo y precio actuales por una cantidad de dinero determinada (por ejemplo, 1234,56 dólares es el único parámetro de entrada). En el interior debería haber todo tipo de controles de volúmenes máximos, mínimos, normalización, contabilidad de apalancamiento, suficiencia de fondos, etc. etc. Lo principal es que el código debe hacer una compra y no molestarme con el hecho de que no tenga dinero (comprar todo lo que tenga), que alguna comprobación haya fallado (hacer que tenga éxito), que haya una orden, pero que no se haya producido ninguna compra (morir, pero no volver sin comprar), etc. Entiendo que en alguna clase como CTrade está esto. Pero no es tan fácil copiar algo de allí. Quiero tratar con mi propio algoritmo, no con el lenguaje de MQL5.

[Aleksey Lebedev]

voix_kas:

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;

[Andrey Khatimlianskii]

voix_kas:

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 ;)