[SciPy-user] Problems testing SciPy 0.3.2

[Pearu Peterson]

On Sat, 16 Oct 2004, Francesc Alted wrote:

> Yes, that works much better. Only 2 errors now:
>
> ======================================================================
> ERROR: check_random (scipy.linalg.basic.test_basic.test_det)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/users/exp/alted/bin-i686//lib/python/scipy/linalg/tests/test_basic.py", line 282, in check_random
>    Numeric_det = LinearAlgebra.determinant
> AttributeError: 'module' object has no attribute 'determinant'

Hmm, don't know why determinant is not defined in your version of 
LinearAlgebra.

> ----------------------------------------------------------------------
> Ran 695 tests in 1.552s
>
> FAILED (errors=2)
> <unittest.TextTestRunner object at 0xb72758cc>
> -----------
>
> Curiously enough, if I change the directory to scipy/Lib/linalg, start the
> python interpreter and run the tests there, everything goes well:
>
> ----------------------------------------------------------------------
> Ran 600 tests in 1.333s
>
> OK
> <unittest.TextTestRunner object at 0xb727e7cc>
> -----------
>
> You can note, however, that only 600 tests were executed there.

It could be because python is picking up modules in the current directory 
that import unexisting extension modules.

Actually, scipy has currently about 970 level=0 tests. Look at the 
beginning of scipy.test() output to see if there are any error messages 
present.

> So, it seems that my ATLAS libraries were bad. Uh, I don't know what I was
> doing wrong, but apparently I repeteated the error twice. That's strange
> because your instructions in INSTALL.txt were clear enough :-/ Perhaps
> something wrong with my software versions?
>
> gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
> LAPACK, Version 3.0 (update) Date: May 31, 2000
> ATLAS 3.6.0
>
>> Also, do the  following commands work?
>>
>> cd Lib/lapack
>> python setup_atlas_version.py build_ext --inplace
>> python -c 'import atlas_version'
>
> Here you are:
>
> [alted at api linalg]$ python -c 'import atlas_version'
> ATLAS version 3.6.0 built by pearu on Sat Apr 10 13:28:37 CDT 2004:
>   UNAME    : Linux xp 2.4.25-1-686 #1 Tue Feb 24 10:55:59 EST 2004 i686 GNU/Linux
>   INSTFLG  :
>   MMDEF    : /home/pearu/src/ATLAS/CONFIG/ARCHS/P4SSE2/gcc/gemm
>   ARCHDEF  : /home/pearu/src/ATLAS/CONFIG/ARCHS/P4SSE2/gcc/misc
>   F2CDEFS  : -DAdd_ -DStringSunStyle
>   CACHEEDGE: 1048576
>   F77      : /usr/bin/g77, version GNU Fortran (GCC) 3.3.3 (Debian 20040401)
>   F77FLAGS : -fomit-frame-pointer -O -fno-second-underscore
>   CC       : /usr/bin/gcc, version gcc (GCC) 3.3.3 (Debian 20040401)
>   CC FLAGS : -fomit-frame-pointer -O3 -funroll-all-loops
>   MCC      : /usr/bin/gcc, version gcc (GCC) 3.3.3 (Debian 20040401)
>   MCCFLAGS : -fomit-frame-pointer -O
>
> Now, with my own generated ATLAS libs:
>
> [alted at api linalg]$ python -c 'import atlas_version'
> ATLAS version 3.6.0 built by alted on vie oct 15 17:02:42 CEST 2004:
>   UNAME    : Linux api.uji.es 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
>   INSTFLG  :
>   MMDEF    : /scratch1/alted/ATLAS/CONFIG/ARCHS/P4SSE2/gcc/gemm
>   ARCHDEF  : /scratch1/alted/ATLAS/CONFIG/ARCHS/P4SSE2/gcc/misc
>   F2CDEFS  : -DAdd__ -DStringSunStyle
>   CACHEEDGE: 1048576
>   F77      : /usr/bin/g77, version GNU Fortran (GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
>   F77FLAGS : -fomit-frame-pointer -O
>   CC       : /usr/bin/gcc, version gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
>   CC FLAGS : -fomit-frame-pointer -O3 -funroll-all-loops
>   MCC      : /usr/bin/gcc, version gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
>   MCCFLAGS : -fomit-frame-pointer -O
>
> At first sigth, I can see a difference: the "-fno-second-underscore" flag
> that you put when compiling, while I didn't put this. Can this account for
> the problems?

I would not expect that not using '-fno-second-underscore' would cause 
problems as blas/lapack libraries do not contain symbols having 
underscores in their names and so the libraries should be identical 
(unless I missed something). But you could try building atlas with 
'-fno-second-underscore' (and check that F2CDEFS contains then -DAdd_, 
not -DAdd__). If the resulting atlas library will be still bad then I'd 
suspect a compiler bug.

Pearu