Hi, On Sat, Dec 26, 2015 at 6:37 AM, Michael Niedermayer <mich...@niedermayer.cc > wrote:
> On Fri, Dec 25, 2015 at 08:10:16PM -0800, Ganesh Ajjanagadde wrote: > > On Fri, Dec 25, 2015 at 9:11 AM, Ganesh Ajjanagadde > > <gajjanaga...@gmail.com> wrote: > > > This tightens the errors by doing a first order Taylor approximation of > > > one obvious source of error. This results in negligible runtime > > > slowdown, but improves worst case relative error by ~ 30%, worst case > > > ulp count from 673 to 391. Another illustration is: > > > arg : -303.137207600000010643270798027515 > > > exp10 : 7.2910890073523505e-304, 2 ulp > > > exp10l: 7.2910890073523489e-304, 0 ulp > > > simple: 7.2910890073526541e-304, 377 ulp > > > corr : 7.2910890073524274e-304, 97 ulp > > > real : 7.2910890073523489e-304, 0 ulp > > > next : 7.2910890073533033e-304, 1178 ulp > > > prev : 7.2910890073513954e-304, 1178 ulp > > > > > > where next, prev denote: > > > exp10l(nextafter(x, INFINITY)) > > > exp10l(nextafter(x, -INFINITY)), > > > and simple the exp2(M_LOG2_10 * x), corr this approach. > > > > > > Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> > > > --- > > > libavutil/internal.h | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/libavutil/internal.h b/libavutil/internal.h > > > index ae11601..b6d72b7 100644 > > > --- a/libavutil/internal.h > > > +++ b/libavutil/internal.h > > > @@ -304,7 +304,9 @@ static av_always_inline av_const int64_t > ff_rint64_clip(double a, int64_t amin, > > > */ > > > static av_always_inline double avpriv_exp10(double x) > > > { > > > - return exp2(M_LOG2_10 * x); > > > + /* log(2)*(log2(10) - (double)log2_10) */ > > > + static const double log2_10_eps = 1.02495895001049072e-16; > > > + return exp2(M_LOG2_10 * x) * (1 + log2_10_eps * x); > > > } > > > > > > static av_always_inline float avpriv_exp10f(float x) > > > -- > > > 2.6.4 > > > > > > > Michael: I don't recall you opposing this, but I also recall that you > > don't believe this is useful. It will make me feel a bit better about > > ff_exp10 if this goes in, so at what level (percentage) of runtime > > slowdown are you willing to accept this? > > i dont know if the speed difference of exp10 really matters for any > speed relevant code (probably not) and i dont know if the accuracy > increase really matters for any code either > so its weighting 2 "dont knows" against each other > i cant really say what is better I share this concern. I'd prefer to keep it simple, so prefer without this patch. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel