Mientras escribía un libro sobre Wolfenstein 3D quería demostrar cláramente cuán difícil era trabajar sin coma flotante. Mis intentos personales de entender la coma flotante leyendo los habituales artículos canónicos encontraban resistencia significativa de mi cerebro. Intenté encontrar una forma diferente. Algo lejos de (−1)^S∗1.M∗2^(E−127) y sus misteriosos exponente/mantisa. Posiblemente un dibujo, ya que parecen fluir a través de mi cerebro sin esfuerzo.
|
etiquetas: coma flotante , floating point
www.meneame.net/search?q=coma++++flotante&w=links&p=tags&s
es de 1985, muy posterior a los mainframes.
No era este el enlace concreto pero creo que vale como referencia. Por cierto que cobol tiene revisiones de los 80.
a mi de me pasó aprender ese detallito y lo descubrí hace poco. Una escala lineal para el ultimo tramo entre el número más pequeño normal y el cero
Like si eres tan palurdo como yo.
Ambas representaciones son necesarias para entender la coma flotante.
Especialmente para hacer algoritmos matemáticos es mejor irse al álgebra antes que darle directamente al código. Uno se puede llevar sorpresas de cuántos bucles te puedes quitar usando el álgebra y sus teoremas antes de lanzarse a programar.
Joder, qué viejo soy.
La cosa es que el coprocesador x87 funcionaba con una pila: tú bloqueabas la cpu y pasabas el control al coprocesador y éste podía encadenar muchas operaciones en punto flotante seguidas, en el sentido de que tenía una pila y añadía y quitaba operandos y aplicaba operaciones, manteniendo una alta precisión. Pero antes los datos eran de 32/64 bits y después volvían a serlo, por lo que había que transformarlos, lo cual restaba mucho rendimiento si sólo ibas a hacer operaciones simples.
SSE funcionaba directamente con registros: no hacía falta bloquear la cpu (hasta donde yo sé), no hacía falta conversiones previas/posteriores (trabajaba directamente en 64/32 bits) y además funcionaba como una máquina vectorial (podías ejecutar serialmente la misma instrucción muchas veces sobre un conjunto de datos como una cadena de montaje, con el consiguiente aumento de rendimiento).
La parte divertida, es que se descubrió que la implementación de physics por cpu de Nvidia usaba instrucciones x87 para realizar sus cálculos y no SSE, con lo cual había una pérdida brutal de rendimiento si usabas hardware no nvidia y activabas las físicas.
En fin, todo esto para decir que muchas veces se usaba aritmética entera para realizar operaciones de raster incluso a costa de precisión antes que usar operaciones en coma flotante porque salvo que usaras muchas operaciones y necesitaras un error muy muy pequeño, te salía muy a cuenta. Y si queremos ver el error en la precisión de estos cálculos, podemos ver en algunos vídeos de juegos antiguos como hay polígonos que "bailan" un poco de posición según se mueve el personaje (se nota sobre todo en las armas de algunos fps, que están a primer plano y se mueven relativamente poco)
Y después hay infinidad de trucos para evitar ciertas operaciones (como usar tablas con operaciones ya hechas e interpolar), al fin y al cabo, una división no es más que restar muchas veces, si es por un múltiplo de dos equivale a un desplazamiento de bits y en todo caso en una ecuación puedes cambiar una división por una multiplicación al otro lado de la igualdad (que la multiplicación es mucho más barata que la división), todo es darle un par de vueltas a las ecuaciones para sacar operaciones más eficientes en cada momento.