Tema interesante para muchos: las novedades de MetaTrader 4 y MQL4 - grandes cambios en camino - página 50
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
Hay una carta de este tipo. Sin embargo, el gap (salto discontinuo de la cotización) puede ocurrir en cualquier momento, no sólo al principio de la barra. Cualquier formato "adelgazado" no está libre de pecado, por definición. La alimentación completa sólo en los ticks. Y podría ser aún más completa en la historia de la copa. Estoy tratando de hacer un formato de minutos para mí, hasta ahora he encontrado un compromiso de este tipo.Puedo dejarlo como se describe arriba (sin Open, sólo {Hi-Lo-Close}), entiendo todos los inconvenientes, es sólo una versión de mi codificación para mi probador. Usaré ticks crudos o los reduciré artificialmente con cualquier método (con el formato de ticks guardados {bid-ask-time}).
No creo que buscar comprender sin juzgar sea el más grave de mis pecados. ;)
Pensar, en términos de gravedad del pecado, por supuesto, es más fuerte. Estoy de acuerdo.
Me alegro de que hayas acertado. Así que será mejor que te consigas un caldero junto al mío. Tendremos mucho tiempo para charlar. No hay libertad condicional.
;)
¿Está seguro de que las barras MQ M1 se almacenan sin embalaje?
Entonces cómo es que hay retrasos en la obtención del historial (pequeños pero presentes), pero la reaplicación (como a la caché) es más rápida.
Por lo visto, en el archivo del historial las barras se almacenan como cambios de la barra de sincronización, aquellos en forma comprimida.
Así que su cuenta de 52 bytes es un recuento de la historia desempaquetada.
¿Está seguro de que las barras MQ M1 se almacenan sin embalaje?
Entonces cómo es que hay retrasos en la obtención del historial (pequeños pero los hay), pero la reaplicación (como a la caché) es más rápida.
Por lo visto, en el archivo del historial las barras se almacenan como cambios de la barra de sincronización, aquellos en forma comprimida.
Así que tu cálculo sobre los 52 bytes es un cálculo de la historia sin empaquetar.
No he dicho nada de eso, no sólo eso: estoy seguro de que hay envases. El formato no está declarado al público, y no he intentado "descifrarlo".
Así que todo es correcto, he descrito sólo el formato sin embalaje. Está sacado de la documentación.
No he dicho nada de eso, no sólo eso, estoy seguro de que está empaquetado. El formato no se ha anunciado públicamente y no he intentado "descifrarlo".
Así es, sólo tengo el formato descrito sin empaquetar. Está sacado de la documentación.
Así es, pero estás tratando de demostrar que el nuevo formato será económico, mientras comparas el formato actual desempaquetado y el nuevo parcialmente empaquetado.
No estoy comparando la economía, te imaginabas, sólo la informatividad. No hay economía, mi formato descomprimido es más == 88 bytes {Open, High, Low, Close} y == 72 bytes {High, Low, Close}.
Bueno, no deberías haber tenido el cáncer por la piedra. Habría sugerido simplemente duplicar la información en lugar de 52 bytes 88.
Lo mismo desde el principio hrenfx sugirió.
¿Por qué hay un formato con tantos datos? Es decir, es necesario definir las limitaciones de este filtro de ticks (este formato), cuando no difiere el resultado del historial de ticks puro.
A simple vista, un simple filtro de ticks HighBid+LowAsk no es mucho peor que el inteligente (según la cantidad de datos).
Close-data es bueno sólo para la sincronización multidivisa.
Tal vez, es más fácil cambiar a un plazo menor en lugar de hacer eso. Por ejemplo, S20 sólo requiere 48 bytes para el mismo minuto en formato HighBid+LowAsk (quizás incluso menos, si 4 bytes por precio son más que suficientes. En mi probador, lo hago todo vía long int - muy rápido). Y en términos de precisión, el 100% superará su filtro de minutos en 88 bytes.
P.D. La función Error(Freq, DataSize) = Full - Freq * DataSize tiende a cero, al aumentar Freq,
donde el error es la pérdida de información.
Completo: información completa sobre el mercado.
Freq* DataSize es una función de "multiplicación": la cantidad de información que se puede recuperar con la frecuencia de cuantificación Freq, y el contenido de información(DataSize) para cada término de cuantificación.
¿Por qué hay un formato con tantos datos? Es decir, es necesario definir las limitaciones de este filtro de ticks (este formato), cuando no difiere el resultado del historial de ticks puro.
A simple vista, un simple filtro de ticks HighBid+LowAsk no es mucho peor que el inteligente (según la cantidad de datos).
Close-data es bueno sólo para la sincronización multidivisa.
Tal vez, es más fácil cambiar a un plazo menor en lugar de hacer eso. Por ejemplo, S20 sólo requiere 48 bytes para el mismo minuto en formato HighBid+LowAsk (quizás incluso menos, si 4 bytes por precio son más que suficientes. En mi probador, lo hago todo vía long int - muy rápido). En términos de precisión, superará su filtro de 88 bytes por minuto en un 100%.
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Un tema interesante para muchos: Las novedades de MetaTrader 4 y MQL4 - se avecinan grandes cambios
Avals, 2013.08.11 15:43
Si no sabes qué hacer con esto, puedes olvidar que es una medida a medias. Necesitamos un probador de garrapatas adecuado.
p.d. si se generaliza y en las fichas, entonces es bueno)