> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Martin > Storsj? > Sent: Friday, April 24, 2020 6:44 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] dnn-layer-mathbinary-test: Fix tests for > cases with extra intermediate precision > > On Thu, 23 Apr 2020, Guo, Yejun wrote: > > >> -----Original Message----- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > >> Of Martin Storsj? > >> Sent: Thursday, April 23, 2020 2:34 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: [FFmpeg-devel] [PATCH] dnn-layer-mathbinary-test: Fix tests > >> for cases with extra intermediate precision > >> > >> This fixes tests on 32 bit x86 mingw with clang, which uses x87 fpu > >> by default. > >> > >> In this setup, while the get_expected function is declared to return > >> float, the compiler is (especially given the optimization flags set) > >> free to keep the intermediate values (in this case, the return value > >> from the inlined function) in higher precision. > >> > >> This results in the situation where 7.28 (which actually, as a float, > >> ends up as 7.2800002098), multiplied by 100, is > >> 728.000000 when really forced into a 32 bit float, but 728.000021 > >> when kept with higher intermediate precision. > >> > >> For the multiplication case, a more suitable epsilon would e.g. > >> be 2*FLT_EPSILON*fabs(expected_output), > > > > thanks for the fix. LGTM. > > > > Just want to have a talk with 2*FLT_EPSILON*fabs(expected_output), > > any explanation for this? looks ULP (units of least precision) based > > method is a good choice, see https://bitbashing.io/comparing-floats.html. > > Anyway, let's use the hardcoded threshold for simplicity. > > FLT_EPSILON corresponds to 1 ULP when the exponent is zero, i.e. in the range > [1,2] or [-2,-1]. So by doing FLT_EPSILON*fabs(expected_output) you get the > magnitude of 1 ULP for the value expected_output. By allowing a difference of > 2 > ULP it would be a bit more lenient - not sure if that aspect really is > relevant or > not. > > This would work fine for this particular test, as you have two input values > that > should be represented the same in both implementations, and you do one > single operation on them - so the only difference _should_ be how much the > end result is rounded. If testing for likeness on a more complex function that > does a series of operations, you would have to account for a ~1 ULP rounding > error in each of the steps, and calculate how that rounding error could be > magnified by later operations. > > And especially if you have two potentially inexact numbers that are close each > other and perform a subtraction, you'll have loss of significance, and the > error > in that result is way larger than 1 ULP for that particular number.
Thanks a lot Martin, will push now. > > // Martin > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".