All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Soete <soete.joel@tiscali.be>
To: "Carlos O'Donell" <carlos@systemhalted.org>
Cc: dave <dave@hiauly1.hia.nrc.ca>,
	parisc-linux <parisc-linux@lists.parisc-linux.org>
Subject: [parisc-linux] Next step in glibc test math failures analysis ;-)
Date: Sun, 14 May 2006 12:06:25 +0000	[thread overview]
Message-ID: <44671D41.6010401@tiscali.be> (raw)
In-Reply-To: <119aab440605091805q741bba07i3d50aee4299e6d82@mail.gmail.com>



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

  reply	other threads:[~2006-05-14 12:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <IZ03Y4$9E8A6266AB8A578EB25FE5A0BE2593A0@scarlet.be>
2006-05-10  1:05 ` [parisc-linux] Re: some starting . of glibc test math filaures ;-) Carlos O'Donell
2006-05-14 12:06   ` Joel Soete [this message]
2006-05-14 21:34     ` [parisc-linux] Re: Next step in glibc test math failures analysis ; -) Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44671D41.6010401@tiscali.be \
    --to=soete.joel@tiscali.be \
    --cc=carlos@systemhalted.org \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.