bugGNU Scientific Library - Bugs: bug #44865, bsimp/msbdf e5_bigt in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #44865: bsimp/msbdf e5_bigt in ode-initval2/test.c is FMA-sensitive

Submitter:  Patrick Alken <psa>
Submitted:  Fri 17 Apr 2015 03:28:16 PM UTC
   
 
Category:  Accuracy problem Severity:  3 - Normal
Operating System:  Status:  None
Assigned to:  None Open/Closed:  Open
Release: 

Fri 17 Apr 2015 03:28:35 PM UTC, comment #1: 

Also, FWIW, making this change makes the test pass:

diff --git a/ode-initval2/test.c b/ode-initval2/test.c
index f66cb6b..40ec089 100644
--- a/ode-initval2/test.c
+++ b/ode-initval2/test.c
@@ -1942,7 +1942,7 @@ test_extreme_problems (void)
   /* Integration interval for problems */
  
   const double start[CONST_EXTREME_NPROB] = { 0.0 };
-  const double end[CONST_EXTREME_NPROB] = { 1e11, 1e11, 1e-5 };
+  const double end[CONST_EXTREME_NPROB] = { 1e9, 1e11, 1e-5 };
 
   const double epsabs[CONST_EXTREME_NPROB] =
     { 1e1 GSL_DBL_MIN, 1e1 GSL_DBL_MIN, 1e-12 };

Thanks again,
Hal

Patrick Alken <psa>
Group administrator
Fri 17 Apr 2015 03:28:16 PM UTC, original submission:  

Hello,

Please CC me directly on any replies because I'm not subscribed to the bugs list.

When compiling gsl-1.16 using Clang/LLVM trunk for big-endian PPC64/Linux, and using -ffp-contract=fast, make check reports one test failure, which is in ode-initval2, with this error:

FAIL: bsimp/msbdf e5_bigt [0] (3.74930479547497807e-49 observed vs 3.75953510319630164e-49 expected) [1126]
FAIL: bsimp/msbdf e5_bigt [1] (6.24102529027298901e-21 observed vs 8.02997493696624951e-21 expected) [1127]
FAIL: bsimp/msbdf e5_bigt [2] (1.55381668382339737e-20 observed vs 1.27123535645485829e-20 expected) [1128]
FAIL: bsimp/msbdf e5_bigt [3] (5.6710668834932872e-65 observed vs 4.65237109886871277e-65 expected) [1129]

When compiling ode-initval2/test.c using -ffp-contract=on or -ffp-contract=off instead, the test passes. Also, when compiling using -ffp-contract=fast but placing '#pragma clang optimize off'/'#pragma clang optimize on' around only the rhs_e5 function, the test also passes. I've examined the assembly produced for the rhs_e5 (annotated below), and it looks okay. As a result, it seems likely that this is a sensitivity of the test to the extra FMA precision.

Could the test be modified to make it less sensitive to FMA formation?

Thanks again,
Hal

int
rhs_e5 (double t, const double y[], double f[], void *params)
{
  const double a = 7.89e-10;
  const double b = 1.1e7;
  const double c = 1.13e3;
  const double m = 1.0e6;

  extern int nfe;
  nfe += 1;

  f[0] = -a y[0] - b y[0] * y[2];
  f[1] = a y[0] - m c y[1] y[2];
  f[3] = b y[0] y[2] - c * y[3];
  f[2] = f[1] - f[3];

  return GSL_SUCCESS;
}

Patrick Alken <psa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psa (Submitted the item)
  •  

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code