Todos los dubbles normalizados por el mismo algoritmo (por ejemplo, a través de NormalizeDouble) pueden compararse entre sí directamente.
Este hecho obvio permite evitar construcciones costosas de comparación de números reales en muchos casos. Lo que en algunas tareas puede aumentar significativamente el rendimiento.
Quizá una de las tareas más ejemplares sea la de probador. Analicémoslo con un ejemplo.
Hay BuyLimit. En cada tick, el probador debe comparar BuyLimit con el precio Ask. El probador estándar lo hace así actualmente
pass 0 returned result 100000.000000in0:00:01.578
pass 1 returned result 100000.000000in0:00:00.759
pass 2 returned result 100000.000000in0:00:00.894
pass 3 returned result 100000.000000in0:00:00.769
pass 4 returned result 100000.000000in0:00:00.806
pass 5 returned result 100000.000000in0:00:00.772
pass 6 returned result 100000.000000in0:00:01.253
pass 7 returned result 100000.000000in0:00:01.200
pass 8 returned result 100000.000000in0:00:01.089
pass 9 returned result 100000.000000in0:00:00.780
pass 10 returned result 100000.000000in0:00:01.258
optimization finished, total passes 11
optimization done in0 minutes 11 seconds
shortest pass 0:00:00.759, longest pass 0:00:01.578, average pass 0:00:01.014
Sin normalización.
pass 0 returned result 100000.000000in0:00:01.743
pass 1 returned result 100000.000000in0:00:00.844
pass 2 returned result 100000.000000in0:00:00.672
pass 3 returned result 100000.000000in0:00:00.817
pass 4 returned result 100000.000000in0:00:00.635
pass 5 returned result 100000.000000in0:00:00.604
pass 6 returned result 100000.000000in0:00:00.867
pass 7 returned result 100000.000000in0:00:00.611
pass 8 returned result 100000.000000in0:00:00.899
pass 9 returned result 100000.000000in0:00:00.649
pass 10 returned result 100000.000000in0:00:00.742
optimization finished, total passes 11
optimization done in0 minutes 09 seconds
shortest pass 0:00:00.604, longest pass 0:00:01.743, average pass 0:00:00.825
Podemos ver que la ganancia es superior al 20% si no hacemos la normalización al comparar los precios.
En consecuencia, si el comprobador interno pasa a utilizar precios normalizados y no realiza una normalización interna al comparar los precios, se puede conseguir una importante mejora del rendimiento.
Actualizado a 2269. Resultados del perfilador de un gran EA (no sintético).
Probador
Virtual
Probablemente, el perfilador hace mediciones erróneas. Por lo demás, resulta que OrderSend cinco tarda 912 ms de media.
Todos los dubbles normalizados por el mismo algoritmo (por ejemplo, a través de NormalizeDouble) pueden compararse entre sí directamente.
Este hecho obvio permite evitar construcciones costosas de comparación de números reales en muchos casos. Lo que en algunas tareas puede aumentar significativamente el rendimiento.
Quizá una de las tareas más ejemplares sea la de probador. Analicémoslo con un ejemplo.
Hay BuyLimit. En cada tick, el probador debe comparar BuyLimit con el precio Ask. El probador estándar lo hace así actualmente
Es decir, cualquier nivel de operación(orden pendiente o SL/TP) desencadena una Normalización.
Pero siempre podemos conseguir una construcción de comparación muy eficaz si los precios se han normalizado de antemano (antes del backtest).
if (BuyLimit_Price >= Ask) BuyLimit -> Buy;Intentemos una comparación. He ejecutado este robot en Tester a través de Virtual.
Comparación de precios mediante la normalización.
Sin normalización.
Podemos ver que la ganancia es superior al 20% si no hacemos la normalización al comparar los precios.
En consecuencia, si el comprobador interno pasa a utilizar precios normalizados y no realiza una normalización interna al comparar los precios, se puede conseguir una importante mejora del rendimiento.
Después de la asignación directa sin estera. las operaciones también
El prefijo, por supuesto, copia la representación en bytes del número sin cambios.
¿Debemos hacer una prueba de más de un segundo para mayor claridad?
Hay una dispersión de 3 veces en una versión: pase más corto 0:00:00.604, pase más largo 0:00:01.743. ¿Qué comparamos?
¿Debemos hacer una prueba de más de un segundo para mayor claridad?
Hay una dispersión de 3 veces en una versión: pase más corto 0:00:00.604, pase más largo 0:00:01.743. ¿Qué comparamos?
Comparando el más corto, por supuesto. Estoy acostumbrado a correr con garrapatas filtradas. Prepararé los no filtrados más tarde.
Estamos comparando el más corto, por supuesto.
¿Por qué? La optimización no consiste en una sola pasada. Qué más da que una pasada sea tan rápida, si la media no es muy diferente.
Estoy acostumbrado a correr con garrapatas filtradas. Más adelante prepararé las que no están filtradas.
Puedo hacer un intervalo más largo. Al menos 30 segundos para la prueba.
¿Por qué? La optimización no consiste en una sola pasada. Qué más da que una pasada sea tan rápida, si la media no es muy diferente.
Este parámetro está optimizado.
Y no afecta a la lógica. Por eso es más corto.
Este parámetro está optimizado
Y no afecta a la lógica. Por eso es más corto.
¿Qué tiene que ver la lógica de EA con esto? Estamos midiendo la velocidad del probador.
¿Qué tiene que ver la lógica de EA con esto? Estamos midiendo la velocidad del probador.
Así es como funciona un agente, que cuenta consecutivamente lo mismo. Si se elimina toda la aleatoriedad, el rendimiento neto se acerca al más corto.