[parisc-linux] Re: some starting . of glibc test math filaures ;-)

[parisc-linux] Re: some starting . of glibc test math filaures ;-)

[Carlos O'Donell]

On 5/9/06, Joel Soete <soete.joel@tiscali.be> wrote:
> > > If somebody still remember why, that could help me a bit.
> >
> > Probably the maxulps data on hppa is out of date. We've fixed one or tw=
o
> > cases from time to time, but there are probably other problems.
> >
> > Pls send a patch to fix this case.
> >
> Obvioulsy ;-)
>

Where is your ChangeLog?!  ;-)

I'm the hppa libc-ports maintainer. If you send me a well formed
ChangeLog and patch I can do the checkin.

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Next step in glibc test math failures analysis ;-)

[Joel Soete]

Hello all,

Next investigation are obviously:
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math/test-float.out
::::::::::::::
testing float (without inline functions)
Failure: Real part of: cacos (inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (-inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + inf i) == NaN - inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN - inf i) == NaN + inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (-inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: cpow (NaN + NaN i, NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: csinh (0.0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set

First thought, the reported failure is very unrelevent: the actual pb is not related to computed value but well because cacos() let 
fpu flag with "Invalid operation" set. So imho this 1st patch:
--- libm-test.inc.Orig 2006-05-12 12:02:10.000000000 +0000
+++ libm-test.inc 2006-05-12 15:39:31.000000000 +0000
@@ -549,14 +549,19 @@
    int part_xfail;
    char str[200];

+  /* report first what computation did */
+  test_exceptions (test_name, exception);
+
    sprintf (str, "Real part of: %s", test_name);
    part_comp = __real__ computed;
    part_exp = __real__ expected;
    part_max_ulp = __real__ max_ulp;
    part_xfail = __real__ xfail;

+  /* Don't check again for exceptions, just pass through the
+     zero/inf sign test.  */
    check_float_internal (str, part_comp, part_exp, part_max_ulp, part_xfail,
-   exception, &real_max_error);
+   exception & IGNORE_ZERO_INF_SIGN, &real_max_error);

    sprintf (str, "Imaginary part of: %s", test_name);
    part_comp = __imag__ computed;
@@ -564,11 +569,8 @@
    part_max_ulp = __imag__ max_ulp;
    part_xfail = __imag__ xfail;

-  /* Don't check again for exceptions, just pass through the
-     zero/inf sign test.  */
    check_float_internal (str, part_comp, part_exp, part_max_ulp, part_xfail,
-   exception & IGNORE_ZERO_INF_SIGN,
-   &imag_max_error);
+   exception & IGNORE_ZERO_INF_SIGN, &imag_max_error);
  }


====<>====

would better report the actual pb like this test:
Failure: cacos (inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set

Would it have a chance to be accepted?

That said, for now I just know that for the first failure only, the pb occure in:
__complex__ float
__cacosf (__complex__ float x)
{
   __complex__ float y;
   __complex__ float res;

   y = __casinf (x);

   __real__ res = (float) M_PI_2 - __real__ y;
   __imag__ res = -__imag__ y;

   return res;
}

when the "_real_ res" is computed.

The test "check_complex ("casin (inf + NaN i) == NaN + inf i plus sign of zero/inf not specified" pass well so the the computation 
would be __real__ res = (double) M_PI_2 - NaN.

And also seems to confirm my very first feeling: this formula is mathematicaly right but may be presents some lakes of numerical 
implementation like is the brotherhood funct:
__complex__ float
__casinf (__complex__ float x)
{
   __complex__ float res;

   if (isnan (__real__ x) || isnan (__imag__ x))
     {
       if (__real__ x == 0.0)
         {
           res = x;
         }
       else if (__isinff (__real__ x) || __isinff (__imag__ x))
         {
           __real__ res = __nanf ("");
           __imag__ res = __copysignf (HUGE_VALF, __imag__ x);
         }
       else
         {
           __real__ res = __nanf ("");
           __imag__ res = __nanf ("");
         }
     }
   else
     {
       __complex__ float y;

       __real__ y = -__imag__ x;
       __imag__ y = __real__ x;

       y = __casinhf (y);

       __real__ res = __imag__ y;
       __imag__ res = -__real__ y;
     }

   return res;
}

So my next question is: is some of you know a similar implementation of cacosf()? or what would be the results of cacosf() for 
various limit figure with nan, 0.0 and infinity?

Thanks in advance,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: Next step in glibc test math failures analysis ; -)

[Carlos O'Donell]

> So my next question is: is some of you know a similar implementation of c=
acosf()?
> or what would be the results of cacosf() for various limit figure with na=
n, 0.0 and infinity?

Is the problem the setting of the V-bit by the operation?

The value of  "cacos (inf + NaN i)" is  "NaN + inf i", the problem is
that after the test the processor has turned on the V bit to indicate
that the operation is invalid.

In 10-9 of the PA 2.0 book there is a complete description of what
should and should
not trigger an "invalid" exception.

Do we have a case of:
1. Any arithmetic operation on a signaling NaN except for conversion
to integer formats.
2. Magnitude subtraction of intinities like (+inf + -inf)
3. Multiplication of 0 and inf
4. The division operations 0/0 and inf/inf
5. Square root if the operand is less than zero
6. Inproper comparison operations
7. Conversion to integer format as in table 10-6.

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux