On Fri, Dec 25, 2015 at 9:55 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > On Fri, Dec 25, 2015 at 9:47 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >> On Fri, Dec 25, 2015 at 6:27 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >>> On Fri, Dec 25, 2015 at 9:26 AM, James Almer <jamr...@gmail.com> wrote: >>>> On 12/25/2015 2:11 PM, Ganesh Ajjanagadde wrote: >>>>> Fast, reasonably accurate 10^x. Alternative of detection of libm exp10 at >>>>> configure >>>>> time is not worth the trouble, since it is anyway not POSIX or ISO C, >>>>> and currently only the GNU libm has it. Furthermore, GNU libm's variant >>>>> is ~ 2x slower, and is ironically not correctly rounded (2 ulp off) to >>>>> justify all >>>>> that slowdown. >>>>> >>>>> Reviewed-by: Michael Niedermayer <mich...@niedermayer.cc> >>>>> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >>>>> --- >>>>> libavutil/internal.h | 19 +++++++++++++++++++ >>>>> 1 file changed, 19 insertions(+) >>>>> >>>>> diff --git a/libavutil/internal.h b/libavutil/internal.h >>>>> index f86b7fb..ae11601 100644 >>>>> --- a/libavutil/internal.h >>>>> +++ b/libavutil/internal.h >>>>> @@ -292,6 +292,25 @@ static av_always_inline av_const int64_t >>>>> ff_rint64_clip(double a, int64_t amin, >>>>> return res; >>>>> } >>>>> >>>>> +/** >>>>> + * Compute 10^x for floating point values. Note: this function is by no >>>>> means >>>>> + * "correctly rounded", and is meant as a fast, reasonably accurate >>>>> approximation. >>>>> + * For instance, maximum relative error for the double precision variant >>>>> is >>>>> + * ~ 1e-13 for very small and very large values. >>>>> + * This is ~2x faster than GNU libm's approach, which is still off by >>>>> 2ulp on >>>>> + * some inputs. >>>>> + * @param x exponent >>>>> + * @return 10^x >>>>> + */ >>>>> +static av_always_inline double avpriv_exp10(double x) >>>> >>>> It's an inline function in a header, and internal at that. Just call it >>>> ff_exp10. >>> >>> It is used in avcodec and avfilter. I thought this meant that it >>> should be avpriv? >>> Personally, I like ff_exp10 as it is shorter. >>> >> >> avpriv is a hack for private functions that need to be exported in >> shared libraries, since we have a rule to only export av* functions. > > Makes sense now. > >> inline functions in headers don't need to be exported in a library, so >> no need for avpriv. ff* is fine there, and used for other similar >> situations. > > Guess the patch is ok (once this is changed), and likewise the > configure one. Both of these going in soon. Thanks.
pushed > >> >> - Hendrik >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
