¿Funciona correctamente el probador? - página 5

 
Integer:
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.
 
Renat:
Entero:
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.
Esto ocurre en cualquier dato de plazo minúsculo, véanlo ustedes mismos y en esas cotizaciones, que he bajado de Alpari, creo, también.



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.
 
VladislavVG:
Renat:
Entero:
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.
Esto ocurre en los datos de cualquier minuto de tiempo, puedes verlo por ti mismo y en esas cotizaciones que he descargado de Alpari también.

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.
 
Renat:
VladislavVG:
Renat:
Entero:
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.
Si no tiene esa idea, puede utilizar la mano derecha para solucionar el problema.

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.
Sí, ya he visto y corregido el post anterior.

Buena suerte. Saludos, Vladislav.
 
VladislavVG:

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.
 
Renat:
VladislavVG:

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.
¿He entendido bien que el probador debe distorsionar mal las pruebas en tal situación? ¿Quizás deberíamos añadir una comprobación de este tipo al script estándar? Está claro que es mejor utilizar datos verificados para las pruebas. Pero muchos operadores prueban los sistemas con los datos de su corredor, por lo que es posible que se produzcan malentendidos.

Buena suerte. Saludos, Vladislav.
 
VladislavVG:

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.
¿He entendido bien que el probador tiene que distorsionar mucho las pruebas en una situación así? ¿Quizás deberíamos añadir una comprobación de este tipo al script estándar? Está claro que es mejor utilizar datos verificados para las pruebas. Pero muchos operadores prueban los sistemas con los datos de su corredor, por lo que es posible que se produzcan malentendidos.

Buena suerte. Atentamente, Vladislav.
Totalmente equivocado. No hay ninguna distorsión, salvo el pensamiento erróneo sobre un punto en la cabeza de los operadores.

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.
 
Renat:
VladislavVG:

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é.
¿He entendido bien que el probador tiene que distorsionar mucho las pruebas en esta situación? ¿Quizás deberíamos añadir una comprobación de este tipo al script estándar? Está claro que es mejor utilizar datos verificados para las pruebas. Pero muchos operadores prueban los sistemas con los datos de su corredor, por lo que es posible que se produzcan malentendidos.

Buena suerte. Saludos, Vladislav.
Totalmente equivocado. No hay más distorsión que los pensamientos erróneos sobre un solo punto en la cabeza de los operadores.

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.
Nunca he esperado una ejecución precisa. Y respecto a las garrapatas las entiendo muy bien. En general, todas mis paradas están fuera de las zonas de reversión estadísticamente significativas y ciertamente no más cerca de 2,5 ATR detrás del extremo de la barra anterior :). Es decir, no hay ni un atisbo de algoritmos de "scalping". En cuanto a la media cancha, incluso diría que un valor expresado en TAE es una estimación más precisa (verificada por la práctica).

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.
 
Renat писал (а):

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.
 
Integer:
Renat escribió:

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.
Así que se han importado al servidor de comercio - esto es común para los datos históricos de períodos anteriores.