Un poco sorprendido :) Pensé en compartir y hacer una pregunta NO retórica. - página 14
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
El optimizador no es exactamente un "probador de escala lineal", sino que tiene sus propios métodos de optimización que funcionan eficazmente en cálculos repetidos a gran escala.
Ahora estamos ocupados en acelerar los cálculos de masas. Aquí hay un enlace a los resultados anteriores, y una nueva versión con cálculos más rápidos está lista.
Estoy de acuerdo, no es exactamente un "probador de escala lineal". Se hacen optimizaciones explícitas, lo cual es muy bueno. Sin embargo, no puedo imaginar cómo se puede optimizar para un caso univariante de una situación muy frecuente:
La optimización va para dos parámetros, un parámetro (rango de 100 valores) no toca las llamadas del indicador, el segundo (rango de 5 valores)sí.
En este caso, calculará los valores del indicador 500 veces mientras busca 500 variantes. En este caso, en realidad realizará un gran número de recálculos. Esto se debe a que el rango de la segunda variable es sólo 5, no 500.
Este es sólo el ejemplo más sencillo. Quizás ya se te haya ocurrido alguna idea de cómo sortear esta escalabilidad lineal del probador para el optimizador.
P.D. Son ejemplos como éste los que le dan ventaja a la velocidad en sus propias calculadoras por órdenes de magnitud, no por porcentaje. Pero estas calculadoras no son universales, por lo que la comparación es incorrecta desde el principio.
Ok - digamos que hay un optimizador sin computación en la nube, pero multihilo, y que soporta C++ y MT4 (y todo su subsistema) y es 100 veces más rápido que éste, y 6 veces más rápido puramente por código MT5, sí... y "resuelve" no sólo con fuerza bruta y GA, sino también con unas 50 variantes más. ¿Por cuánto lo comprarías? ¿Lo comprarías por 1000 dólares? ¿Por qué tan caro? Usted y otras diez personas serán los únicos compradores. :)
Sin embargo, no puedo imaginar cómo optimizar para un caso univariante una situación muy frecuente:
Ya me imagino algo (pero no del todo). Antes de ejecutar el optimizador, debe realizar un análisis de dependencia de los parámetros de entrada que se van a optimizar (en el ejemplo anterior, dos variables son completamente independientes). A continuación, la optimización se ejecuta primero a través de las variables independientes del rango más pequeño al más grande (no siempre es correcto, ya que también depende de la intensidad de recursos de los mismos indicadores. A veces es mejor contar 100 veces el indicador luminoso, que 5 veces el pesado), guardando en la memoria los resultados.
Está claro que la implementación de dicha optimización es muy compleja (especialmente para el caso de la nube). Pero si se implementa, entonces al menos absolutamente todos los Asesores Expertos creados en MQL5 Wizard serán optimizados órdenes de magnitud más rápido. Porque el Asistente MQL5 es una combinación de un gran número de indicadores entre sí (es decir, hay un enorme número de parámetros de entrada independientes entre sí). Otra cosa es que esa actividad no tenga sentido para un comercio rentable...
El almacenamiento en caché seguido de resultados de muestreo en muestras enormes (millones y decenas de millones) es más caro que el cálculo directo.
El almacenamiento en caché con muestreo posterior de los resultados en muestras enormes (millones y decenas de millones) es más caro que el cálculo directo.
Estoy seguro de que es casi irreal implementar un optimizador universal perfecto para que sea tan "inteligente" como he descrito anteriormente. Por supuesto, hay margen de mejora, pero no puede ser perfecto en ningún caso.
Muestras enormes (decenas de millones), por supuesto, exageras considerablemente. No hay necesidad de guardar esas cosas en el caché.
Creo que todos entendéis perfectamente lo que quiero decir. Y muchos lo hacen. Nadie te va a criticar por ello, de lo contrario sería la ignorancia del programador de las críticas. Porque los que son adecuados son muy conscientes de la dificultad de aplicar estas cosas.
Permítanme explicar la idea de la caché utilizando el mismo ejemplo:
Si el indicador no se redibuja, al final de una sola ejecución en el probador tendrá un buffer completo de todos los valores del indicador. Ya lo tienes. Y, si la siguiente pasada utiliza los mismos valores del indicador (la segunda variable no ha cambiado), no tenemos que volver a leerla. Puede tomar valores del buffer ya calculado (que ya tiene, no es necesario guardarlo en la caché, la memoria de la ejecución anterior no está completamente libre).
Si el indicador no se redibuja, entonces
Estoy seguro de que es casi irreal implementar un optimizador universal perfecto para que sea tan "inteligente" como he descrito anteriormente. Por supuesto, hay mucho margen de mejora, pero de todos modos no se puede hacer a la perfección.
Muestras enormes (de decenas de millones), por supuesto, has exagerado considerablemente. No hay necesidad de guardar esas cosas en el caché.
Por ejemplo, la prueba del EURUSD de los últimos 11 años da más de 50 millones de ticks.
Esto significa que un simple indicador de un búfer como MA tendrá que almacenar 50 millones de estados (50 millones * 8 bytes(doble) = 400 mb de búfer), lo cual es demasiado. Si se utiliza algo más complejo o más grande en número, de hecho la caché no cabrá en la memoria, y mucho menos los agentes multinúcleo.
Estábamos trabajando en la idea de las cachés de indicadores y resultó que es mucho más rápido y consume menos recursos calcular el siguiente valor del indicador (e incluso con un método económico) que construir cachés.
Sí, precisamente porque es imposible escribir un optimizador universal tan rápido, los trituradores numéricos no universales siempre ganarán en términos de velocidad. Y eso no tiene nada de bueno ni de malo.
No ganan nada.
No tienen entorno de mercado, ni infraestructura, ni indicadores, ni análisis. Y esto es más importante que un ciclo puntual (y ni siquiera representado).
Por ejemplo, la prueba del EURUSD en los últimos 11 años da más de 50 millones de ticks.
Estamos hablando de un optimizador, no de tantas ejecuciones de un solo probador. El concepto de optimizador es bastante diferente. Allí se consiguen importantes ganancias de velocidad a costa de pequeños errores en los resultados. El optimizador no necesita en absoluto modelos basados en ticks. Como mucho, se basan en los precios de apertura. Un optimizador no es un probador, es otra cosa totalmente distinta. Su enfoque es diferente, y también bastante lógico.
No están ganando nada.
No tienen entorno de mercado, ni infraestructura, ni indicadores, ni análisis. Y eso es más importante que un ciclo puntual (y ni siquiera representado).
Ganan en velocidad, porque nada puede ser más rápido que el ciclo for solo. A veces la velocidad es exactamente lo que necesitas, y una calculadora vencerá a cualquier probador universal en velocidad (pero no en otros parámetros). No sólo de MetaQuotes.
No puedo demostrar mi afirmación por la siguiente razón:
Mi calculadora es simplemente una implementación en C++ de mi EA, donde todas las operaciones se hacen específicamente enteras (los precios son enteros), donde los pases innecesarios, etc. se reducen completamente a cero. No hay interfaz allí, nada. La única salida es un archivo con los resultados de la optimización. Es decir, puedo escribir un EA con optimización algorítmica en C++ y mi probador no hará ninguna comprobación de operaciones (por ejemplo, comprobar si hay suficiente margen, etc.). No emulará la historia y no contará con indicadores. No hay nada universal en cuanto a la versatilidad de los probadores de MT5. La única tarea de la calculadora es calcular rápidamente, lo más rápido posible. Y cuenta cien veces más rápido que el probador de MT4, produciendo un error de <1%. No entiendo lo que estoy tratando de mostrar aquí.
Es obvio que el bucle for sin comprobaciones y con sólo enteros siempre contará más rápido que un comprobador universal.