On Thu, Oct 29, 2015 at 7:36 AM, wm4 <nfx...@googlemail.com> wrote: > On Thu, 29 Oct 2015 07:27:20 -0400 > Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > >> On Thu, Oct 29, 2015 at 5:43 AM, wm4 <nfx...@googlemail.com> wrote: >> > On Thu, 29 Oct 2015 00:19:59 -0400 >> > Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote: >> > >> >> This is more concise and conveys the intent better. >> >> Furthermore, it is likely more precise as well due to lack of floating >> >> point division. >> >> >> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >> >> --- >> > >> > These patches are all pretty similar. And likely tedious to check for >> > correctness. So low gain, while some potential for regressions. >> >> In the time it took you to write that comment, you could have easily >> reviewed a couple. log10 is already being used in the codebase, why >> not make it consistent and also make it more precise? >> >> There is a good reason why libc has a log10 function. >> >> Maybe you don't care about such things, but I do: it is (roughly) >> analogous to using double instead of float for filters/resampling etc >> - noise floor should not be increased unless there is a clear benefit. >> Here there is none from using log as opposed to log10. > > Not going to play this superficially-review-mass-patches-with-little-to- > none-benefit-just-so-a-single-developer-doesn't-get-annoyed-and-then-deal- > with-regression-fallout game. > > You're giving the ML more patches to review than it can deal with it, so > my reaction is to flat out reject such patch-spam for things which seem to > have little benefit and are not 100% trivial.
How? I send fewer patches than many other developers here. > > (This reminds me of mass cosmetics from Libav...) Comparing this with cosmetics is not accurate - these are NOT cosmetics. They affect the bit accuracy of the results. To prove to the likes of wm4 that this is not cosmetic, here are some simple results: computing 10*log10(x) vs 10*log10(x)/log(10.0), top is first, bottom is second expr: x = 1e-12: -120.000000000000000 -119.999999999999986 x = DBL_MIN: -3076.526555685887615 -3076.526555685887161 x = 5*1e32: 326.989700043360187 326.989700043360131 These are differences obtained within the first 15 digits. I am pretty confident that by finding the worst case, one can get even starker differences. > _______________________________________________ > 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
