Un poco sorprendido :) Pensé en compartir y hacer una pregunta NO retórica. - página 16
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
Te digo que los principiantes... La comprensión vendrá con la experiencia.
Buen punto. Es una buena. :)
Estás exagerando con el novato. ¿De qué estamos discutiendo ahora? :)
Descubre las matemáticas. :)
==
Añadiré... tal vez alguien lo haga... puedes empezar por mirar esto.
http://en.wikipedia.org/wiki/%E2%84%9A
y aquí http://demonstrations.wolfram.com/RationalNumberExplorer/
y aquí http://www.solarix.ru/for_developers/cpp/boost/rational/ru/rational.shtml
Las caritas sonrientes de tus próximos mensajes serán recortadas. Tenlo en cuenta.
La conversión de precios a valores enteros no tiene ventajas significativas. Sí, reduce eficazmente los volúmenes, pero tiene muchas veces menos velocidad debido a la inevitable conversión a doble. Precisamente es inevitable, porque no se puede hacer todo el sistema entero, la matemática computable todavía tiene que hacerse en doble (que ni siquiera tiene suficiente precisión).
Lo secundo. Por eso escribí antes:
P.D. Tus cifras son claramente inexactas: la historia INT no puede ocupar 2,1Gb y la historia DOBLE no puede ocupar 7Gb. La diferencia debe ser siempre exactamente 2(USHORT no es suficiente) veces. Pasar a la aritmética de enteros con los precios da una ventaja significativa cuando toda la lógica de un EA puede ser sustituida por la lógica de enteros. Esto no ocurre muy a menudo.
Tengo la calculadora más tonta pero más rápida, todo es entero, porque sólo tiene operaciones de suma, resta y comparación. En consecuencia, no es necesario pasar de INT a DOBLE.
En general, la optimización algorítmica en casos particulares siempre da una ventaja en velocidad de ejecución (no de escritura) sobre el enfoque general. Así, por ejemplo, si su Asesor Experto utiliza la auto-optimización de sus parámetros, la cuestión de la velocidad de auto-optimización es muy importante. Y es razonable crear, ya sea en DLL o directamente en MQL5, un Asesor Experto optimizado algorítmicamente al máximo. Y no utilice el optimizador MT5 para la autooptimización. Desafortunadamente, MT5-optimizer para Asesores Expertos auto-optimizados es adecuado para casos muy limitados.
Lo secundo. Por eso escribí antes:
En mi calculadora más tonta pero más rápida, todo está en números enteros, porque sólo hay operaciones de suma, resta y comparación. El cambio de INT a DOBLE, respectivamente, es innecesario.
En general, la optimización algorítmica en casos particulares siempre da una ventaja en la velocidad de ejecución (no de escritura) sobre el enfoque general. Así, por ejemplo, si su Asesor Experto utiliza la auto-optimización de sus parámetros, la cuestión de la velocidad de auto-optimización es muy importante. Por lo tanto, es razonable crear, ya sea en DLL o directamente en MQL5, su propio Asesor Experto optimizado algorítmicamente al máximo. Y no utilice el optimizador de MT5 para los casos de auto-optimización. Desafortunadamente, el optimizador incorporado para los Asesores Expertos auto-optimizados es bueno para casos limitados.
¿Puede dar un ejemplo de cuándo no se puede evitar la traducción al doble?
Otro ejemplo es cuando necesitamos calcular el valor porcentual de algo o su probabilidad.
En el primer caso, tomamos un pip como 0,0001 de un porcentaje y 1,2345% serán 12345 puntos.
Lo mismo ocurre con la probabilidad.
Siempre hay que tener en cuenta que incluso la profundidad de bits del doble es limitada y que siempre hay puntos ocultos.
¿Dime un ejemplo en el que necesites convertir a doble?
Un ejemplo contrario sería calcular el porcentaje de algo o la probabilidad.
En el primer caso, tomamos un pip como 0,0001 de un porcentaje, en cuyo caso 1,2345% son 12345 puntos.
Lo mismo ocurre con la probabilidad.
Siempre hay que tener en cuenta que incluso la profundidad de bits del doble es limitada y que siempre hay puntos ocultos.
Bueno, ¡qué emboscada! La humanidad está desarrollando la ciencia de los números en la dirección equivocada. Los números reales, y mucho menos los complejos, se han inventado en vano. - ¡Muy simplemente algunas personas resultan ser capaces de hacer con un número de enteros!
¿No ves un ejemplo?