[SciPy-dev] Re: scipy / SGI MIPSpro compiler (part 3)

[Pearu]

On Sun, 25 Aug 2002, Steve M. Robbins wrote:

> ======================================================================
> FAIL: check_asum (test_blas.test_fblas1_simple)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/local/unstable/lib/python2.1/site-packages/scipy/linalg/tests/test_blas.py", line 59, in check_asum
>     assert_almost_equal(f([3,-4,5]),12)
>   File "/usr/local/unstable/lib/python2.1/site-packages/scipy_base/testing.py", line 283, in assert_almost_equal
>     assert round(abs(desired - actual),decimal) == 0, msg
> AssertionError: 
> Items are not equal:
> DESIRED: 12
> ACTUAL: 0.0
> 
> The failure comes from sasum() -- the single precision version.
> The code using dasum() works OK.
> 
> 
> ======================================================================
> FAIL: check_dot (test_blas.test_fblas1_simple)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/local/unstable/lib/python2.1/site-packages/scipy/linalg/tests/test_blas.py", line 66, in check_dot
>     assert_almost_equal(f([3,-4,5],[2,5,1]),-9)
>   File "/usr/local/unstable/lib/python2.1/site-packages/scipy_base/testing.py", line 283, in assert_almost_equal
>     assert round(abs(desired - actual),decimal) == 0, msg
> AssertionError: 
> Items are not equal:
> DESIRED: -9
> ACTUAL: 0.0
> 
> Same pattern: sdot() fails, but ddot() works.
> 
> 
> ======================================================================
> FAIL: check_nrm2 (test_blas.test_fblas1_simple)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/local/unstable/lib/python2.1/site-packages/scipy/linalg/tests/test_blas.py", line 75, in check_nrm2
>     assert_almost_equal(f([3,-4,5]),math.sqrt(50))
>   File "/usr/local/unstable/lib/python2.1/site-packages/scipy_base/testing.py", line 283, in assert_almost_equal
>     assert round(abs(desired - actual),decimal) == 0, msg
> AssertionError: 
> Items are not equal:
> DESIRED: 7.07106781187
> ACTUAL: 3.73560645334e+270
> 
> Same again: snrm2() fails but dnrm2() works.
> 
> 
> I figure there is something systematically wrong with the single
> precision wrappers.  But I don't know what it could be --- some
> of them appear to work: saxpy, sscal, isamax.

The wrong things happen only with functions that is supposed to return C
float or Fortran real.

> I tried a small test case in the style of f2py's tests/f77 for a
> "sasum"-like function (see below).  It works fine.  However, in this
> test case, I just use the default f2py-generated signature file.  It
> turns out to be quite different from the signature for sasum() in
> linalg/fblas.pyf.  For one thing, the f2py-generated files create a C
> wrapper in which "f2py_func" returns void and has an extra "float*"
> parameter (presumably to return the value) while the fblas.pyf version
> returns float.

The difference is that we tried to avoid intermediate Fortran wrappers 
for blas interfaces. As you already found, by default f2py generates these 
wrappers to Fortran functions for maximum portability and compiler 
independence. These wrappers are crucial for Fortran functions returning 
complex or character types but not so crucial for returning integer or 
real  types. But now your case shows that these wrappers are also needed 
for real*4 types. Unless we figure out something else (see below) then I'll 
fix this issue later by letting scipy to generate these auxiliary 
wrappers.

> But I'm way out of my depth now.  Is there some strange linker
> problem with "extern float" functions?

I have succesfully (without any errors except from weave) tested scipy on 
the following platform:

bash$ python -c 'import os,sys;print os.name,sys.platform'
posix irix646
bash$ uname -a
IRIX64 ape 6.5 07201608 IP30
bash$ python -c 'import sys;print sys.version'
2.1.1 (#1, Oct 21 2001, 16:10:39) [C]
bash$ python -c 'import Numeric;print Numeric.__version__'
20.2.1
bash$ cc  -version
MIPSpro Compilers: Version 7.30
bash$ f77 -version
MIPSpro Compilers: Version 7.30
bash$ 

where both LAPACK and BLAS are built by scipy, in the lines of the 
following:

cd scipy
LAPACK_SRC=/path/to/src/lapack BLAS_SRC=/path/to/src/blas \
 python setup.py build

Do you see any difference with your case? Did you build LAPACK/BLAS 
yourself (then how? compiler flags?) or did you let scipy to build them 
as above? Btw, what is the output of

 python scipy_distutils/system_info.py

in your case (with all enviroment variables like LAPACK_SRC, BLAS_SRC,
etc set)? Do you have any system blas/lapack installed?

I am asking this information because it is possible that your Fortran
compiler assumed that Fortran "real" is "real*8" but f2py assumes
"real*4". See if you can find any relevant flags in your compiler manual.

Pearu