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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
