Preguntas de un "tonto" - página 13
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
En realidad, hay hasta 8 bytes de información en el mensaje, que pueden ser interpretados como se desee. Puede ser datetime, double, 4 short, 8 char, o 64 bits bit a bit.
Con los cuatros, 4 bytes de magia eran suficientes para codificar cualquier cosa, pero ahora tenemos 8. Todo lo que necesitas es un deseo.
Lo sé, lo usé bastante bien en la 4, y leí el artículo (me gustó mucho la idea).
Aquí no está claro sólo - ¿Por qué se especifican diferentes tipos en diferentes lugares?
Por favor, indique cómo puede cerrar una posición con TP y SL, si el precio está cerca del TP y necesita salir ahora.
Envío una orden para abrir una nueva posición de igual volumen. En la mayoría de los casos funciona. Pero a veces me encuentro con una situación en la que una posición tiene tiempo de cerrarse por TP y en lugar de cerrarse, consigo una nueva posición en el mercado... :(
¿Cómo puedo indicar que la posición abierta se refiere al cierre de una posición existente, y si la posición principal ya ha sido cerrada, no abrir una nueva?
Se me ocurren opciones como "quitar el SL y el TP antes del cierre o esperar al cierre del TP", pero no son soluciones agradables. ¿No podemos realizar una operación tan sencilla como CERRAR una posición como lo hacíamos en MT4?
Busque PositionClose en la clase CTrade.
Seguro que será igual que el tuyo. Una conclusión es ineludible: no hay otro camino.
Pero apoyo su petición. Pido a los desarrolladores que consideren esta variante.
Añadir el tipo de operación TRADE_ACTION_CLOSE - cierre de una posición para un símbolo especificado en su volumen al precio actual.
En realidad, hay 8 bytes completos de información para el mensaje, que pueden interpretarse como se quiera. Puede ser datetime, double, 4 short, 8 char, o 64 bits bit a bit.
Con los cuatros, 4 bytes de magia eran suficientes para codificar cualquier cosa, pero ahora tenemos 8. Sería sólo un deseo.
Unos 8 bytes en long y ulong estaban claros desde la Referencia. Lo que es preocupante es el uso incoherente de estos tipos en relación con la magia.
Un ejemplo sencillo: es aceptable asignar request.magic=ULONG_MAX-1 al enviar una solicitud de comercio. ¿Por qué el Manual de Referencia dice que la función OrderGetInteger(ORDER_MAGIC) sólo devuelve el tipo long? Además, la magia también devuelve el tipo largo tanto para las posiciones como para las operaciones.
Entonces, ¿cómo se diseñó originalmente? Tal vez, deberíamos especificar parala estructura MqlTradeRequest que la magia es de tipo largo, porque las funciones HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. no están destinadas a devolver valores enteros mayores que LONG_MAX?
Los 8 bytes de long y ulong estaban claros en el Manual de Referencia. El uso incoherente de estos tipos en relación con la magia es preocupante.
Un ejemplo sencillo: al enviar una solicitud de comercio, es aceptable asignar request.magic=ULONG_MAX-1. ¿Por qué el Manual de Referencia dice que la función OrderGetInteger(ORDER_MAGIC) sólo devuelve el tipo long? Además, la magia también devuelve el tipo largo tanto para las posiciones como para las operaciones.
Entonces, ¿cómo se diseñó originalmente? Tal vez, deberíamos especificar parala estructura MqlTradeRequest que la magia es de tipo largo, porque las funciones HistoryDealGetInteger(), PositionGetInteger(), OrderGetInteger() etc. no están destinadas a devolver valores enteros mayores que LONG_MAX?
En realidad el magik es de tipo largo (esto se puede comprobar fácilmente formando un magik negativo y un magik con un valor fuera del rango de valores de tipo largo).
Para comprobarlo, podemos modificar ligeramente el Asesor Experto Nocturno (no utiliza clases de la biblioteca estándar).
Para que el experimento sea limpio, debemos cambiar el tipo de parámetro EA_Magic a largo y desencadenar el mago de la última orden en el historial (si la orden se ha establecido con éxito).
Interesting:
В действительности магик имеет тип long (это легко проверяется формированием отрицательного магика и магика со значением выходящим за диапазон значений типа long).
Si es así, es necesario aclarar la descripción del elemento mágico de la estructuraMqlTradeRequest eliminando "u"del nombre del tipo.
En realidad, hay 8 bytes completos de información para el mensaje, que pueden interpretarse como se quiera. Puede ser datetime, double, 4 short, 8 char, o 64 bits bit a bit.
Con los cuatros, 4 bytes de magia eran suficientes para codificar cualquier cosa, pero ahora tenemos 8. Sería sólo un deseo.
En realidad, no son 64 sino sólo 63 bits (es decir, 8 bytes incompletos). Serían 8 bytes si utilizáramos todo el rango largo.
Pero desgraciadamente...
Por un lado, la magia ulong se pasa a la estructura MqlTradeRequest. Significa que sólo se pueden establecer valores positivos.
Porotro lado, las funciones PositionGetInteger/OrderGetInteger devuelven el tipo long. Significa que la mitad del rango ulong se corta.
En total, tenemos 63 bits en lugar de los 64 descritos anteriormente. En realidad, no es tan malo como un gran inconveniente para los principios de comprobación del orden.
Sería mucho más conveniente utilizar el mismo sistema que en MT4 - permitir a los magos con una señal. Ya que muchos sistemas de trading se basan en un simple principio que utiliza el mismo símbolo de un mago. Ya que es mucho más fácil dividir un sistema en dos y filtrar sus órdenes utilizando la función habitual MathAbs( OrderMagicNumber() ).
En realidad no son 64, sino sólo 63 bits (es decir, 8 bytes incompletos). 8 bytes sería si se utilizara toda la gama de longs.
Se equivoca.
Se utilizan 64 bits y depende de ti cómo los utilices. Largo/largo no hace ninguna diferencia, todo depende de cómo se interpreten esos 64 bits. Si quieres usar long como un long con signo - úsalo, si quieres usarlo como un ulong sin signo - no hay problema. Si quieres utilizar otros tipos de datos en estos 64 bits, hazlo.
Esto es exactamente lo que escribió Slava.
En realidad no son 64, sino sólo 63 bits (es decir, 8 bytes incompletos). 8 bytes sería si se utilizara todo el rango largo.
Pero desgraciadamente...
Por un lado, la magia ulong se pasa a la estructura MqlTradeRequest. Significa que sólo se pueden establecer valores positivos.
Porotro lado, las funciones PositionGetInteger/OrderGetInteger devuelven el tipo long. Significa que la mitad del rango ulong se corta.
En total tenemos 63 bits en lugar de los 64 descritos anteriormente. En realidad, no es tan malo como un gran inconveniente para los principios de comprobación del orden.
Sería mucho más conveniente utilizar el mismo sistema que en MT4 - permitir a los magos con una señal. Ya que muchos sistemas de trading se basan en un simple principio que utiliza el mismo símbolo de un mago. Ya que es mucho más fácil dividir un sistema en dos y filtrar sus órdenes utilizando la función habitual MathAbs( OrderMagicNumber() ).
Sinceramente, estoy desconcertado, os estáis pasando con lo que no es gran cosa. En absoluto. Este problema no existe, te lo has inventado. Ordena las conversiones de tipo hasta el final.
Espero que el artículo que sigue le ayude. Cópialo en un script, compílalo, ejecútalo en la terminal y luego piénsalo bien. Buena suerte.