[SciPy-dev] Lapack tests too stringent?

Ravikiran Rajagopal ravi.rajagopal at amd.com
Tue Jan 23 15:37:33 CST 2007


Hi,
  Running scipy.test(10,10) on revision 2591 causes a failure in 
check_syevr_irange (scipy.lib.tests.test_lapack.test_flapack_float):

AssertionError:
Arrays are not almost equal

(mismatch 33.3333333333%)
 x: array([-0.66992444,  0.48769474,  9.18222523], dtype=float32)
 y: array([-0.66992434,  0.48769389,  9.18223045])

The problem with this test is that the double precision version of this test 
passes on my machine but not the single precision version. To eliminate SciPy 
and ATLAS from the chain of causation, I ran the attached program with the 
reference BLAS and the reference LAPACK from netlib. I have similar failures 
on 32-bit and on 64-bit machines, both running up to date Fedora Core 6. With 
LAPACK 3.1.0, here are the eigenvalue results for double precision for the 
array from the test:
  -0.669924337185138
   0.487693886153334
   9.1822304510318
The above agrees with the reference values in the scipy test above. However, 
with single precision, the values are:
  -0.669923424720764
   0.487694501876831
   9.18223190307617
This does not meet the requirement for arrays being almost equal; is this 
because eps is dependent on double precision and is too low for single 
precision?

To confirm that this is indeed an issue with LAPACK, I ran it on old RHEL3 
32-bit machine with gcc/g77 (as opposed to gcc/gfortran on my FC6 machines) 
and with lapack 3.0 (up to date with all patches). In this case too, there is 
a difference between single precision and double precision values:
       Single                Double
  -0.669924139976501    -0.669924337185137
   0.487694054841995     0.487693886153333
   9.18223094940186      9.1822304510318

Do others see similar numbers? The attached program can be compiled using
  gcc -o sytest syevr.c -llapack -lblas -lg2c
where -lg2c is not required if you are using gfortran. To switch between 
single and double precision tests, change the typedef at the top of the file, 
and the first letter of the call on line 66. In my tests, changing the value 
of abstol did not make any difference.

I wonder why I have not encountered this before since the tests have been in 
SciPy for a long time according to the SVN log.

Regards,
Ravi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syevr.c
Type: text/x-csrc
Size: 2621 bytes
Desc: not available
Url : http://projects.scipy.org/pipermail/scipy-dev/attachments/20070123/3523df81/attachment.bin 


More information about the Scipy-dev mailing list