On Fri, Oct 14, 2005 at 11:37:30AM +0300, Hannu Savolainen wrote: Pedantic geekiness warning Actually there are 25 fixed-point equivalent bits of precision, due to the implicit 1. Its not much difference, but sometimes it matters. - Steve

On Fri, 2005-10-14 at 10:34 +0100, Steve Harris wrote: With so many experts around, it would be nice to have a small, effecient 16bit -> float, as well as a float -> 16bit (uhm, right, Intel hardware will do this for you, but say you are someahere else) --

First of all, thank you all very much for you comments, the picture is much clearer now. I just don't fully understand the floating-point precission part. If numbers from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I think the implicit 1 does not count), and the numbers from binary 0.01 to 0.1 also have 24 bits of precision, and so on for 0.001..0.01, etc. wouldn't that mean we have a higher resolution? We are using 7 of 8 exponent bits too. Just wasting the cases where the exponent is larger than 0, or has some special meaning.) That would give you 31 bits, minus a couple useless and redundant cases. (when the exponent is -128, and denormalizing ocurrs) Then I also fail to see why it's bad for overflows to ocurr in fixed point. Those signals (above 0dB FS) would clip on the hardware anyway, and are expected to do so, since they were either badly recorded or amplified. Greetings, Dimitri -- Highspeed-Freiheit. Bei GMX superg�nstig, z.B. GMX DSL_Cityflat, DSL-Flatrate f�r nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl

On Fri, Oct 14, 2005 at 09:00:37PM +0200, cpolymeris(a)gmx.net wrote: Obviously, too strong a signal will clip. This of course requires calculations to check for overflow. More likely, such checks will be too slow, so overflow will result in the value "wrapping around", that is, maxint + 1 => minint. This of course sounds really, really bad. Less obviously, too weak a signal will also distort. If the signal is in the range [-6, 5] then there are only 10 discrete values a sample may have, and your signal will sound like it's being played through your PC beeper with a pencil stuck through the cone. Also, any DC offset will indirectly make fewer values available, resulting in either clipping, or lack of precision. These problems don't seem so bad if only the output is considered, but in any audio processing pipeline, there are many more signal paths that must be considered. Imagine all the different signal paths in a filter. It is possible to avoid the mentioned problems using fixed point arithmetic where the "point" is fixed at a different place depending on the expected signal level. However, it's not much fun, and I very much doubt it is significantly faster. By using floating point, you gaurantee that the biggest step between two consecutive values is somewhere between 1/2^23 and 1/2^24th of your signal range (provided you don't run up against the limits of floating point, which is hard to do). Of course there are smaller steps between consecutive values as values approach 0; this is what makes floating-point desirable. In other words, you do have more than 2^24 values available to you, but the worst case difference between consecutive values is never much worse than if you had exactly 2^24 values.

fons adriaensen wrote: I agree with that conclusion. Just don't forget about the denormals issue on Intel (has this been mentioned in this thread before?). However, it's easy to work around this by adding a small amount of noise where necessary. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikwissenschaft.uni-mainz.de/~ag

On Fri, 2005-10-14 at 22:57 +0200, fons adriaensen wrote: The hardware need not be that specialized. Both mmx and altivec implements 16bit saturating add and sub. Signed as well as unsigned.

Very interesting reads. Thanks!

On Mon, Oct 17, 2005 at 02:18:52PM -0400, Paul Davis wrote: I'd agree, but he has some valid points. Using floats may give you the impression that you don't have to care much about how a particular algo works, and that is a trap many a DSP programmer has fallen into. Problems arise when an algorithm systematically subtracts near equal quantities and presents the difference as a valid result, and this does indeed occur easily with low frequency filters. But AFAICS, it's nearly always possible to work around this if you understand the algorithm. The problem occurs mostly when textbook algorithms are implemented literally, and is not confined to audio or DSP. A classic example is the solution of a quadratic equation: a * x * x + b * x + c = 0 The textbook solution is: d = sqrt (b * b - 4 * a * c) x1 = (-b + d) / (2 * a) x2 = (-b - d) / (2 * a) When the magnitudes of d and b are nearly equal (and that occurs systematically in some applications), one of the two results can be very imprecise. (*) To return to the quoted text, I have the impression that the author compares badly implemented float routines with correctly written fixed points ones. It's easy to arrive at a predefined conclusion that way. -- FA (*) The solution is to compute the largest magnitude root first, and then obtain the second one from their product, c / a.