El lienzo es genial. - página 17

 
Алексей Тарабанов:

Análisis morfométrico: análisis de las células muertas. Primero los matamos y luego los ponemos bajo el microscopio.

Morfometría (en griego: morphe form + ...metry)

Eso es todo. Ya está bien de desordenar el tema.

 
fxsaber:


Double int es dos veces más rápido que double

No te das cuenta de la escala y no estás haciendo las pruebas correctamente en microsíntesis, sin considerar las implicaciones de ejecutar no 30 funciones de ensamblaje, sino una matriz de 50k-100k instrucciones.

Refuta todos los puntos que he expuesto en mi respuesta original.

 
Renat Fatkhullin:

No te das cuenta de la escala y estás ejecutando incorrectamente las pruebas en microsíntesis, sin considerar las consecuencias de ejecutar no 30 funciones de ensamblador sino una matriz de 50k-100k instrucciones.

Refute cada uno de mis puntos anteriores en su respuesta original.

Refutó ese punto (aunque con acciones primitivas en cada tic)

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

¡El lienzo es impresionante!

Renat Fatkhullin, 2019.01.15 22:37

Teniendo en cuenta el código de 64 bits y nuestro compilador debemos olvidarnos de los enteros en la clase de tarea basada en cálculos dobles...

El comprobador se basa en cálculos dobles. Y hay tantos en cada tic que incluso una carrera en vacío va a 7 millones de tics por segundo.


Puede escribir un simulador con acciones más complicadas en cada tic. Pero la base del Probador es la comparación del precio actual del tick con el precio de la orden, lo que hace que los códigos sean más altos. Esta afirmación no se hace en el vacío. He publicado mediciones reproducibles y alternativas de cálculo de dominio público.

 
fxsaber:

Desmiente este punto (aunque con acciones primitivas en cada tic)

El comprobador se basa en cálculos dobles. Y hay tantos en cada tic que incluso una carrera en vacío va a un ritmo de 7 millones de tics por segundo.


Es posible escribir un simulador con acciones más complicadas en cada tic. Pero la base del Probador es comparar el precio actual del tick con el precio de la orden, que es lo que hace que los códigos sean aproximadamente más altos.

Refuta esto:

  1. todo tendrá que ser convertido a ints
  2. obtener muchos retrasos en la conversión de datos
  3. obtener un consumo de memoria salvaje
  4. obtener el 100% de posibilidades de desbordamiento en cada operación y la muerte completa del sistema
  5. obtener un desprecio de los desarrolladores que se ofrecen a dejar leer sus indicadores y trabajar en ints en lugar de dubs
  6. Y ta da, ya no hay diferencia entre dubs e ints en la velocidad. Es difícil de creer, pero sí.

Cada punto, por favor.

Tenga en cuenta que incluso un punto 4 o 5 es suficiente para fusionar la idea de la aceleración de los enteros.

No me refiero a que el probador no sea for(i=0;i<limit;i++ ) { }

Pero también puedo señalar que no se puede esperar conservar los resultados de la optimización local del microcódigo en las operaciones con números enteros. A veces basta con añadir una cadena inofensiva en un bucle y perder la velocidad en decenas de porcentajes. Y si se pasa a las tareas reales cuando el código está hinchado de trabajo real, todas las comparaciones se van al diablo ahí.

 
Renat Fatkhullin:

Refuta esto:

  1. todo tendrá que ser convertido a ints
  2. obtener muchos retrasos en la conversión de datos
  3. obtener un consumo de memoria loco
  4. obtener una probabilidad del 100% de desbordamientos en cada operación y la muerte total del sistema
  5. obtener un desprecio de los desarrolladores que se ofrecen a dejar leer sus indicadores y trabajar en ints en lugar de dubs
  6. Y ta da, ya no hay diferencia entre los dubs y los ints en cuanto a velocidad. Es difícil de creer, pero sí.

Cada punto, por favor.

Tenga en cuenta que incluso un punto 4 o 5 es suficiente para fundir la idea de la aceleración de los enteros.

El objetivo era demostrar que hay problemas que todavía se pueden resolver en números enteros para acelerar. Un probador como este no es universal, ya que no se ajusta al menos al punto 5.


En cuanto a los cuatro primeros puntos, los problemas son muy rebuscados. Dado que la velocidad del probador sólo se necesita durante la optimización. Sólo convierte los ticks una vez para todo el grupo de pases.

 
fxsaber:

El objetivo era demostrar que hay problemas que todavía se pueden resolver en números enteros para acelerar. Dicho probador no es universal, ya que no se ajusta al menos al punto 5.


En cuanto a los cuatro primeros puntos, los problemas son muy rebuscados. Dado que la velocidad del probador sólo se necesita durante la optimización. Convierte los ticks sólo una vez para todo el grupo de pases.

Es decir, no se refutan los puntos 4 ni 5.

E incluso la conversión que se quiere ahorrar, lo que aumenta inmediatamente el coste del tiempo varias veces. Sí, a veces, incluyendo la memoria de conversión. Creía que estabas sugiriendo que toda la plataforma se convirtiera a int64 para deshacerse de las conversiones.

Incluso teóricamente no hay beneficios de la migración a int desde hace 10 años.
 
Renat Fatkhullin:

No estoy hablando de cómo un probador no for(i=0;i<limit;i++ ) { }

Si se trata de un probador sin temporizador, está demostrado que un probador es para por ticks.

 
fxsaber:

Si se trata de un probador sin temporizador, está demostrado que un probador es para los ticks.

Esto no es un probador, sino un falso. Sin indicadores, sin beneficios ni nada. Pero con un riesgo constante de desbordamiento de enteros.

Ni siquiera tiene sentido discutirlo.

Y otra vez:

Pero también puedo señalar que no se puede esperar guardar los resultados de la optimización del microcódigo local en las operaciones con números enteros.

A veces basta con añadir una cadena inofensiva en un bucle para perder decenas de puntos de velocidad. Y si se pasa a las tareas reales cuando el código se hincha de trabajo real, todas las comparaciones se van al diablo ahí.

¿Entiendes que optimizar 20 comandos de ensamblador y el bloque real para varios cientos o miles de comandos matará tu ejemplo?
 
Renat Fatkhullin:

Así que no se refutan ni el punto 4 ni el 5.

E incluso quieres guardar la conversión, lo que multiplica inmediatamente el tiempo empleado. Sí, a veces, incluyendo la memoria de conversión. Creía que estabas sugiriendo cambiar toda la plataforma a precios int64 para librarte de las conversiones.

Parece que se trata de un malentendido de lo que estaba hablando. Me refería a un ejemplo de problema privado de Tester, donde los precios enteros pueden dar una ganancia en ciertas situaciones. El caso universal no estaba en mente. Por eso mi Tester, al que di un enlace más arriba, está implementado en los doblajes, ya que es universal.

Incluso teóricamente no hay ninguna ganancia por ir a int desde hace 10 años.

No puedo estar de acuerdo al 100%.

 
Renat Fatkhullin:

No es un probador, es una imitación. Sin indicadores, sin beneficios y sin nada. Pero con un riesgo constante de desbordamiento de enteros.

Este es un complemento para su probador, que hace un pase completo con todas las operaciones y beneficios, sin ningún cambio en el código de cualquier Asesor Experto (con cualquier indicador). Pero lo hace más rápido que el Tester normal. Se han dado todas las pruebas reproducibles. Personas del recurso han verificado estas afirmaciones.

Razón de la queja: