Rockbox mail archive
Subject: Re: Re: berzerk peak meter? Alpha testers wanted.
From: Paul Suade (paul.suade_at_laposte.net)
Date: 20020924
Should be the last one.
I did a mistake and strange enough, when I tried to used to compute j like
gf in the example in http://www.dattalo.com/technical/theory/logs.html I
found less accurate results than the first one despite of my mistake. Really
a surprise...
In fact, using "log2_table[j];" for the fractional part of log2(x) seems
more accurate than "(log2_table[j] +
((x&4095)*(log2_table[j+1]log2_table[j]))>>12);". I'm really puzzled
because the second method should be more accurate than the first one by
linearly smothing the scale effect of the first method !? it should be
another problem of overflowing...
Nonetheless, if precision is enough, using only the first method has the
real benefit to make fflog2 even faster to compute.
By the way, I give here two ways to compute log10, you'de better to use the
one which gets rid of fflog2 and uses log10_table instead since it has the
same result than (fflog2(x)*LOG2_10)>>12 but faster (no multiply at all).
 Original Message 
From: "Paul Suade" <paul.suade_at_laposte.net>
To: <rockbox_at_cool.haxx.se>
Sent: Tuesday, September 24, 2002 3:44 PM
Subject: Re: Re: berzerk peak meter? Alpha testers wanted.
> Overflow bug fixed.
>
> Added fflog10 based on fflog2.
>
> It uses now a fixed point 4.12 bits integer instead of a fixed point 16.16
> bits integer.
>
> Example of results :
>
> fflog10(32767) = 4.50146
> fflog10(20479) = 4.28882
> fflog10(17408) = 4.24048
> fflog10(1279) = 3.08472
> fflog10(264) = 2.4082
> fflog10(72) = 1.85718
> fflog10(18) = 1.25513
> fflog10(15) = 1.17603
> Press ENTER to continue...
Page was last modified "Jan 10 2012" The Rockbox Crew
