On Tue, Dec 22, 2015 at 11:34 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Tue, Dec 22, 2015 at 12:48 PM, Ganesh Ajjanagadde <gajja...@mit.edu> > wrote: >> >> On Tue, Dec 22, 2015 at 8:04 AM, Ganesh Ajjanagadde <gajja...@mit.edu> >> wrote: >> > On Tue, Dec 22, 2015 at 3:35 AM, Michael Niedermayer >> > <mich...@niedermayer.cc> wrote: >> [...] >> >> >> >> IMHO a exp10 fallback should be implemented using exp2() if that is >> >> faster >> >> and available. >> > >> > I don't know whether the fallback should use exp or exp2, need to >> > check which is faster. And if we fallback to exp or exp2, it will turn >> > out that the fallback is significantly faster than the actual libm >> > function (as demonstrated above, like erf), nothing wrong with that, >> > just is somewhat strange. >> > >> >> >> >> Code requiring absolute accuracy must be written using integers as C >> >> does not gurantee accuracy for float and double. >> >> A single libc or fallback providing more accuracy does not really help >> >> as our code must function correctly in the absence of such accuracy >> >> also the accuracy difference between exp2() and pow() should be >> >> negligible >> > >> > A lot of our floating point code assumes IEEE-754, which has >> > reasonably well defined semantics. Anyway, as a general statement, I >> > agree. >> > >> > For a proper libm, exp2(x) and pow(2, x) should be identical. I guess >> > what you are referring to is exp2(log2(10)*x) vs pow(10, x). In this >> > case, I don't know how bad the difference is; I suspect it to be more >> > than 1 ulp in some cases. >> >> Definitely way more than 1 ulp. Looks like exp2 fallback is the way to go: >> 1. speed: it is approximately 25% faster on GNU libm, even faster on >> BSD/Mac OS X and other libm's due to a table lookup approach. >> 2. accuracy: it is marginally better. Measurement was via 3e8 points >> spaced evenly from -310 to 310, maximum relative error is 1.7e-13 vs >> 1.8e-13. For values in the 64 bit range (roughly 10^0 to 10^20), error >> is around 7.5e-15. Basically errors are amplified at very small and >> very large values which is intuitively clear. In fact, that is exactly >> what GNU libm does: splits the exponent into a main term and a >> correction term, computes exp twice, and then multiplies the two >> together. >> >> Really, I guess the question is: >> are people ok with this accuracy loss on non GNU/Linux? > > > I think "yes".
Thanks, will post later today. > > You'd use M_LOG2_10 instead of log2(10), right? Of course, I just gave it as I forgot the actual constant name :). > > Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
