hypotl(LDBL_MAX, 0.0L) = inf

hypotl(LDBL_MAX, 0.0L) = inf

[airplanemath]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

Given that hypot(DBL_MAX, 0.0) = DBL_MAX and hypotf(FLT_MAX, 0.0f) =
FLT_MAX, I suspect this is a problem in hypotl.  Am I missing something?

There is a similar difference in cabsl compared to cabs and cabsf, which
probably has a similar cause.

I attached my test case, which I compile with
gcc -Og -O0 test_cabs_hypot.c -o test_cabs_hypot

What should I expect here?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: STC showing behavior of hypotl compared to hypot and hypotf --]
[-- Type: text/x-csrc, Size: 1042 bytes --]

#include <complex.h>
#include <float.h>
#include <math.h>
#include <stdio.h>

int main(void) {
  _Complex long double test_cabsl = LDBL_MAX + 0.0L * _Complex_I;
  long double test_hypotl1 = LDBL_MAX, test_hypotl2 = 0.0L;
  _Complex double test_cabs = DBL_MAX + 0.0L * _Complex_I;
  double test_hypot1 = DBL_MAX, test_hypot2 = 0.0L;
  _Complex float test_cabsf = FLT_MAX + 0.0L * _Complex_I;
  float test_hypotf1 = FLT_MAX, test_hypotf2 = 0.0L;

  printf("cabsl(%Lg%+Lgi) = %Lg\n", creall(test_cabsl), cimagl(test_cabsl), cabsl(test_cabsl));
  printf("hypotl(%Lg, %Lg) = %Lg\n\n", test_hypotl1, test_hypotl2, hypotl(test_hypotl1, test_hypotl2));

  printf("cabs(%lg%+lgi) = %lg\n", creal(test_cabs), cimag(test_cabs), cabs(test_cabs));
  printf("hypot(%lg, %lg) = %lg\n\n", test_hypot1, test_hypot2, hypot(test_hypot1, test_hypot2));

  printf("cabsf(%g%+gi) = %g\n", crealf(test_cabsf), cimagf(test_cabsf), cabsf(test_cabsf));
  printf("hypotf(%g, %g) = %g\n\n", test_hypotf1, test_hypotf2, hypotf(test_hypotf1, test_hypotf2));
  return 0;
}

Re: hypotl(LDBL_MAX, 0.0L) = inf

[Corinna Vinschen]

On Apr 17 10:02, airplanemath via Cygwin wrote:
> Given that hypot(DBL_MAX, 0.0) = DBL_MAX and hypotf(FLT_MAX, 0.0f) =
> FLT_MAX, I suspect this is a problem in hypotl.  Am I missing something?

No.  This is a bug in newlib's hypotl.  Newlib mainly targest embedded
systems and as such wasn't very much interested in long double arithmetic
for a long time.

In contrast to hypot and hypotf, it's not implemented as exact function,
but just as the outside idea sqrtl (x^2 + y^2).  With LDBL_MAX ^ 2 ==
inf as input, sqrtl returns inf.  So what we get here is an intermediate
overflow, that wouldn't occur if the hypotl function would be implemented
in detail.

The problem is, somebody would have to do it.  That is, implementing
a hypotl which works for all supported CPU types.  There are quite a few
long double variations in the wild, unfortunately...

Having said that, there's an easier way out for Cygwin: We just use
the hypotl function from Mingw-w64 for Cygwin as well.

I pushed this patch and uploaded new developer snapshots to
https://cygwin/snapshots/

Please give it a try.


Thanks,
Corinna

Re: hypotl(LDBL_MAX, 0.0L) = inf

[airplanemath]

On Mon, Apr 19 2021, Corinna Vinschen via Cygwin wrote:

> On Apr 17 10:02, airplanemath via Cygwin wrote:
>> Given that hypot(DBL_MAX, 0.0) = DBL_MAX and hypotf(FLT_MAX, 0.0f) =
>> FLT_MAX, I suspect this is a problem in hypotl.  Am I missing
>> something?
>
> No.  This is a bug in newlib's hypotl.  Newlib mainly targest embedded
> systems and as such wasn't very much interested in long double
> arithmetic for a long time.
>
> Having said that, there's an easier way out for Cygwin: We just use
> the hypotl function from Mingw-w64 for Cygwin as well.
>
> I pushed this patch and uploaded new developer snapshots to
> https://cygwin/snapshots/
>
> Please give it a try.

Thank you.  This fixes that problem and a related one for me.
>
>
> Thanks, Corinna