Un poco sorprendido :) Pensé en compartir y hacer una pregunta NO retórica. - página 21
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
Es fácil saltar de una declaración fallida a otra.
Cuando se tiene un procesador con tipos de datos racionales y cuando otro conjunto de comandos SSExxx puede manejarlos más rápido que double, entonces se pueden traer los números racionales a la discusión sobre la aceleración de los cálculos. Cuando se publiquen pruebas de cálculo de la SMA con diferentes métodos y se demuestre que se gana sobre el doble, entonces será un discurso de práctica.
Mientras tanto, la afirmación original sobre la aceleración de los cálculos matemáticos reales al pasar a números enteros ha fracasado.
¡¿Qué?! No he saltado nada. Si sólo lees la mitad. Ay. He dicho lo de las fracciones racionales unas veinte veces. Pero hasta que señalé que son fracciones, nadie lo entendió. :) Te digo que es divertido. Ay. :(
:) Failed - Estaba hablando de números enteros y del concepto de PUNTO, y un punto es el denominador siempre. 13000 puntos si un punto es igual a 10000 - entonces el valor es = 13000/10000 = 1,3 :)
¿Qué estás haciendo? No he saltado a ningún sitio. Si sólo lees la mitad. Lo siento. Ya te he hablado veinte veces de las cisternas racionales. Pero hasta que señalé que son fracciones, nadie lo entendió. :) Te digo que es ridículo. Ay. :(
:) Failed - Estaba hablando de números enteros y del concepto de PUNTO, y un punto es el denominador siempre. 13000 puntos si un punto es igual a 10000 - entonces el valor es = 13000/10000 = 1,3 :)
Se propone procesar tres longs de 8 bytes (parte entera + denominador + numerador) en lugar de un doble de 8 bytes. Y si empiezas a cortar los largos en algo más corto, tendrás un desbordamiento en los cálculos bastante adecuado.
Incluso tres ints y esos son más de una toma.
Se propone procesar tres longs de 8 bytes (parte entera + denominador + numerador) en lugar de un doble de 8 bytes. Y si empiezas a cortar los largos a algo más corto, obtendrás un desbordamiento en los cálculos bastante adecuado.
Has elegido la peor manera de aplicarlo. Teniendo en cuenta lo que me has dicho, no tiene sentido. ¿Quién de nosotros lo sabe mejor?
Hay un número en kilómetros - es int32 Y no necesita nada más. Simplemente no hay que sumarlo con un valor en otra dimensión. :) Si quiere más precisión que los kilómetros, pase a los nanómetros. :) Y guardarlos como un número entero. :)
TheXpert:
Y en segundo lugar, dudo mucho que la aritmética con doble sea más lenta que con números racionales.
Wapchet más lento. Pero nos proporcionó un enlace equivocado.
1. La implementación en BOOST normaliza los números de ración en cada operación con ellos. Esto no tiene que hacerse en todos los casos, ya que es caro. Es mejor hacerlo sólo cuando haya una amenaza real de desbordamiento del denominador.
2. La reducción a un denominador común (más precisamente, el cálculo del mayor común divisor) no se realiza allí por el algoritmo más rápido. Con mucho, el más rápido.
Con corrección, tiene razón sobre la velocidad de los números racionales.
Los tendría en mql, si la recarga de operaciones aritméticas estuviera disponible. Sin ella mi sintaxis sería muy tediosa (funcional), así que olvídate de ella... С++ :-)
--
Pero sería genial que hubiera soporte a nivel de procesador...
Wapchetta más lento. Sólo que el enlace que dio era erróneo.
1. La implementación en BOOST normaliza los números de ración en cada operación sobre ellos. No hay que hacerlo en todos, porque es caro. Es mejor hacerlo sólo cuando haya una amenaza real de desbordamiento del denominador.
2. La reducción a un denominador común (más precisamente, el cálculo del mayor común divisor) no se realiza allí por el algoritmo más rápido. Por mucho, hay uno más rápido.
Dicho esto, tiene razón en cuanto a la velocidad de los números de rati.
Los tendría en mql, si la recarga de operaciones aritméticas estuviera disponible. Sin ella, obtendría una sintaxis muy tediosa (funcional), así que olvídate de ella... С++ :-)
--
Pero sería genial que hubiera soporte a nivel de CPU...
La aritmética en sí es más lenta porque todavía tenemos que manejar la coma flotante (eso si comparamos la aritmética pura de dobles y largos), si convertimos los dobles a aritmética de enteros perdemos. El cálculo recurrente de NOD por sí solo requeriría log(N) operaciones, sin mencionar el hecho de que cada operación de multiplicación requeriría si para comprobar el desbordamiento. Luego 4 divisiones más (dos por NOD y para extraer la parte entera y el resto fraccionario).
Por si fuera poco, todavía tendrías que asignar más memoria para almacenar todas estas tonterías de la que necesitarías para la toma.
Wapchet más lento. Sólo el enlace que citó fue desafortunado.
¿Pruebas? Desde luego, para mí tienes más autoridad que el escritor original, pero esa es una afirmación fuerte.
Por lo tanto, me gustaría ver pruebas comparativas.
La aritmética en sí es más lenta porque todavía tiene que manejar el punto flotante (eso si comparas la aritmética doble y larga pura),
1. Si conviertes los dobles a aritmética de enteros, pierdes.
2. sólo el cálculo recurrente de NOD requeriría log(N) operaciones, por no mencionar el hecho de que
3. Cada operación de multiplicación requerirá que se compruebe si hay desbordamiento.
4. Luego 4 divisiones más (dos por NOD y para extraer la parte entera y el resto fraccionario).
5. Además de todo esto, todavía tendrás que asignar más memoria para almacenar todas estas tonterías de la que necesitas para la toma.
1. Es una operación única para cada toma. La pérdida es insignificante, luego las ganancias son sólidas. :) Supongo que el cociente original se logaritma una vez y se convierte en representación entera.
2. esto es correcto. Aunque es rápido, porque hay un algoritmo rápido que utiliza desplazamientos de bits.
3. no más que controles de desbordamiento.
4. la parte de enteros no necesita ser asignada en absoluto. la fracción se almacena como un par de longs. y si es posible, como un par de ints.
5. Exactamente la misma cantidad si se almacena como un par de longs, y la mitad en el caso de que haya suficientes ints (depende de los requisitos del algoritmo).
Si tenemos en cuenta que el principal consumidor de memoria es una cita, con la representación de enteros la ganancia de espacio es innegable.
Aunque el punto principal no está en el ahorro de memoria, sino en la aceleración. Esto es mucho más importante.
--
El problema con el Académico no es que esté equivocado. Es que hace que los demás queden mal.
Eso es lo que irrita a los presentes y rechaza las ideas sanas... Junto con el agua sucia... :(
Por lo tanto, me gustaría ver pruebas comparativas.
Lo intentaré. En el mql5, si se llega a eso... :)
Sólo necesito algo de tiempo. Tendría que escribir una biblioteca.
Lo intentaré. En mql5, si se llega a eso... :)
¿Para qué? Se acepta C++.
El problema con el académico no es que esté equivocado. Es que hace que los demás queden mal.
El problema es que se cree más listo que los demás y trata constantemente de ridiculizar a los demás.
Y la caga. En algunos lugares, mucho.
El problema con el académico no es que esté equivocado. Es que hace que los demás queden mal.
Esto es lo que irrita a los presentes y rechaza las ideas sanas... Junto con el agua sucia... :(
No me meto en la cabeza de nadie. Pero estoy invertido. :) ¿Quién ha pedido consejo sobre "debo seguir el tema"? :)
Y entonces yo soy el que está en el que está... :) Bueno, no vengas a mí.
¿Cuál es la diferencia en general? ¿Qué hay que discutir? En mi opinión, todo sigue en el mismo nivel embrionario que antes. Así que no hay ningún problema conmigo, es como si no existiera. :)