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

Submitted by:  Patrick Alken <psa>
Submitted on:  Fri 17 Apr 2015 03:28:16 PM UTC  
 
Category: Accuracy problemSeverity: 3 - Normal
Operating System: Status: None
Assigned to: NoneOpen/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>
Project 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>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1