IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Q: floating-point, losslessness from http://www.wavpack.com/technical.
Porcus
post Feb 17 2012, 17:00
Post #1





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



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.)

This post has been edited by Porcus: Feb 17 2012, 17:37


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
saratoga
post Feb 17 2012, 17:06
Post #2





Group: Members
Posts: 4718
Joined: 2-September 02
Member No.: 3264



QUOTE (Porcus @ Feb 17 2012, 11:00) *
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.
Go to the top of the page
+Quote Post
pdq
post Feb 17 2012, 17:29
Post #3





Group: Members
Posts: 3305
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



This Wikipedia article describes the 1994 Pentium floating point divide bug. I have not heard of any such bug since then.
Go to the top of the page
+Quote Post
bryant
post Feb 17 2012, 19:18
Post #4


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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.
Go to the top of the page
+Quote Post
saratoga
post Feb 17 2012, 19:19
Post #5





Group: Members
Posts: 4718
Joined: 2-September 02
Member No.: 3264



QUOTE (pdq @ Feb 17 2012, 11:29) *
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!

This post has been edited by saratoga: Feb 17 2012, 19:20
Go to the top of the page
+Quote Post
Porcus
post Feb 17 2012, 23:49
Post #6





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



QUOTE (bryant @ Feb 17 2012, 19:18) *
That document is very outdated, but that part is true.


Confirming my guess then smile.gif

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.)


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th April 2014 - 01:29