Jotap_66, a continuación la respuesta del técnico en el foro foráneo a tu respuesta a su post:

¡Hurra! He sido semi validado.

Cita Iniciado por jotap_66 Ver mensaje
Efectivamente...Tiene razon en que si los sumas ordenadamente, el problema desaparece...pero claro, esto muchas veces no es posible (reescribir el algoritmo)....El ordenador esta resolviendo un problema, y una simple suma de dos numeros 1 y 1e-13 te lo fastidia todo.....Como dice esta persona, se puede aumentar la precision a 64 bits....Es una posibilidad, pero hasta hace poco no era nada facil...
El x86 viene teniendo doble precisión desde hace ya décadas. Ciertamente, encontrar equipos de audio que funcionen internamente en doble precisión puede haber sido imposible. (Lo siento, soy del mundo de la informática, no del de audio, así que sé menos sobre ello). Y, claro está, hay grandes problemas de funcionamiento en la doble precisión en general. Pero en ausencia de estas preocupaciones, no creo que muchas personas se queden despiertos por la noche preocupados por problemas de precisión, cuando tienen un trayecto de doble precisión que funciona maravillosamente.

Estoy de acuerdo en que no todos los algoritmos pueden evitar los problemas de precisión, pero algunos de ellos sí. Muchas de las decisiones que se toman en torno al diseño de un filtro digital tienen su base en problemas de cuantización - notablemente, escoger entre las diferentes formar de filtros IIR (Respuesta Infinita al Impluso) y FIR (Respuesta Finita al Impulso).
Cita Iniciado por jotap_66 Ver mensaje
Hoy dia la misma notacion IEE 754 contempla los 64 bits e incluso, ciertos micros como el PowePc, hasta 96...Y hombre lo de que si tienes problemas sigues aumentando la precision, pues como que no tiene mucho sentido....

Lo que si me llama la atencion (volviendo al tema audio) es que dice que no esta nada claro lo de que usar los 32 bits en coma flotante sea mejor que con 32 bits enteros....
De nuevo, todo depende de para qué lo estás utilizando. A veces necesitas más mantisa, en otras ocasiones precisas más exponente. Yo soy de los que creen que cualquier cosa por encima de 16 bits no es necesario para la música final, pero durante su procesador puedo pensar en montones de razones por las que me gustaría tener esos 8 bits extra dedicados a un exponente en vez de mayor precisión. En otras situaciones, por ejemplo en trabajo con filtros IIR, dependiendo en los que estás haciendo querrás mucho tener una mantisa de 32 bits. Todo depende de la situación.

Existe un fascinante paralelo a esto en el mundo de las tarjetas de vídeo. Como todos probablemente sabéis, el vídeo en los ordenadores empezó como 4 bits (CGA), luego 8 bits (VGA), luego 16 bits depués 24 bits y 32bits. Todo esto era con números enteros. Comenzando alrededor del año 2000 hubo un empuje por parte de los programadores gráficos, insignemente notably John Carmack, para que nVidia/ATI implementara un trayecto de color en coma flotante, empezando con color a 64 bits -16 bits por color, compuesto de 1 signo, 10 mantisas, 5 exponentes.

A continuación una cita de un post de Carmack, hace más de 7 años. Mucho de lo que cuenta en ella es anáñogo al audio. Noten, específicamente, cómo la renderización de un videojuego se ha trasladado de donde las texturas y el color tienen un bien definido rango (0,1) a un rango ilimitado. Y también cómo aunque puede que necesites esta precisión añadida para tus cálculos, no la necesitas para el formato de salida final. La analogía en el mundo del audio es que utilizar 32 bits coma flotante en el trayecto de datos al procesar no justifica la utilización de más de 16 bits en el formato de salida.
Range is even more clear cut. There are some values that have intrinsic ranges of 0.0 to 1.0, like factors of reflection and filtering. Normalized vectors have a range of -1.0 to 1.0. However, the most central quantity in rendering, light, is completely unbounded. We want a LOT more than a 0.0 to 1.0 range. Q3 hacks the gamma tables to sacrifice a bit of precision to get a 0.0 to 2.0 range, but I wanted more than that for even primitive rendering techniques. To accurately model the full human sensable range of light values, you would need more than even a five bit exponent.

... "Do we need it in the front buffer?" Probably not. Going to a 64 bit front buffer would probably play hell with all sorts of other parts of the system. It is probably reasonable to stay with 32 bit front buffers with a blit from
the 64 bit back buffer performing a lookup or scale and bias operation before dithering down to 32 bit. Dynamic light adaptation can also be done during this copy. Dithering can work quite well as long as you are only performing a single pass.s.