Excerpts from torbenh's message of 2011-02-01 14:00:17 +0100: > On Sun, Jan 30, 2011 at 02:29:13PM +0100, Philipp Ãberbacher wrote: > > Excerpts from Peter Nelson's message of 2011-01-29 13:47:07 +0100: > > > On Sat, 2011-01-29 at 12:07 +0100, Philipp Ãberbacher wrote: > > > > Excerpts from fons's message of 2011-01-28 16:11:52 +0100: > > > > > On Fri, Jan 28, 2011 at 02:02:36PM +0100, Philipp Ãberbacher wrote: > > > > > > > > > > > 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 > > > > > > > > > > Libm has log(), log10, and log2(). > > > > > > > > Took me a while to figure out that libm is part of glibc :) > > > > Good to know that those functions are available on probably pretty much > > > > all linux systems. > > > > > > > > > > The next obvious question is: Does the inaccuracy reliably result in > > > > > > values bigger than 11? > > > > > > > > > > No. > > > > > > > > > > If the input is a power of two, and you expect an integer as > > > > > a result, just do > > > > > > > > > > k = (int)(log2(x) + 1e-6) > > > > > > > > log2() suffers from the same problem? I somewhat dislike the idea of > > > > adding a constant. > > > > > > > > > or > > > > > > > > > > k = (int)(log(x)/log(2) + 1e-6) > > > > > > > > > > or > > > > > > > > > > int m, k; > > > > > for (k = 0, m = 1; m < x; k++, m <<= 1); > > > > > > > > > > which will round up if x is not a power of 2. > > > > > > > > Neat. I thought about it myself yesterday but my ideas weren't exactly > > > > brilliant. One idea was to divide by 2, the other to use a small > > > > lookup table for powers of 2. I don't really know about efficiency, but > > > > I guess bit shifting is as efficient as it gets? > > > > Anyway, it's a neat way to avoid the problem and the rounding properties > > > > of mult/div in case of not power of 2 could be useful as well. > > > > > > Well, now I'm just being pedantic :-), but as a quick test using rdtsc > > > (i.e. profiling to be taken with a grain of salt): > > > > > > 1: log(x)/log(2) > > > 2: (1 << k) < x > > > 3: m < x & m <<= 1 > > > > > > This is 1000 iterations; cycling through x of 512, 1024, 2048, 4096 (to > > > prevent the compiler optimizing log(x)/log(2) to a single call > > > throughout the whole test). The fourth line is the sum of the iterator > > > in each loop. > > > > > > ./a.out (unoptimized) > > > 1 3132000 cycles > > > 2 261468 cycles > > > 3 285273 cycles > > > 1 50500, 2 50500, 3 50500 > > > > > > ./a.out (-O3) > > > 1 2598345 cycles > > > 2 170055 cycles > > > 3 173673 cycles > > > 1 50500, 2 50500, 3 50500 > > > > > > I must admit, I'm surprised that fons way shows slightly slower in my > > > test! > > > > Is it really surprising (for the non-optimised variant)? Your variant > > uses one less variable and assignment. That this isn't optimised away > > completely with -O3 does surprise me too. > > > > > As an aside, here's the result with (-O3 -ffast-math) > > > > > > ./a.out > > > 1 150894 cycles, > > > 2 169983 cycles, > > > 3 158850 cycles, > > > 1 47750, 2 50500, 3 50500 > > > > > > Yeah, faster, but wrong :-) > > > > > > Peter. > > > > After a brief look at man gcc -ffast-math doesn't seem like a very good > > idea to use it in general, so no surprise it's not part of -O3 or > > something. > > i like -ffast-math... this whole thread is about float not being exact. > sure its worse with -ffast-math ... but if you dont assume correctness, > and do appropriate workarounds in case where you need correct results, > its the way to go. Since --ffast-math is a collection of other options I would have thought that you'd pick the ones that make sense for your use case instead of --ffast-math. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
