Algoritmos, métodos de solución, comparación de su rendimiento - página 23

[fxsaber]

Andrey Khatimlianskii:

Podrías tener un intervalo más largo. Al menos 30 segundos para la prueba.

Con la normalización.

pass 0 returned result 100000.000000 in 0:00:35.296
pass 1 returned result 100000.000000 in 0:00:29.361
pass 2 returned result 100000.000000 in 0:00:24.549
pass 3 returned result 100000.000000 in 0:00:25.067
pass 4 returned result 100000.000000 in 0:00:24.578
pass 5 returned result 100000.000000 in 0:00:24.634
pass 6 returned result 100000.000000 in 0:00:25.079
optimization finished, total passes 7
optimization done in 3 minutes 09 seconds
shortest pass 0:00:24.549, longest pass 0:00:35.296, average pass 0:00:26.937

Sin normalización.

pass 0 returned result 100000.000000 in 0:00:33.035
pass 1 returned result 100000.000000 in 0:00:26.020
pass 2 returned result 100000.000000 in 0:00:20.137
pass 3 returned result 100000.000000 in 0:00:20.859
pass 4 returned result 100000.000000 in 0:00:21.130
pass 5 returned result 100000.000000 in 0:00:20.664
pass 6 returned result 100000.000000 in 0:00:21.001
optimization finished, total passes 7
optimization done in 2 minutes 50 seconds
shortest pass 0:00:20.137, longest pass 0:00:33.035, average pass 0:00:23.263

El mismo 20%.

[Andrey Khatimlianskii]

fxsaber:

Así es como trabaja un Agente, cuenta constantemente lo mismo. Si se elimina toda la aleatoriedad, el rendimiento neto se acerca al más corto.

Net no es interesante, ya que no es realizable en la realidad.

Gracias por las pruebas.

[Alexey Navoykov]

fxsaber:

Con la normalización.

Sin normalización.

El mismo 20%.

20% para un EA ficticio que no hace nada... No es muy significativo. En el código real, la cifra sería muchas veces menor. ¿Merece la pena perder el tiempo en estas trivialidades?

Y hablando de optimizar los cálculos, deberíamos empezar por el hecho de que no es necesario controlar constantemente los niveles de todas las órdenes pendientes. Sólo tenemos que comprobar el más cercano. Si se alcanza, entonces el siguiente nivel y así sucesivamente.

[fxsaber]

Alexey Navoykov:

20% para un EA ficticio que no hace nada... No es muy significativo. En el código real la cifra sería muchas veces menor. ¿Merece la pena perder el tiempo en estas trivialidades?

La observación es justa. En mi robot normal veo demasiado retraso en el Tester. Hay muchas razones para ello. Y ésta es una de ellas. Una pasada son 100 millones de ticks. Tomemos la genética estándar para los pases de 10K. Eso es un trillón de ticks por lo menos. En cada tic el probador hace al menos una normalización. Cuando no podía hacer nada. ¿Cuál es el ahorro de esta optimización? Además, molestarse es hacer una normalización en cada comparación, como ocurre ahora. En realidad, es más fácil y eficaz normalizar sólo los precios de entrada.

Y hablando de la optimización de los cálculos, hay que empezar por el hecho de que no es necesario controlar constantemente los niveles de todas las órdenes pendientes. Sólo tenemos que comprobar el más cercano. Si se alcanza, se comprueba el siguiente nivel, etc.

El comprobador incorporado se retrasa mucho cuando aumenta el número de pedidos. Los TS de la red son sus "asesinos". He sugerido esa optimización algorítmica. No creo que la emprendan.

Aquí no estamos hablando de una gran cantidad de cálculos internos que acompañan a cada tic del probador.