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

[Ganesh Ajjanagadde]

On Tue, Dec 22, 2015 at 11:34 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 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".

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