[FFmpeg-devel] [PATCH][RFC] lavu/libm: add exp10 support

[Ronald S. Bultje]

Hi,

On Tue, Dec 22, 2015 at 12:48 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
wrote:

> On Tue, Dec 22, 2015 at 8:04 AM, Ganesh Ajjanagadde <gajjanag at mit.edu>
> wrote:
> > On Tue, Dec 22, 2015 at 3:35 AM, Michael Niedermayer
> > <michael at 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".

You'd use M_LOG2_10 instead of log2(10), right?

Ronald