c++ - resueltos - estadistica elemental solucionario
¿Por qué usarías flotar sobre doble, o doble sobre largo doble? (5)
Sigo siendo un principiante en la programación y siempre tengo más preguntas de las que pueden contestar nuestras búsquedas de libros o de Internet (a menos que me haya perdido algo). Así que pido disculpas por adelantado si esto fue respondido pero no pude encontrarlo.
Entiendo que el flotador tiene un rango más pequeño que el doble, lo que lo hace menos preciso, y por lo que entiendo, el doble de largo es aún más preciso (?). Entonces mi pregunta es ¿por qué querría usar una variable que es menos precisa en primer lugar? ¿Tiene algo que ver con diferentes plataformas, diferentes versiones de SO, diferentes compiladores? ¿O hay momentos específicos en la programación donde es estratégicamente más ventajoso usar un flotador sobre un doble / largo doble?
¡Gracias a todos!
El principio básico aquí sería no usar más de lo que necesita.
La primera consideración es el uso de la memoria, probablemente ya te hayas dado cuenta, si solo estás haciendo un doble, no importa, pero qué pasa si creas un billón de los que usaste el doble de espacio de memoria que tenías.
Lo siguiente es la utilización del procesador, creo que en muchos procesadores, si utiliza tipos de datos más pequeños, puede realizar una forma de subprocesamiento en el que realiza múltiples operaciones a la vez.
Entonces, una extensión a esta parte de la respuesta son las instrucciones de SSE, básicamente, esto le permite utilizar datos empaquetados para realizar múltiples operaciones de punto flotante a la vez, lo que en un caso idealizado puede duplicar la velocidad de su programa.
Por último, es legible, cuando alguien está leyendo su código, si usa un flotador, se dará cuenta de inmediato de que no está superando cierto número. En mi opinión, a veces el número correcto de precisión simplemente fluirá mejor en el código.
El uso de flotadores tiene dos costos, el obvio de su rango y precisión limitados y, menos obvio, el análisis más difícil que imponen esas limitaciones.
A menudo es relativamente fácil determinar que el doble es suficiente, incluso en los casos en que se necesitaría un esfuerzo de análisis numérico significativo para demostrar que la flotación es suficiente. Eso ahorra costos de desarrollo y riesgo de resultados incorrectos si el análisis más difícil no se realiza correctamente.
La mayor ventaja de Float en muchos procesadores es su reducida huella de memoria. Eso se traduce en más números por línea de caché y más ancho de banda de memoria en términos de números transferidos por segundo. Por lo general, cualquier ganancia en el rendimiento de cómputo es relativamente leve: de hecho, los procesadores populares realizan todos los cálculos de punto flotante en un formato que es más amplio que el doble.
Parece que es mejor usar el doble a menos que se cumplan dos condiciones: hay suficientes números para que su huella de memoria sea un problema de rendimiento significativo, y los desarrolladores pueden demostrar que la flotación es lo suficientemente precisa.
Quizás te interese ver la respuesta publicada aquí. ¿Debo usar doble o flotar?
Pero se reduce a la huella de memoria frente a la cantidad de precisión que necesita para una situación determinada. En un motor de física, es posible que le importe más la precisión, por lo que tendría más sentido utilizar un doble o un doble largo.
En pocas palabras: solo debe usar tanta precisión como necesite para un algoritmo dado
Un flotador usa menos memoria que un doble, por lo que si no necesita que su número tenga el tamaño de un doble, también puede usar un flotador, ya que ocupará menos memoria.
Al igual que usted no usaría un autobús para conducir usted y un amigo a la playa ... sería mucho mejor ir en un automóvil de 2 plazas.
Lo mismo se aplica a un doble sobre un doble largo ... solo reserve la memoria que vaya a necesitar. De lo contrario, con un código más complejo, corre el riesgo de utilizar demasiada memoria y de que los procesos se ralenticen o colapsen.
En casi todos los procesadores, los números de punto flotante "más pequeños" toman el mismo o menos ciclos de reloj en ejecución. A veces la diferencia no es muy grande (o nada), otras veces puede ser literalmente el doble de la cantidad de ciclos para double contra float .
Por supuesto, la huella de memoria, que está afectando el uso del caché, también será un factor. float toma la mitad del tamaño del double , y el long double es aún más grande.
Edición: Otro efecto secundario de un tamaño más pequeño es que las extensiones SIMD del procesador (3DNow!, SSE, AVX en x86, y extensiones similares están disponibles en otras arquitecturas) pueden funcionar solo con float , o pueden tomar el doble de float vs . double (y que yo sepa, no hay instrucciones SIMD disponibles para el long double en ningún procesador). Por lo tanto, esto puede mejorar el rendimiento si se usa float vs. double , al procesar el doble de datos de una vez. Fin de edición.
Por lo tanto, suponer que 6-7 dígitos de precisión es lo suficientemente bueno para lo que necesita, y que el rango de +/- 10 +/- 38 es suficiente, entonces se debe usar float . Si necesita más dígitos en el número, o un rango mayor, mueva para double , y si eso no es lo suficientemente bueno, use el long double . Pero para la mayoría de las cosas, el double debería ser perfectamente adecuado.
Obviamente, la importancia de usar "el tamaño correcto" se vuelve más importante cuando tiene muchos cálculos o muchos datos con los cuales trabajar, si hay 5 variables, y solo las usa un par de veces en un programa que sí lo hace. Un millón de otras cosas, ¿a quién le importa? Si está haciendo cálculos de dinámica de fluidos para determinar qué tan bien está funcionando un auto de Fórmula 1 a 200 mph, entonces probablemente tenga que calcular varias decenas de millones de puntos de datos, y cada punto de datos debe calcularse docenas de veces por segundo del viaje de los autos. luego, usar solo unos cuantos ciclos de reloj adicionales en cada cálculo hará que la simulación en general sea notablemente más larga.