Re: OT(ish): Strange coding problem (audio related)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Excerpts from Peter Nelson's message of 2011-01-28 13:03:56 +0100:
> On Fri, 2011-01-28 at 12:28 +0100, Philipp Ãberbacher wrote:
> 
> > Interesting.. would you mind explaining how this can be?
> > How can 11-11 yield 4.80518e-16? 
> 
> Because, rather than 11, log(2048)/log(2.0) is actually (to 40 d.p.)
> 
> 7.6246189861593984035895533360399422488305 /
> 0.6931471805599453094172321214581765680755
> 
> But doubles don't contain 40 d.p.; it is approximately 16. Thus some
> rounding errors may occur...
> 
> Peter.

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?

rant_begin
    Why can't log mean the same thing everywhere? Why does it need to be
    base e here and base 10 there? Why is there no consistency?
    And why is there no proper logarithmus dualis function? Because you
    can simply do log(n)/log(2)? We've just seen how well this works.
    How about:
        log() - base 10
        ln() - base e - logarithmus naturalis
        ld() - base 2 - logarithmus dualis
rant_end

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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux