[LAU] OT(ish): Strange coding problem (audio related)

Gabriel M. Beddingfield gabrbedd at gmail.com
Fri Jan 28 14:39:54 UTC 2011



On Fri, 28 Jan 2011, Philipp Überbacher wrote:

> Thanks Peter, this section was supposed to refer to the output of the
> test program. cout printed 11 for both values but 4.80518e-16 for one
> value minus the other, so this at least a very nasty inconsistency.
>
> I still don't understand why this results in 11 on some machines and
> something else on others. 32/64 bit? Compiler differences? Luck?

Truncation error related to (a) how the compiler ordered 
the operations and (b) the log() implementation.  I also 
noticed if you assign `double iters = log(N)/log(2.0)` that 
`k < iters` works as expected on my machine.

But the thing is, he violated one of the priciples taught in 
Programming 101:  floating point comparisons are dangerous!

>    Why can't log mean the same thing everywhere? Why does it need to be

AFAIK, nearly every programming language is consistent that 
log() is the natural log and log10() is the common log. 
This only conflicts with normal mathematical notation.

However, in the case of log(N)/log(2.0)... it doesn't matter 
if it's log-e, log-10, log-2, log-666.... the answer is the 
same.  This is a well-known formula to calculate the number 
of bits required to represent N.

> The next obvious question is: Does the inaccuracy reliably result in
> values bigger than 11?

I like Peter Nelson's solution to do (1<<k) and skip log() 
alltogether.

-gabriel


More information about the Linux-audio-user mailing list