[FFmpeg-devel] [PATCH 1/2] configure+libm.h: add hypot emulation

[Ganesh Ajjanagadde]

On Sat, Nov 14, 2015 at 4:48 PM, Paul B Mahol <onemda at gmail.com> wrote:
> On 11/14/15, Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
>> It is known that the naive sqrt(x*x + y*y) approach for computing the
>> hypotenuse suffers from overflow and accuracy issues, see e.g
>> http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
>> This adds hypot support to FFmpeg, a C99 function.
>>
>> On platforms without hypot, this patch for simplicity does the naive
>> direct computation outlined above. Improvements can be made separately.
>>
>> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>> ---
>>  configure        | 2 ++
>>  libavutil/libm.h | 8 ++++++++
>>  2 files changed, 10 insertions(+)
>>
>> diff --git a/configure b/configure
>> index d518b21..45df724 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1774,6 +1774,7 @@ MATH_FUNCS="
>>      exp2
>>      exp2f
>>      expf
>> +    hypot
>>      isinf
>>      isnan
>>      ldexpf
>> @@ -5309,6 +5310,7 @@ disabled crystalhd || check_lib
>> libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersi
>>
>>  atan2f_args=2
>>  copysign_args=2
>> +hypot_args=2
>>  ldexpf_args=2
>>  powf_args=2
>>
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index 6c17b28..ab5df1b 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -82,6 +82,14 @@ static av_always_inline float cbrtf(float x)
>>  #define exp2f(x) ((float)exp2(x))
>>  #endif /* HAVE_EXP2F */
>>
>> +#if !HAVE_HYPOT
>> +#undef hypot
>> +static av_always_inline av_const double hypot(double x, double y)
>> +{
>> +    return sqrt(x*x + y*y);
>> +}
>> +#endif /* HAVE_HYPOT */
>> +
>>  #if !HAVE_ISINF
>>  static av_always_inline av_const int isinf(float x)
>>  {
>> --
>> 2.6.2
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> nonsense. either do the right thing or don't touch the code.

The "right thing" is also a very ambiguous term here. For instance, if
one defines the "right thing" by a correctly rounded math library that
meets the ISO C spec, essentially all libm's fail on certain inputs
and functions. The best of the lmainstream lot in this respect is the
GNU libm.  Even the GNU libm sometimes fails to achieve the last bits
of precision for some functions, do e.g man j0 and look at the "bugs"
section.

If one defines the "right thing" as a reasonable fallback, there are
different gradations depending on how much accuracy and readability
one wants. For instance, the backup log10 is definitely incorrect
according to the "strict" criteria, recall the whole log episode.
Nevertheless, I and I believe all other devs here call it a reasonable
fallback. I can do an implementation that goes a bit beyond the naive
sqrt. Ultimately, somewhere the line needs to be drawn.