test_spline_filter failure on 32-bit

[matthew-brett]

_______________________ TestBSplines.test_spline_filter ________________________

[snip]

>                   raise AssertionError(msg)
E                   AssertionError: 
E                   Not equal to tolerance rtol=1e-07, atol=0
E                   
E                   (mismatch 100.0%)
E                    x: array([[ -4.61489439e-01-1.92994106j,   8.33332348e+00+6.25519848j,
E                             6.96301341e-01-9.05576134j,   5.28294897e+00+3.97541451j,
E                             5.92165613e+00+7.68240595j,   6.59493113e+00-1.04542828j,...
E                    y: array([[ -4.61489230e-01-1.92994022j,   8.33332443e+00+6.25519943j,
E                             6.96300745e-01-9.05576038j,   5.28294849e+00+3.97541356j,
E                             5.92165565e+00+7.68240595j,   6.59493160e+00-1.04542804j,...

https://travis-ci.org/MacPython/scipy-wheels/jobs/409327647

Detected on scipy-wheels build matrix. First failure on this test on 21 July:

https://travis-ci.org/MacPython/scipy-wheels/builds/406631499

Previous test was July 14th, no failure (on this test).

https://travis-ci.org/MacPython/scipy-wheels/builds/403942847

[rgommers]

That's a new test, probably a case of test precision too high.

I cannot reproduce this locally. Can you?

[matthew-brett]

Ralf - do you mean you can't reproduce it on a 32-bit docker image?

Failure appears to be very reproducible on Travis.

[pv]

It's a test tolerance issue. The computations for complex data are actually done in single precision even for double-precision inputs, so the check should use bigger rtol ~ 1e-6. Fix in gh-9208

That the routines use single precision is probably bug, but I'd like to leave that to someone else to fix, so a separate issue is here: gh-9209