Errores, fallos, preguntas - página 689

 
Urain:

Alex, por qué no aceptamos el modelo multidivisa como modelo base y dejamos que los que no lo necesiten rueguen a los DC que acorten su historia eliminando las barras de sincronización.

Si hubiera querido utilizar el terminal como un MQ multidivisa, lo habría dejado en una sola divisa y se habría perdido el evento multidivisa, de ahí todos los problemas posteriores.

¿qué tienen que ver las maquetas o los modelos de prueba?

El objetivo de la plataforma es recibir y almacenar claramente la información inicial en los terminales en la misma cantidad que fue recibida por el servidor.

Los promotores no pueden dar ninguna información imparcial. La información sobre las garrapatas es tan amplia como la que existe.

Si el modelo de prueba multidivisa implica una barra a cada minuto, esto no es un modelo del servidor, es un modelo del probador.
Si
el modelo de construcción de indicadores implica la presencia de una barra en cada minuto, no es un modelo del servidor, sino un modelo del trabajo del indicador

No hay que rogar a los desarrolladores que cambien el servidor para que se adapte a sus modelos de percepción de la historia o de pruebas, no es constructivo.

Si necesita el historial de minutos perdidos, tiene que pedir a sus empresas de corretaje que añadan las barras de cada minuto perdido a su historial, con un solo volumen.

 
hrenfx:

¿Pedirle a su corredor que se salte la muleta de Metaquotes? La misma muleta se aplica a los solteros.

¿Necesita que el servidor almacene la hora de inicio de la barra de minutos no a los :00 segundos sino a la hora de llegada del primer tick, por ejemplo a los :05 o a los :24?

Si eso es todo lo que necesita y eso resolverá muchos problemas de pruebas, ¿mejorará mucho el terminal y la calidad de su probador? ¿Es ese desplazamiento de varios segundos crítico para las pruebas multidivisa?

No olvide que el probador modela todos los precios dentro de una barra utilizando el volumen de ticks. ¿Ganará mucho si la primera garrapata llega como lo hizo, y todas las demás no llegan como en la vida real?

Si este desplazamiento no tiene ningún efecto en los siguientes ticks, ¿para qué sirve el desplazamiento? ¿Por la primera marca correcta?

Me parece que sin una prueba sobre el historial de ticks reales -teniendo en cuenta el tiempo real del primer tick y modelando los posteriores- es un beneficio imaginario.

 
sergeev:

¿Qué tienen que ver las maquetas o los modelos de prueba?

El punto de la plataforma es aceptar claramente y almacenar la información original en los terminales en la cantidad que apareció y llegó al servidor.

Los desarrolladores no pueden regalar nada. La cantidad de información en los ticks es la misma que se recibió, ni un byte más, ni uno menos.

Si el modelo de pruebas multidivisa implica que hay una barra en cada minuto, esto no es un modelo del servidor, es un modelo del probador.
Si
el modelo de construcción de indicadores implica la presencia de la barra en cada minuto, no es un modelo de servidor, sino el modelo del indicador

No vayas a suplicar a los desarrolladores que cambien el servidor para adaptarlo a su percepción de la historia o a sus modelos de prueba, no es constructivo.

Si necesitas el historial de minutos perdidos, entonces debes pedirlo a tus DCs, que añadan barras de cada minuto perdido a su historial, con volúmenes unitarios.

Fusionamos los hechos con el curso de pensamiento requerido :)

El servidor transmite ticks, ¿dónde se ve el historial de ticks?

Por otro lado, el terminal recibe el historial, que es almacenado por el servidor, pero ¿por qué se considera correcto almacenar el historial en el servidor en este formato y no en una barra de sincronización?

¿Por qué el propio servidor no tiene generador de frecuencia?

¿Por qué se considera correcto cortar las barras por el tiempo, pero introducir un generador de frecuencia ya no es correcto?

Entonces, eliminemos el tiempo por completo y pasemos a las cruces y los ceros. Básicamente no existe el concepto de tiempo.

Алгоритм генерации тиков в тестере стратегий терминала MetaTrader 5
Алгоритм генерации тиков в тестере стратегий терминала MetaTrader 5
  • 2010.05.21
  • MetaQuotes Software Corp.
  • www.mql5.com
MetaTrader 5 позволяет во встроенном тестере стратегий моделировать автоматическую торговлю с помощью экспертов на языке MQL5. Такое моделирование называется тестированием экспертов, и может проводиться с использованием многопоточной оптимизации и одновременно по множеству инструментов. Для проведения тщательного тестирования требуется генерировать тики на основе имеющейся минутной истории. В статье дается подробное описание алгоритма, по которому генерируются тики для исторического тестирования в клиентском терминале MetaTrader 5.
 
sergeev:

¿Quiere que el servidor almacene la hora de inicio de la barra de minutos no a los :00 segundos, sino a la hora del primer tick, por ejemplo a los :05 o a los :24?

No, no se trata de eso. Lo único que hay que hacer es que el precio de apertura de la barra se corresponda con el precio que había en la cuenta real en el momento de la apertura del minuto. Es decir, el probador no debe mentir al mostrar el precio de apertura de la barra en la apertura del minuto.

¿Es este desplazamiento de varios segundos crucial para probar los Asesores Expertos multidivisa?

Sí, porque provoca una desincronización importante. Por ejemplo, crea una situación de arbitraje casi constante entre varios símbolos relacionados en los precios de apertura.

No olvide que el probador modela todos los precios dentro de una barra utilizando el volumen de ticks. ¿Cuánto ganará si la primera garrapata llega como lo hizo y todas las demás no son en absoluto como en la vida real?

Mucho más de lo que era - la sincronización será no sólo entre los precios de cierre, sino también entre los precios de apertura. Además, las barras multidivisas se sincronizarán, lo que liberará una enorme cantidad de recursos informáticos durante la optimización, que ahora se gastan en la misma operación en cada pasada: la sincronización.

Me parece que sin una prueba sobre el historial de ticks reales -para tener en cuenta el tiempo real del primer tick y simular los siguientes- es un beneficio imaginario.

Ya he escrito más arriba que no se trata del momento del primer tick. Pero lo de la magnificencia de la historia de las garrapatas es un mito en la mayoría de los casos. Para el grueso de los CTs, el historial M1 Bid + Ask OHLC es suficiente.
 

La tarea de almacenar el historial multidivisa es muy similar a la de almacenar vídeo. Es necesario almacenar una trama de sincronización válida y guardar los cambios a partir de ella.

En la actualidad no hay ningún marco de sincronización, sólo hay líneas de sincronización. Cada línea (par de divisas) almacena sus cambios e incluso las líneas no tienen punto de sincronización.

No podemos decir con seguridad que el precio estaba exactamente en este punto (apertura del bar).

Dado que la apertura de la barra fue a las xx:yy:00 y el tick de apertura fue a las xx:yy:12

 
Urain:

Dado que la hora de apertura del bar fue a las xx:yy:00 y el tick de apertura fue a las xx:yy:12

Para almacenarlo así, hay que esforzarse mucho en convencer a los desarrolladores de que es lo correcto y que todos se beneficiarán.

Pero es factible (me refiero a la parte técnica). Sólo hay que convencerles de que reescriban el motor del servidor (y el del terminal también) para almacenar y procesar barras :)

En esta situación, habrá más resistencia (80%) en la primera etapa de la persuasión. Y después de eso depende de los programadores.

Que Veles y Ganesh les ayuden

 
Urain:

No se puede decir con seguridad que en ese momento (apertura del bar) el precio estaba exactamente ahí.

Porque la hora de apertura del bar era a las xx:yy:00 y el tick de apertura era a las xx:yy:12

Puede hacerlo si sólo tiene como objetivo los precios de cierre. Pero para ello, necesitamos seguir el evento de cierre del minuto (no de la barra), tomando Close[1] como el precio actual.

Estas soluciones son muletas completamente artificiales que los desarrolladores utilizan, pero es una solución por la puerta trasera.

Aunque los desarrolladores cambien la situación, el precio Ask simulado seguirá dando desincronización, tanto con el análisis real como con el multidivisa en el probador.

 
hrenfx:

Lo es, porque da una grave desincronización. Por ejemplo, crea una situación de arbitraje casi constante entre varios símbolos interconectados en los precios de apertura.

... Que en realidad no existe, pero el probador crea la ilusión en el probador de que el arbitraje existe.

¿Verdad?

 
joo:

... que en realidad no existe, pero el probador le da la ilusión de que el arbitraje existe.

¿Verdad?

Exactamente. No hay arbitraje en la vida real y el probador muestra los precios de arbitraje sobre datos históricos aparentemente precisos (no modelados) - precios de apertura.
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы - Документация по MQL5
 
hrenfx:
Muy bien. No hay arbitraje en la vida real, y el probador muestra precios de arbitraje sobre datos históricos aparentemente precisos (no modelados) - precios de apertura.

No es bueno...

Aquí siempre sentí en mi cerebro que había que evitar el análisis multidivisa, o de lo contrario me llevaría un rastrillo en la frente. Parece que lo he evitado por una razón.

Razón de la queja: