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
Sí... Me he adelantado a la hora de hacer esto: .... Resulta que hay barras que tienen un precio de apertura igual al precio de cierre de la anterior. No sé qué sistema utiliza MT para dibujar las barras. Creo que sólo los desarrolladores podrán explicarlo. Me gustaría mucho entenderlo.
Si ha habido un periodo de fuera de cuota, entonces al aparecer las cotizaciones el corredor puede dar un tick con el mismo precio. Pero esto es sólo una suposición.
Si sólo se utilizan nuestros datos de tiempo real y no hay huecos entre sesiones o reinicios del servidor, entonces el cierre de una barra no puede ser igual a la apertura de la siguiente. Si se utilizan datos importados, puede ser.
Sí... Estaba en un apuro.... Resulta que hay barras que tienen un precio de apertura igual al precio de cierre de la anterior. Estoy tratando de adivinar qué sistema utiliza MT para dibujar barras. Creo que sólo los desarrolladores podrán explicarlo. Me gustaría mucho entenderlo.
Si ha habido un periodo de fuera de cuota, entonces al aparecer las cotizaciones el corredor puede dar un tick con el mismo precio. Pero esto es sólo una suposición.
Si sólo se utilizan nuestros datos de tiempo real y no hay huecos entre sesiones o reinicios del servidor, entonces el cierre de una barra no puede ser igual a la apertura de la siguiente. Si se utilizan datos importados, puede ocurrir.
He aquí un ejemplo: cotizaciones en tiempo real, su demoservidor. Mira la barra resaltada y las dos barras de arriba. En la barra resaltada, el valor del volumen del tick debe ser 0. Ya que el cambio de precio a este nivel se explica por el volumen de ticks de la barra anterior.
Dos barras más altas que 1 es correcto.
Y este no es un caso aislado. Revisa la historia. Creo que no se trata de las recotizaciones.
Por eso apareció la pregunta.
Buena suerte. Sinceramente, Vladislav.
ZS Lo siento - este ejemplo no es correcto - miré en el lugar equivocado. Ahora lo buscaré en otra parte.
ZZZY corrió sus datos de la secuencia de comandos - los ojos tenían miedo de cometer un error de nuevo - en los que he recibido el tiempo real de su servidor no es realmente. Así que quito la pregunta.
Buena suerte. Saludos, Vladislav.
Sí... Me he adelantado en este caso .... Resulta que hay barras que tienen un precio de apertura igual al precio de cierre de la anterior. No sé qué sistema utiliza MT para dibujar las barras. Creo que sólo los desarrolladores podrán explicarlo.
Si ha habido un periodo de fuera de cuota, entonces al aparecer las cotizaciones el corredor puede dar un tick con el mismo precio. Pero esto es sólo una suposición.
Si sólo se utilizan nuestros datos de rltime y no hay huecos entre sesiones o reinicios del servidor, entonces el Cierre de una barra no puede ser igual a la Apertura de la siguiente. Si se utilizan datos importados, puede ser.
He aquí un ejemplo: cotizaciones en tiempo real, su demoservidor. Mira la barra resaltada y las dos barras de arriba. En la barra resaltada el valor del volumen de ticks debe ser 0. Ya que el cambio de precio a este nivel se explica por el volumen de ticks de la barra anterior.
Dos barras más altas que 1 es correcto.
Y no se trata de un caso aislado: siempre está ahí. Así que, para ser más correcto, no he encontrado ni una sola barra que contenga cero en el caso seleccionado. Mira la historia. Creo que no se trata de requotes.
Por eso surgió la pregunta.
Buena suerte. Sinceramente, Vladislav.
¿Y qué quería mostrar con este ejemplo? ¿Esquivar la barra de una cotización (OHLC = un precio)?
Así que es una situación absolutamente normal. No hay errores ni discrepancias.
Sí... Me he adelantado en este caso .... Resulta que hay barras que tienen un precio de apertura igual al precio de cierre de la anterior. No sé qué sistema utiliza MT para dibujar las barras. Creo que sólo los desarrolladores podrán explicarlo.
Si ha habido un periodo de fuera de cuota, entonces al aparecer las cotizaciones el corredor puede dar un tick con el mismo precio. Pero esto es sólo una suposición.
Si sólo se utilizan nuestros datos de rltime y no hay huecos entre sesiones o reinicios del servidor, entonces el Cierre de una barra no puede ser igual a la Apertura de la siguiente. Si se utilizan datos importados, puede ser.
He aquí un ejemplo: cotizaciones en tiempo real en su demoservidor. Mira la barra resaltada y las dos barras de arriba. En la barra resaltada el valor del volumen de ticks debe ser 0. Ya que el cambio de precio a este nivel se explica por el volumen de ticks de la barra anterior.
Dos barras más altas que 1 es correcto.
Y no se trata de un caso aislado: siempre está ahí. Así que, para ser más correcto, no he encontrado ni una sola barra que contenga cero en el caso seleccionado. Mira la historia. Creo que no se trata de requotes.
Por eso surgió la pregunta.
Buena suerte. Sinceramente, Vladislav.
¿Y qué querías mostrar con este ejemplo? ¿Esquivar la barra de una cotización (OHLC = un precio)?
Así que esta es una situación absolutamente normal. No hay errores ni discrepancias.
Buena suerte. Saludos, Vladislav.
Lo siento, este ejemplo es incorrecto, he mirado en el lugar equivocado. Buscaré en otra parte.
ZZZY corrió sus datos de la secuencia de comandos - los ojos tenían miedo de cometer un error de nuevo - en los que he recibido el tiempo real de su servidor realmente no hay tal cosa. Así que quito la pregunta.
Sí, también escribí un script para comprobar la condición if(Close[previous]==Open[current]) y encontré esto sólo en los datos importados. No existe tal cosa en nuestros datos de tiempo de relevo.
Lo siento, este ejemplo es incorrecto, he mirado en el lugar equivocado. Buscaré en otra parte.
ZZZY corrió la secuencia de comandos de sus datos - los ojos tenían miedo de cometer un error de nuevo - en los que he recibido el tiempo real de su servidor realmente no hay tal cosa. Así que la pregunta eliminada.
Sí, también escribí un script para comprobar la condición if(Close[previous]==Open[current]) y lo encontré sólo en los datos importados. No existe tal cosa en nuestros datos de tiempo de relevo.
Buena suerte. Saludos, Vladislav.
Sí, también escribí un script para comprobar la condición if(Close[previous]==Open[current]) y encontré esto sólo en los datos importados. No existe tal cosa en nuestros datos de retransmisión.
Buena suerte. Atentamente, Vladislav.
Entienda que nunca debe confiar en las garrapatas en las pruebas. Por el contrario, hay que ignorar los movimientos de ruido dentro de la media-spread-spread. Casi todos los operadores pasan por un pips trivial con la esperanza de un pip extra. Y la mayoría de los operadores se justifican con "no, no soy un operador de pipas, quiero una ejecución precisa" :)
La gente se engaña a sí misma esperando una ejecución absolutamente precisa y garantizada, y luego se sorprende de que, en realidad, obtiene recotizaciones, y es imposible hacer un trato en un mercado rápido. No sólo eso, sino que muchos no se ocupan en absoluto de las recotizaciones y otras respuestas del servidor comercial.
Sí, también escribí un script para comprobar la condición if(Close[previous]==Open[current]) y encontré esto sólo en los datos importados. No existe tal cosa en nuestros datos de relé.
Buena suerte. Saludos, Vladislav.
Entienda que nunca debe confiar en las garrapatas en las pruebas. Por el contrario, hay que ignorar los movimientos de ruido dentro de la media-spread-spread. Casi todos los operadores pasan por un pips trivial con la esperanza de un pip extra. Y la mayoría de los operadores se justifican con "no, no soy un operador de pipas, quiero una ejecución precisa" :)
La gente se engaña a sí misma esperando una ejecución absolutamente precisa y garantizada, y luego se sorprende de que, en realidad, recibe recotizaciones, y es imposible hacer un trato en un mercado rápido. No sólo eso, sino que muchos no se ocupan en absoluto de las recotizaciones y otras respuestas del servidor comercial.
Quería saber hasta qué punto esas "interferencias" (llamémoslas así) pueden afectar a la calidad del propio comprobador. He escrito más arriba que no considero la estrategia en sí misma.
De su respuesta deduzco que no pueden. Bien por ti.
Buena suerte. Saludos, Vladislav.
Si sólo se utilizan nuestros datos de retransmisión y no hay huecos entre sesiones o reinicios del servidor, entonces el Cierre de una barra no puede ser igual a la Apertura de la siguiente. Si se utilizan datos importados, puede ser.
No tengo datos importados, sino datos subidos a MT "legalmente" desde el DC.
Si sólo se utilizan nuestros datos de retransmisión y no hay huecos entre sesiones o reinicios del servidor, entonces el Cierre de una barra no puede ser igual a la Apertura de la siguiente. Si se utilizan datos importados, esto puede ocurrir.
No tengo datos importados, sino subidos a MT "legalmente" desde DC.