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.
![Explicación visual de la coma flotante [ENG]](https://cdn.mnmstatic.net/cache/32/70/media_thumb_2x-link-3305561.jpeg?1588707486)
Comentarios
Me encanta el look de la página: tiene un cierto aire retro pero está muy bien currada.
#1 A mi me gusta el aspecto que le da la fuente monoespaciada. Yo la uso siempre que puedo en todos sitios.
#5 de las tipografías gratis es de las que más molan.
#1 Es que este tío (siempre se me olvida su página) deberían darle un sueldo de profesor, porque otros análisis que hace como el de fuego del doom es espectacular.
#17 Le he donado 10$ porque sacar la lengua a paseo es gratis.
#19 Ahorras un montón de ciclos. Es posible hacer algoritmos de rellenado de polígonos con sombreado usando sólo números enteros, no es un muy complicado y en bajas resoluciones muy resultón. A partir de ciertas resoluciones ya necesitas raster por hardware para conseguir tasas de frames respetables para según qué cosas.
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.
Relacionada: Una herramienta para aprender cómo funciona la coma flotante
Una herramienta para aprender cómo funciona la com...
evanw.github.ioA mi la representación de la fórmula me parece más intuitiva para entender las matemáticas y el concepto del diagrama de celdas me parece más útil para hacerme una idea visual de cómo se almacena en la memoría. No son exactamente lo mismo.
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.
#13 Efectivamente, se programa con papel y lápiz.
Qué recuerdos me ha traído lo del coprocesador matemático 387. Yo tenía un 386 en los tiempos de Carolo y me gustaba el tema de los gráficos en 3D, los fractales, etc. Cada imagen tardaba muchísimo en generarse, hasta que me compré el 387 y aquello fue una gloria bendita. Aquel ordenador me duró toda la época del 486 y ya mi siguiente PC fue un Pentium.
Joder, qué viejo soy.
#14 Mi primer PC también fue un 386 que aún conservo en casa a modo de pieza de museo totalmente funcional.
#14 Tiene guasa que los primeros coprocesadores matemáticos de intel, los x87 operaran con 80 bits, mientras los flotantes actuales son de 32 o 64. Daba una mayor precisión en los cálculos, pero al tener que transformar de 64 a 80 y de 80 a 64 se perdía bastante tiempo y por eso a partir del pentium 4 la cosa cambió (se introdujeron SSE y la forma de trabajar con flotantes).
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)
#18 Amén, gracias por la explicación. Por cierto, creo recordar que FRACTINT era un programa que generaba gráficos fractales de forma muy eficiente, y que el truco era que realmente operaba con enteros y ahorraba operaciones de coma flotante. De ahí lo del "INT" en el nombre.
#7 Yo lo que veo ahí es precisamente lo de mantisa + exponente, o sea lo de siempre.
¿Menciona los números subnormales?
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
https://es.wikipedia.org/wiki/Coma_pitagórica
¿Otra vez?
https://www.meneame.net/search?q=coma + flotante&w=links&p=tags&s=&h=&o=&u=
Tan visual, que llevo un rato en la página y no sé ni atinar cual es la imagen esa a la que se refiere.
Like si eres tan palurdo como yo.
Esto sale en los manuales de ibm de los mainframes (de hace mucho)
#3 https://en.wikipedia.org/wiki/IEEE_754
es de 1985, muy posterior a los mainframes.
#6 https://www.ibm.com/support/knowledgecenter/SS6SG3_6.2.0/lr/ref/rlddedat.html
No era este el enlace concreto pero creo que vale como referencia. Por cierto que cobol tiene revisiones de los 80.