Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Q: floating-point, losslessness from http://www.wavpack.com/technical. (Read 7147 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Q: floating-point, losslessness from http://www.wavpack.com/technical.

I quote:
Quote
I have decided to not use any floating-point arithmetic in WavPack's data path because I believe that integer operations are less susceptible to subtle chip to chip variations that could corrupt the lossless nature of the compression, the recent Pentium floating point bug being a blatant example of this.


Is this obsoleted, in the sense that Bryant has found that one can now trust floating-point arithmetic, or does it mean that even floating-point .WV files are created using fixed-point arithmetic, without any use of the processor's floating-point internals?


(Edited for clarification.)

Q: floating-point, losslessness from http://www.wavpack.com/technical.

Reply #1
Is this obsoleted, or does it mean that one does not use the processor's floating-point internals?


I don't know about wavpack specifically, but lossless formats tend not to use floating point since addition and multiplication is subject to a somewhat difficult to predict rounding error, which complicates using them for lossless compression.

Q: floating-point, losslessness from http://www.wavpack.com/technical.

Reply #2
This Wikipedia article describes the 1994 Pentium floating point divide bug. I have not heard of any such bug since then.

Q: floating-point, losslessness from http://www.wavpack.com/technical.

Reply #3
That document is very outdated, but that part is true. WavPack does not use floating-point for encoding or decoding, and that applies even to the floating-point audio support (the values are disassembled into integers first thing).

FLAC does not use floating-point for decoding either. However, it does use it for encoding but is done in such a way that variations in implementations cannot cause problems. There was a generally civil discussion of it here.

Q: floating-point, losslessness from http://www.wavpack.com/technical.

Reply #4
This Wikipedia article describes the 1994 Pentium floating point divide bug. I have not heard of any such bug since then.


If you read the entire quote, not just the truncated version Porcus posted, I don't think he means to single out that particular bug.  Its just an example:

Quote
I have decided to not use any floating-point arithmetic in WavPack's data path because I believe that integer operations are less susceptible to subtle chip to chip variations that could corrupt the lossless nature of the compression, the recent Pentium floating point bug being a blatant example of this.  It is possible that a lossless compressor that used floating-point math could generate different output when running on that faulty Pentium. Even disregarding actual bugs, floating-point math is complicated enough that there could be subtle differences between "correct" implementations that could cause trouble for this type of application.


Basically, the main problem is not that hardware can be buggy (although that is also a problem), but rather that different CPUs can execute the same sequence of floating point operations and come to slightly different answers without being buggy.  In contrast, integer operations are (virtually) always exactly defined and so should produce identical results on different machines (assuming equivalent register size at least).  For this reason, its usually preferable to use integers and explicitly define your rounding operations rather then implicitly rely on hardware implementations which are subject to change in the future.  That way you can be certain that your lossless files will continue to be lossless on future CPUs.

Ah, too slow!

 

Q: floating-point, losslessness from http://www.wavpack.com/technical.

Reply #5
That document is very outdated, but that part is true.


Confirming my guess then 

Well I do think I need a different filetype to easier distinguish out certain CD rips in my archive, so ... technically, that means you can count in another user. (And so reading the features made me curious, thus the question.)