scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
Hi,

I have compiled ATLAS following
http://www.scipy.org/Installing_SciPy/Linux#head-1c4018a51422706809ee96a4db03ca0669f5f6d1
on Ubuntu hardy gcc-4.3 64bits .

everything look fine but  scipy.test() fails in a quite bad way :
----------------------------------------------------------------------
Ran 1567 tests in 11.328s

FAILED (failures=2, errors=12)

Is it well-known that some tests of scipy 0.7.0.dev4373 fail ?
I can send you the quite long log if needed.

The point is that the user has no real way to know it there is something
wrong in the a ATLAS installation or if the errors are in the testsuite.

When I see for instance "ERROR: Failure: ImportError (cannot import name
flapack)" I must admit that it looks like a wrong installation of ATLAS
but what should I do now ??

ATLAS installation is time consuming and the documentation is really
unclear except this tutorial. As a result, we need a robust testsuite to
be able to know if scipy+ATLAS is correctly installed or not.

Note that however numpy.test() is ruining just fine and that I can use
scipy to do what I have to do.

Xavier
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Robert Kern-2
On Fri, May 16, 2008 at 4:33 PM, Xavier Gnata <[hidden email]> wrote:

> Hi,
>
> I have compiled ATLAS following
> http://www.scipy.org/Installing_SciPy/Linux#head-1c4018a51422706809ee96a4db03ca0669f5f6d1
> on Ubuntu hardy gcc-4.3 64bits .
>
> everything look fine but  scipy.test() fails in a quite bad way :
> ----------------------------------------------------------------------
> Ran 1567 tests in 11.328s
>
> FAILED (failures=2, errors=12)
>
> Is it well-known that some tests of scipy 0.7.0.dev4373 fail ?
> I can send you the quite long log if needed.

Just show us the parts at the end showing the failures.

> The point is that the user has no real way to know it there is something
> wrong in the a ATLAS installation or if the errors are in the testsuite.
>
> When I see for instance "ERROR: Failure: ImportError (cannot import name
> flapack)" I must admit that it looks like a wrong installation of ATLAS
> but what should I do now ??

It might just be a problem with the build of scipy rather than the
ATLAS library itself. Show us scipy's build output.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
Robert Kern wrote:

> On Fri, May 16, 2008 at 4:33 PM, Xavier Gnata <[hidden email]> wrote:
>  
>> Hi,
>>
>> I have compiled ATLAS following
>> http://www.scipy.org/Installing_SciPy/Linux#head-1c4018a51422706809ee96a4db03ca0669f5f6d1
>> on Ubuntu hardy gcc-4.3 64bits .
>>
>> everything look fine but  scipy.test() fails in a quite bad way :
>> ----------------------------------------------------------------------
>> Ran 1567 tests in 11.328s
>>
>> FAILED (failures=2, errors=12)
>>
>> Is it well-known that some tests of scipy 0.7.0.dev4373 fail ?
>> I can send you the quite long log if needed.
>>    
>
> Just show us the parts at the end showing the failures.
>
>  
>> The point is that the user has no real way to know it there is something
>> wrong in the a ATLAS installation or if the errors are in the testsuite.
>>
>> When I see for instance "ERROR: Failure: ImportError (cannot import name
>> flapack)" I must admit that it looks like a wrong installation of ATLAS
>> but what should I do now ??
>>    
>
> It might just be a problem with the build of scipy rather than the
> ATLAS library itself. Show us scipy's build output.
>
>  

Here it is. Ok it is long but I cannot cut it without removing an
interesting part :

/usr/lib/python2.5/site-packages/scipy/linsolve/__init__.py:4:
DeprecationWarning: scipy.linsolve has moved to scipy.sparse.linalg.dsolve
  warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve',
DeprecationWarning)
/usr/lib/python2.5/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:20:
DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be removed,
install scikits.umfpack instead
  ' install scikits.umfpack instead', DeprecationWarning )
/usr/lib/python2.5/site-packages/scipy/splinalg/__init__.py:3:
DeprecationWarning: scipy.splinalg has moved to scipy.sparse.linalg
  warn('scipy.splinalg has moved to scipy.sparse.linalg',
DeprecationWarning)
E..........................................E.............E...............................
Don't worry about a warning regarding the number of bytes read.
Warning: 1000000 bytes requested, 20 bytes read.
./usr/lib/python2.5/site-packages/numpy/lib/utils.py:114:
DeprecationWarning: write_array is deprecated
  warnings.warn(str1, DeprecationWarning)
/usr/lib/python2.5/site-packages/numpy/lib/utils.py:114:
DeprecationWarning: read_array is deprecated
  warnings.warn(str1, DeprecationWarning)
..E................../usr/lib/python2.5/site-packages/numpy/lib/utils.py:114:
DeprecationWarning: npfile is deprecated
  warnings.warn(str1, DeprecationWarning)
............................caxpy:n=4
..caxpy:n=3
....ccopy:n=4
..ccopy:n=3
.............cscal:n=4
....cswap:n=4
..cswap:n=3
.....daxpy:n=4
..daxpy:n=3
....dcopy:n=4
..dcopy:n=3
.............dscal:n=4
....dswap:n=4
..dswap:n=3
.....saxpy:n=4
..saxpy:n=3
....scopy:n=4
..scopy:n=3
.............sscal:n=4
....sswap:n=4
..sswap:n=3
.....zaxpy:n=4
..zaxpy:n=3
....zcopy:n=4
..zcopy:n=3
.............zscal:n=4
....zswap:n=4
..zswap:n=3
..EEE............................................................................................................................................................................................................................................................................................................................................................................................................/usr/lib/python2.5/site-packages/scipy/ndimage/_segmenter.py:30:
UserWarning: The segmentation code is under heavy development and
therefore the public API will change in the future.  The NIPY group is
actively working on this code, and has every intention of generalizing
this for the Scipy community.  Use this module minimally, if at all,
until it this warning is removed.
  warnings.warn(_msg, UserWarning)
...F....................................E...........E....
 _naupd: Number of update iterations taken
 -----------------------------------------
    1 -    1:    11


 _naupd: Number of wanted "converged" Ritz values
 ------------------------------------------------
    1 -    1:     4


 _naupd: Real part of the final Ritz values
 ------------------------------------------
    1 -    4:   1.033D+00   7.746D-01   5.164D-01   2.582D-01


 _naupd: Imaginary part of the final Ritz values
 -----------------------------------------------
    1 -    4:   0.000D+00   0.000D+00   0.000D+00   0.000D+00


 _naupd: Associated Ritz estimates
 ---------------------------------
    1 -    4:   2.700D-15   6.598D-19   1.478D-22   4.431D-26



     =============================================
     = Nonsymmetric implicit Arnoldi update code =
     = Version Number:  2.4                      =
     = Version Date:    07/31/96                 =
     =============================================
     = Summary of timing statistics              =
     =============================================


     Total number update iterations             =    11
     Total number of OP*x operations            =    52
     Total number of B*x operations             =     0
     Total number of reorthogonalization steps  =    51
     Total number of iterative refinement steps =     0
     Total number of restart steps              =     0
     Total time in user OP*x operation          =     0.004001
     Total time in user B*x operation           =     0.000000
     Total time in Arnoldi update routine       =     0.004001
     Total time in naup2 routine                =     0.004001
     Total time in basic Arnoldi iteration loop =     0.004001
     Total time in reorthogonalization phase    =     0.000000
     Total time in (re)start vector generation  =     0.000000
     Total time in Hessenberg eig. subproblem   =     0.000000
     Total time in getting the shifts           =     0.000000
     Total time in applying the shifts          =     0.000000
     Total time in convergence testing          =     0.000000
     Total time in computing final Ritz vectors =     0.000000

.EE........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................F...........................................................................................................................................................E...warning:
specified build_dir '_bad_path_' does not exist or is not writable.
Trying default locations
...warning: specified build_dir '..' does not exist or is not writable.
Trying default locations
..warning: specified build_dir '_bad_path_' does not exist or is not
writable. Trying default locations
...warning: specified build_dir '..' does not exist or is not writable.
Trying default locations
............................building extensions here:
/home/gnata/.python25_compiled/m12
................................................................................................
======================================================================
ERROR: Failure: ImportError
(/usr/lib/python2.5/site-packages/scipy/linalg/clapack.so: undefined
symbol: clapack_sgesv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/cluster/__init__.py",
line 9, in <module>
    import vq, hierarchy
  File "/usr/lib/python2.5/site-packages/scipy/cluster/hierarchy.py",
line 178, in <module>
    import _hierarchy_wrap, scipy, types, math, sys, scipy.stats
  File "/usr/lib/python2.5/site-packages/scipy/stats/__init__.py", line
7, in <module>
    from stats import *
  File "/usr/lib/python2.5/site-packages/scipy/stats/stats.py", line
192, in <module>
    import scipy.linalg as linalg
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
18, in <module>
    from scipy.linalg import clapack
ImportError: /usr/lib/python2.5/site-packages/scipy/linalg/clapack.so:
undefined symbol: clapack_sgesv

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File
"/usr/lib/python2.5/site-packages/scipy/integrate/tests/test_integrate.py",
line 9, in <module>
    from scipy.linalg import norm
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/interpolate/__init__.py",
line 7, in <module>
    from interpolate import *
  File
"/usr/lib/python2.5/site-packages/scipy/interpolate/interpolate.py",
line 13, in <module>
    import scipy.linalg as slin
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: test_integer (test_array_import.TestReadArray)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.5/site-packages/scipy/io/tests/test_array_import.py",
line 51, in test_integer
    from scipy import stats
  File "/usr/lib/python2.5/site-packages/scipy/stats/__init__.py", line
7, in <module>
    from stats import *
  File "/usr/lib/python2.5/site-packages/scipy/stats/stats.py", line
192, in <module>
    import scipy.linalg as linalg
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError
(/usr/lib/python2.5/site-packages/scipy/lib/lapack/clapack.so: undefined
symbol: clapack_sgesv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/lib/lapack/__init__.py",
line 16, in <module>
    import clapack
ImportError:
/usr/lib/python2.5/site-packages/scipy/lib/lapack/clapack.so: undefined
symbol: clapack_sgesv

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/maxentropy/__init__.py",
line 9, in <module>
    from maxentropy import *
  File
"/usr/lib/python2.5/site-packages/scipy/maxentropy/maxentropy.py", line
75, in <module>
    from scipy.linalg import norm
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/signal/__init__.py", line
11, in <module>
    from ltisys import *
  File "/usr/lib/python2.5/site-packages/scipy/signal/ltisys.py", line
9, in <module>
    import scipy.interpolate as interpolate
  File "/usr/lib/python2.5/site-packages/scipy/interpolate/__init__.py",
line 7, in <module>
    from interpolate import *
  File
"/usr/lib/python2.5/site-packages/scipy/interpolate/interpolate.py",
line 13, in <module>
    import scipy.linalg as slin
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File
"/usr/lib/python2.5/site-packages/scipy/sparse/linalg/dsolve/tests/test_linsolve.py",
line 6, in <module>
    from scipy.linalg import norm, inv
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File
"/usr/lib/python2.5/site-packages/scipy/sparse/linalg/eigen/lobpcg/tests/test_lobpcg.py",
line 8, in <module>
    from scipy import array, arange, ones, sort, cos, pi, rand, \
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File
"/usr/lib/python2.5/site-packages/scipy/sparse/linalg/isolve/tests/test_iterative.py",
line 9, in <module>
    from scipy.linalg import norm
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
ERROR: Failure: ImportError (cannot import name flapack)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose/loader.py", line 364, in
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 39, in
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.5/site-packages/nose/importer.py", line 84, in
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python2.5/site-packages/scipy/stats/__init__.py", line
7, in <module>
    from stats import *
  File "/usr/lib/python2.5/site-packages/scipy/stats/stats.py", line
192, in <module>
    import scipy.linalg as linalg
  File "/usr/lib/python2.5/site-packages/scipy/linalg/__init__.py", line
8, in <module>
    from basic import *
  File "/usr/lib/python2.5/site-packages/scipy/linalg/basic.py", line
17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib/python2.5/site-packages/scipy/linalg/lapack.py", line
17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

======================================================================
FAIL: test_texture2 (test_segment.TestSegment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.5/site-packages/scipy/ndimage/tests/test_segment.py",
line 152, in test_texture2
    assert_array_almost_equal(tem0, truth_tem0, decimal=6)
  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
255, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
240, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not almost equal

(mismatch 66.6666666667%)
 x: array([  0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
         0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
         1.91816598e-01,   1.02515288e-01,   9.30087343e-02,...
 y: array([ 0.        ,  0.        ,  0.        ,  0.        ,  0.        ,
        0.        ,  0.13306101,  0.08511007,  0.05084148,  0.07550675,
        0.4334695 ,  0.03715914,  0.00289055,  0.02755581,  0.48142046,
        0.03137803,  0.00671277,  0.51568902,  0.01795249,  0.49102375,  
1.        ], dtype=float32)

======================================================================
FAIL: test_pbdv (test_basic.TestCephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.5/site-packages/scipy/special/tests/test_basic.py",
line 368, in test_pbdv
    assert_equal(cephes.pbdv(1,0),(0.0,0.0))
  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
139, in assert_equal
    assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg),
verbose)
  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
145, in assert_equal
    assert desired == actual, msg
AssertionError:
Items are not equal:
item=1

 ACTUAL: 1.0
 DESIRED: 0.0

----------------------------------------------------------------------
Ran 1567 tests in 13.438s

FAILED (failures=2, errors=12)




python setup.py build output :


mkl_info:
  libraries mkl,vml,guide not found in /usr/lib
  libraries mkl,vml,guide not found in /usr/local/lib/scipy/lib
  NOT AVAILABLE

fftw3_info:
  FOUND:
    libraries = ['fftw3']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_FFTW3_H', None)]
    include_dirs = ['/usr/include']

djbfft_info:
  NOT AVAILABLE

blas_opt_info:
blas_mkl_info:
  libraries mkl,vml,guide not found in /usr/lib
  libraries mkl,vml,guide not found in /usr/local/lib/scipy/lib
  NOT AVAILABLE

atlas_blas_threads_info:
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
  FOUND:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/lib']
    language = c
    include_dirs = ['/usr/include']

customize GnuFCompiler
Could not locate executable g77
Could not locate executable f77
customize IntelFCompiler
Could not locate executable ifort
Could not locate executable ifc
customize LaheyFCompiler
Could not locate executable lf95
customize PGroupFCompiler
Could not locate executable pgf90
Could not locate executable pgf77
customize AbsoftFCompiler
Could not locate executable f90
customize NAGFCompiler
Found executable /usr/bin/f95
customize VastFCompiler
customize GnuFCompiler
customize CompaqFCompiler
Could not locate executable fort
customize IntelItaniumFCompiler
Could not locate executable efort
Could not locate executable efc
customize IntelEM64TFCompiler
customize Gnu95FCompiler
Found executable /usr/bin/gfortran
customize Gnu95FCompiler
customize Gnu95FCompiler using config
compiling '_configtest.c':

/* This file is generated from numpy/distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
  ATL_buildinfo();
  return 0;
}
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -fPIC

compile options: '-c'
gcc: _configtest.c
gcc -pthread _configtest.o -llapack -lf77blas -lcblas -latlas -o _configtest
ATLAS version 3.8.1 built by root on Tue May 13 00:29:20 CEST 2008:
   UNAME    : Linux dupilon 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45
UTC 2008 x86_64 GNU/Linux
   INSTFLG  : -1 0 -a 1
   ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_Core2Duo -DATL_CPUMHZ=2201
-DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664
   F2CDEFS  : -DAdd_ -DF77_INTEGER=int -DStringSunStyle
   CACHEEDGE: 2097152
   F77      : gfortran, version GNU Fortran (Ubuntu 4.3.0-1ubuntu1) 4.3.0
   F77FLAGS : -O -fPIC -m64
   SMC      : gcc, version gcc (Ubuntu 4.3.0-1ubuntu1) 4.3.0
   SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC
   SKC      : gcc, version gcc (Ubuntu 4.3.0-1ubuntu1) 4.3.0
   SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC
success!
removing: _configtest.c _configtest.o _configtest
  FOUND:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/lib']
    language = c
    define_macros = [('ATLAS_INFO', '"\\"3.8.1\\""')]
    include_dirs = ['/usr/include']

ATLAS version 3.8.1
lapack_opt_info:
lapack_mkl_info:
  NOT AVAILABLE

atlas_threads_info:
Setting PTATLAS=ATLAS
  libraries lapack_atlas not found in /usr/lib
numpy.distutils.system_info.atlas_threads_info
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
  FOUND:
    libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/lib']
    language = f77
    include_dirs = ['/usr/include']

customize GnuFCompiler
customize IntelFCompiler
customize LaheyFCompiler
customize PGroupFCompiler
customize AbsoftFCompiler
customize NAGFCompiler
customize VastFCompiler
customize GnuFCompiler
customize CompaqFCompiler
customize IntelItaniumFCompiler
customize IntelEM64TFCompiler
customize Gnu95FCompiler
customize Gnu95FCompiler
customize Gnu95FCompiler using config
compiling '_configtest.c':

/* This file is generated from numpy/distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
  ATL_buildinfo();
  return 0;
}
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -fPIC

compile options: '-c'
gcc: _configtest.c
gcc -pthread _configtest.o -llapack -llapack -lf77blas -lcblas -latlas
-o _configtest
ATLAS version 3.8.1 built by root on Tue May 13 00:29:20 CEST 2008:
   UNAME    : Linux dupilon 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45
UTC 2008 x86_64 GNU/Linux
   INSTFLG  : -1 0 -a 1
   ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_Core2Duo -DATL_CPUMHZ=2201
-DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664
   F2CDEFS  : -DAdd_ -DF77_INTEGER=int -DStringSunStyle
   CACHEEDGE: 2097152
   F77      : gfortran, version GNU Fortran (Ubuntu 4.3.0-1ubuntu1) 4.3.0
   F77FLAGS : -O -fPIC -m64
   SMC      : gcc, version gcc (Ubuntu 4.3.0-1ubuntu1) 4.3.0
   SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC
   SKC      : gcc, version gcc (Ubuntu 4.3.0-1ubuntu1) 4.3.0
   SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC
success!
removing: _configtest.c _configtest.o _configtest
  FOUND:
    libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/lib']
    language = f77
    define_macros = [('ATLAS_INFO', '"\\"3.8.1\\""')]
    include_dirs = ['/usr/include']

ATLAS version 3.8.1
ATLAS version 3.8.1
umfpack_info:
amd_info:
  FOUND:
    libraries = ['amd']
    library_dirs = ['/usr/lib']
    swig_opts = ['-I/usr/include']
    define_macros = [('SCIPY_AMD_H', None)]
    include_dirs = ['/usr/include']

  FOUND:
    libraries = ['umfpack', 'gfortran', 'amd']
    library_dirs = ['/usr/lib']
    swig_opts = ['-I/usr/include', '-I/usr/include']
    define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]
    include_dirs = ['/usr/include']





_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Robert Kern-2
On Fri, May 16, 2008 at 4:58 PM, Xavier Gnata <[hidden email]> wrote:

> Here it is. Ok it is long but I cannot cut it without removing an
> interesting part :

Well, the parts interesting to me are the ones starting here:

> ======================================================================
> ERROR: Failure: ImportError
> (/usr/lib/python2.5/site-packages/scipy/linalg/clapack.so: undefined
> symbol: clapack_sgesv)
> ----------------------------------------------------------------------

This looks like an ATLAS build problem. Specifically, it looks like
you didn't make a full LAPACK for ATLAS. I'm not current on the build
process for recent ATLASes. I *think* that if you pass the correct
--with-netlib-lapack to ./configure, it will correctly merge a full
LAPACK. But it might not. Instructions for doing this manually are
here:

  http://svn.scipy.org/svn/scipy/trunk/INSTALL.txt

This does not involve recompiling ATLAS.

But you can probably save yourself a lot of trouble by just installing
the atlas3-base (and possibly atlas3-sse or atlas3-sse2 if you have
those capabilities) and their corresponding -dev packages. It's an old
version, but provides a reasonable speedup for the effort expended.

> ======================================================================
> FAIL: test_texture2 (test_segment.TestSegment)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/usr/lib/python2.5/site-packages/scipy/ndimage/tests/test_segment.py",
> line 152, in test_texture2
>    assert_array_almost_equal(tem0, truth_tem0, decimal=6)
>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
> 255, in assert_array_almost_equal
>    header='Arrays are not almost equal')
>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
> 240, in assert_array_compare
>    assert cond, msg
> AssertionError:
> Arrays are not almost equal
>
> (mismatch 66.6666666667%)
>  x: array([  0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
>         0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
>         1.91816598e-01,   1.02515288e-01,   9.30087343e-02,...
>  y: array([ 0.        ,  0.        ,  0.        ,  0.        ,  0.        ,
>        0.        ,  0.13306101,  0.08511007,  0.05084148,  0.07550675,
>        0.4334695 ,  0.03715914,  0.00289055,  0.02755581,  0.48142046,
>        0.03137803,  0.00671277,  0.51568902,  0.01795249,  0.49102375,
> 1.        ], dtype=float32)

This might be an actual bug in the (heavily in-development) image
segmentation code.

> ======================================================================
> FAIL: test_pbdv (test_basic.TestCephes)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/usr/lib/python2.5/site-packages/scipy/special/tests/test_basic.py",
> line 368, in test_pbdv
>    assert_equal(cephes.pbdv(1,0),(0.0,0.0))
>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
> 139, in assert_equal
>    assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg),
> verbose)
>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
> 145, in assert_equal
>    assert desired == actual, msg
> AssertionError:
> Items are not equal:
> item=1
>
>  ACTUAL: 1.0
>  DESIRED: 0.0

Not sure about this one. Probably a real bug.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
Robert Kern wrote:

> On Fri, May 16, 2008 at 4:58 PM, Xavier Gnata <[hidden email]> wrote:
>
>  
>> Here it is. Ok it is long but I cannot cut it without removing an
>> interesting part :
>>    
>
> Well, the parts interesting to me are the ones starting here:
>
>  
>> ======================================================================
>> ERROR: Failure: ImportError
>> (/usr/lib/python2.5/site-packages/scipy/linalg/clapack.so: undefined
>> symbol: clapack_sgesv)
>> ----------------------------------------------------------------------
>>    
>
> This looks like an ATLAS build problem. Specifically, it looks like
> you didn't make a full LAPACK for ATLAS. I'm not current on the build
> process for recent ATLASes. I *think* that if you pass the correct
> --with-netlib-lapack to ./configure, it will correctly merge a full
> LAPACK. But it might not. Instructions for doing this manually are
> here:
>
>   http://svn.scipy.org/svn/scipy/trunk/INSTALL.txt
>
> This does not involve recompiling ATLAS.
>
> But you can probably save yourself a lot of trouble by just installing
> the atlas3-base (and possibly atlas3-sse or atlas3-sse2 if you have
> those capabilities) and their corresponding -dev packages. It's an old
> version, but provides a reasonable speedup for the effort expended.
>
>  
>> ======================================================================
>> FAIL: test_texture2 (test_segment.TestSegment)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>  File
>> "/usr/lib/python2.5/site-packages/scipy/ndimage/tests/test_segment.py",
>> line 152, in test_texture2
>>    assert_array_almost_equal(tem0, truth_tem0, decimal=6)
>>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
>> 255, in assert_array_almost_equal
>>    header='Arrays are not almost equal')
>>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
>> 240, in assert_array_compare
>>    assert cond, msg
>> AssertionError:
>> Arrays are not almost equal
>>
>> (mismatch 66.6666666667%)
>>  x: array([  0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
>>         0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
>>         1.91816598e-01,   1.02515288e-01,   9.30087343e-02,...
>>  y: array([ 0.        ,  0.        ,  0.        ,  0.        ,  0.        ,
>>        0.        ,  0.13306101,  0.08511007,  0.05084148,  0.07550675,
>>        0.4334695 ,  0.03715914,  0.00289055,  0.02755581,  0.48142046,
>>        0.03137803,  0.00671277,  0.51568902,  0.01795249,  0.49102375,
>> 1.        ], dtype=float32)
>>    
>
> This might be an actual bug in the (heavily in-development) image
> segmentation code.
>
>  
>> ======================================================================
>> FAIL: test_pbdv (test_basic.TestCephes)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>  File
>> "/usr/lib/python2.5/site-packages/scipy/special/tests/test_basic.py",
>> line 368, in test_pbdv
>>    assert_equal(cephes.pbdv(1,0),(0.0,0.0))
>>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
>> 139, in assert_equal
>>    assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg),
>> verbose)
>>  File "/usr/lib/python2.5/site-packages/numpy/testing/utils.py", line
>> 145, in assert_equal
>>    assert desired == actual, msg
>> AssertionError:
>> Items are not equal:
>> item=1
>>
>>  ACTUAL: 1.0
>>  DESIRED: 0.0
>>    
>
> Not sure about this one. Probably a real bug.
>
>  
Thanks for our support :)
I used to use the atlas unbutu package but I would like to understand
how to compile ATLAS and to see if there is a real performance
improvement or not. As you said,it should note be that large...

I have merge the lib using ar as explain in your link.
Now I get this :
FAILED (failures=5, errors=5)

****************************************************************
WARNING: clapack module is empty
-----------
See scipy/INSTALL.txt for troubleshooting.
Notes:
* If atlas library is not found by numpy/distutils/system_info.py,
  then scipy uses flapack instead of clapack.
****************************************************************

...........................FF.............NO ATLAS INFO AVAILABLE
.........................................
****************************************************************
WARNING: cblas module is empty

 It looks there still something wrong isn't it?

xavier

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

cdavid
Xavier Gnata wrote:
>> Not sure about this one. Probably a real bug.

This error is often seen when mixing g77/gfortran. hardy still uses g77
as the default fortran compiler, so it is easy to make a mistake there.

> Thanks for our support :)
> I used to use the atlas unbutu package but I would like to understand
> how to compile ATLAS and to see if there is a real performance
> improvement or not. As you said,it should note be that large...

It is large if you are using a recent core 2 duo: the atlas package
(sse2) are built for pentium4 which has a deficient L1 cache, whereas
core 2 duo has much better behaviour. For large matrices, this can be
significant.

How did you build lapack ? From lapack 3.1.1, you only need to use this
as the make.inc:

####################################################################
#  LAPACK make include file.                                       #
#  LAPACK, Version 3.1.1                                           #
#  February 2007                                                   #
####################################################################
#
SHELL = /bin/sh
#
#  The machine (platform) identifier to append to the library names
#
PLAT = _LINUX
#
#  Modify the FORTRAN and OPTS definitions to refer to the
#  compiler and desired compiler options for your machine.  NOOPT
#  refers to the compiler options desired when NO OPTIMIZATION is
#  selected.  Define LOADER and LOADOPTS to refer to the loader and
#  desired load options for your machine.
#
FORTRAN  = gfortran
OPTS     = -O2 -fPIC
DRVOPTS  = $(OPTS)
NOOPT    = -O0 -fPIC
LOADER   = gfortran
LOADOPTS =
#
# Timer for the SECOND and DSECND routines
#
# Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME
#TIMER    = EXT_ETIME
# For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION
ETIME_
# TIMER    = EXT_ETIME_
# For gfortran compiler: SECOND and DSECND will use a call to the
INTERNAL FUNCTION ETIME
TIMER    = INT_ETIME
# If your Fortran compiler does not provide etime (like Nag Fortran
Compiler, etc...)
# SECOND and DSECND will use a call to the INTERNAL FUNCTION CPU_TIME
# TIMER    = INT_CPU_TIME
# If neither of this works...you can use the NONE value... In that case,
SECOND and DSECND will always return 0
# TIMER     = NONE
#
#  The archiver and the flag(s) to use when building archive (library)
#  If you system has no ranlib, set RANLIB = echo.
#
ARCH     = ar
ARCHFLAGS= cr
RANLIB   = ranlib

LAPACKLIB = liblapack_pic.

And then, to build atlas:

./configure -C if gfortran -Fa alg -fPIC
--with-netlib-lapack=PATH_TO_LAPACK/liblapack_pic.a

But really, you have to think about the pain to build and make sure it
works with the time you gain by having a faster atlas. I bet that for
the time you need to make it work, you could have inverted millions of
big matrices :)

cheers,

David
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
David Cournapeau wrote:

> Xavier Gnata wrote:
>  
>>> Not sure about this one. Probably a real bug.
>>>      
>
> This error is often seen when mixing g77/gfortran. hardy still uses g77
> as the default fortran compiler, so it is easy to make a mistake there.
>
>  
>> Thanks for our support :)
>> I used to use the atlas unbutu package but I would like to understand
>> how to compile ATLAS and to see if there is a real performance
>> improvement or not. As you said,it should note be that large...
>>    
>
> It is large if you are using a recent core 2 duo: the atlas package
> (sse2) are built for pentium4 which has a deficient L1 cache, whereas
> core 2 duo has much better behaviour. For large matrices, this can be
> significant.
>
> How did you build lapack ? From lapack 3.1.1, you only need to use this
> as the make.inc:
>
> ####################################################################
> #  LAPACK make include file.                                       #
> #  LAPACK, Version 3.1.1                                           #
> #  February 2007                                                   #
> ####################################################################
> #
> SHELL = /bin/sh
> #
> #  The machine (platform) identifier to append to the library names
> #
> PLAT = _LINUX
> #
> #  Modify the FORTRAN and OPTS definitions to refer to the
> #  compiler and desired compiler options for your machine.  NOOPT
> #  refers to the compiler options desired when NO OPTIMIZATION is
> #  selected.  Define LOADER and LOADOPTS to refer to the loader and
> #  desired load options for your machine.
> #
> FORTRAN  = gfortran
> OPTS     = -O2 -fPIC
> DRVOPTS  = $(OPTS)
> NOOPT    = -O0 -fPIC
> LOADER   = gfortran
> LOADOPTS =
> #
> # Timer for the SECOND and DSECND routines
> #
> # Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME
> #TIMER    = EXT_ETIME
> # For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION
> ETIME_
> # TIMER    = EXT_ETIME_
> # For gfortran compiler: SECOND and DSECND will use a call to the
> INTERNAL FUNCTION ETIME
> TIMER    = INT_ETIME
> # If your Fortran compiler does not provide etime (like Nag Fortran
> Compiler, etc...)
> # SECOND and DSECND will use a call to the INTERNAL FUNCTION CPU_TIME
> # TIMER    = INT_CPU_TIME
> # If neither of this works...you can use the NONE value... In that case,
> SECOND and DSECND will always return 0
> # TIMER     = NONE
> #
> #  The archiver and the flag(s) to use when building archive (library)
> #  If you system has no ranlib, set RANLIB = echo.
> #
> ARCH     = ar
> ARCHFLAGS= cr
> RANLIB   = ranlib
>
> LAPACKLIB = liblapack_pic.
>
> And then, to build atlas:
>
> ./configure -C if gfortran -Fa alg -fPIC
> --with-netlib-lapack=PATH_TO_LAPACK/liblapack_pic.a
>
> But really, you have to think about the pain to build and make sure it
> works with the time you gain by having a faster atlas. I bet that for
> the time you need to make it work, you could have inverted millions of
> big matrices :)
>
> cheers,
>
> David
> _______________________________________________
>  

Ok I give up and I use the ubuntu packages.
I hope that the documentation project will provide us with a nice "how
to install scipy without errors".
btw, this odcumentation project is the best news of the day ;)

Xavier
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Johann Cohen-Tanugi-2
well, I am not sure the doc marathon will deal with building scipy, at
least as a priority.... This is going to remain a very tough issue
because scipy depends on packages that are complex and hard to build.
Note that if you dont need smart lin. algebra you still have plenty of
good stuff in scipy despite this lapack failure. Maybe what would be
nice is for the scipy build process to clearly disable some specific
libs if something goes wrong and report it at the end of the build. Then
when testing likewise it would disable the corresponding test
functions.... yes this is complete vaporware I know....

Now on the specific problem you have, I don't completely recall now but
when I was struggling with compiling lapack one of the woes I was facing
was a mismatch of fortran compilers, so can you make sure in the python
setup.py config that you are using gfortran all the way through, and not
g77 in any step of the builds of either lapack/blas/scipy?
well my 2 cents,
HTH,
Johann


Xavier Gnata wrote:

> David Cournapeau wrote:
>  
>> Xavier Gnata wrote:
>>  
>>    
>>>> Not sure about this one. Probably a real bug.
>>>>      
>>>>        
>> This error is often seen when mixing g77/gfortran. hardy still uses g77
>> as the default fortran compiler, so it is easy to make a mistake there.
>>
>>  
>>    
>>> Thanks for our support :)
>>> I used to use the atlas unbutu package but I would like to understand
>>> how to compile ATLAS and to see if there is a real performance
>>> improvement or not. As you said,it should note be that large...
>>>    
>>>      
>> It is large if you are using a recent core 2 duo: the atlas package
>> (sse2) are built for pentium4 which has a deficient L1 cache, whereas
>> core 2 duo has much better behaviour. For large matrices, this can be
>> significant.
>>
>> How did you build lapack ? From lapack 3.1.1, you only need to use this
>> as the make.inc:
>>
>> ####################################################################
>> #  LAPACK make include file.                                       #
>> #  LAPACK, Version 3.1.1                                           #
>> #  February 2007                                                   #
>> ####################################################################
>> #
>> SHELL = /bin/sh
>> #
>> #  The machine (platform) identifier to append to the library names
>> #
>> PLAT = _LINUX
>> #
>> #  Modify the FORTRAN and OPTS definitions to refer to the
>> #  compiler and desired compiler options for your machine.  NOOPT
>> #  refers to the compiler options desired when NO OPTIMIZATION is
>> #  selected.  Define LOADER and LOADOPTS to refer to the loader and
>> #  desired load options for your machine.
>> #
>> FORTRAN  = gfortran
>> OPTS     = -O2 -fPIC
>> DRVOPTS  = $(OPTS)
>> NOOPT    = -O0 -fPIC
>> LOADER   = gfortran
>> LOADOPTS =
>> #
>> # Timer for the SECOND and DSECND routines
>> #
>> # Default : SECOND and DSECND will use a call to the EXTERNAL FUNCTION ETIME
>> #TIMER    = EXT_ETIME
>> # For RS6K : SECOND and DSECND will use a call to the EXTERNAL FUNCTION
>> ETIME_
>> # TIMER    = EXT_ETIME_
>> # For gfortran compiler: SECOND and DSECND will use a call to the
>> INTERNAL FUNCTION ETIME
>> TIMER    = INT_ETIME
>> # If your Fortran compiler does not provide etime (like Nag Fortran
>> Compiler, etc...)
>> # SECOND and DSECND will use a call to the INTERNAL FUNCTION CPU_TIME
>> # TIMER    = INT_CPU_TIME
>> # If neither of this works...you can use the NONE value... In that case,
>> SECOND and DSECND will always return 0
>> # TIMER     = NONE
>> #
>> #  The archiver and the flag(s) to use when building archive (library)
>> #  If you system has no ranlib, set RANLIB = echo.
>> #
>> ARCH     = ar
>> ARCHFLAGS= cr
>> RANLIB   = ranlib
>>
>> LAPACKLIB = liblapack_pic.
>>
>> And then, to build atlas:
>>
>> ./configure -C if gfortran -Fa alg -fPIC
>> --with-netlib-lapack=PATH_TO_LAPACK/liblapack_pic.a
>>
>> But really, you have to think about the pain to build and make sure it
>> works with the time you gain by having a faster atlas. I bet that for
>> the time you need to make it work, you could have inverted millions of
>> big matrices :)
>>
>> cheers,
>>
>> David
>> _______________________________________________
>>  
>>    
>
> Ok I give up and I use the ubuntu packages.
> I hope that the documentation project will provide us with a nice "how
> to install scipy without errors".
> btw, this odcumentation project is the best news of the day ;)
>
> Xavier
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

cdavid
Johann Cohen-Tanugi wrote:
> well, I am not sure the doc marathon will deal with building scipy, at
> least as a priority....

Yes, I agree. I think too many people try to build all the dependencies
by themselves, and are surprised it is difficult. Frankly, I almost
think it would be good to have less documentation, as an
'anti-incentive'. Building software which rely on binaries linked with
several languages is just something inherently difficult and requires a
lot of knowledge for the platform. The fact that ATLAS, BLAS and LAPACK
use non standard build procedures certainly does not help either.

>  This is going to remain a very tough issue
> because scipy depends on packages that are complex and hard to build.
> Note that if you dont need smart lin. algebra you still have plenty of
> good stuff in scipy despite this lapack failure. Maybe what would be
> nice is for the scipy build process to clearly disable some specific
> libs if something goes wrong and report it at the end of the build.

That's one of the reason I worked on numscons: in numscons, all
dependencies are actually checked, contrary to numpy.distutils which
just checks for the *presence* of a dependency. For example, if your
atlas is somewhat buggy and cannot be linked, numscons detects it
because before using atlas, it tries to build/run a small program which
uses atlas, and this is logged.

cheers,

David
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Johann Cohen-Tanugi-2
Salut!
Super... je m'etais promis de tester ton setup numscons, et bien entendu
j'ai pas trouvé le temps ;) Une raison de plus pour essayer, mais le
marathon d'abord!
Johann

David Cournapeau wrote:

> Johann Cohen-Tanugi wrote:
>  
>> well, I am not sure the doc marathon will deal with building scipy, at
>> least as a priority....
>>    
>
> Yes, I agree. I think too many people try to build all the dependencies
> by themselves, and are surprised it is difficult. Frankly, I almost
> think it would be good to have less documentation, as an
> 'anti-incentive'. Building software which rely on binaries linked with
> several languages is just something inherently difficult and requires a
> lot of knowledge for the platform. The fact that ATLAS, BLAS and LAPACK
> use non standard build procedures certainly does not help either.
>
>  
>>  This is going to remain a very tough issue
>> because scipy depends on packages that are complex and hard to build.
>> Note that if you dont need smart lin. algebra you still have plenty of
>> good stuff in scipy despite this lapack failure. Maybe what would be
>> nice is for the scipy build process to clearly disable some specific
>> libs if something goes wrong and report it at the end of the build.
>>    
>
> That's one of the reason I worked on numscons: in numscons, all
> dependencies are actually checked, contrary to numpy.distutils which
> just checks for the *presence* of a dependency. For example, if your
> atlas is somewhat buggy and cannot be linked, numscons detects it
> because before using atlas, it tries to build/run a small program which
> uses atlas, and this is logged.
>
> cheers,
>
> David
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Johann Cohen-Tanugi-2
ooops that happens to me once in a while. This was for David's eyes only ;)
J.

Johann Cohen-Tanugi wrote:

> Salut!
> Super... je m'etais promis de tester ton setup numscons, et bien entendu
> j'ai pas trouvé le temps ;) Une raison de plus pour essayer, mais le
> marathon d'abord!
> Johann
>
> David Cournapeau wrote:
>  
>> Johann Cohen-Tanugi wrote:
>>  
>>    
>>> well, I am not sure the doc marathon will deal with building scipy, at
>>> least as a priority....
>>>    
>>>      
>> Yes, I agree. I think too many people try to build all the dependencies
>> by themselves, and are surprised it is difficult. Frankly, I almost
>> think it would be good to have less documentation, as an
>> 'anti-incentive'. Building software which rely on binaries linked with
>> several languages is just something inherently difficult and requires a
>> lot of knowledge for the platform. The fact that ATLAS, BLAS and LAPACK
>> use non standard build procedures certainly does not help either.
>>
>>  
>>    
>>>  This is going to remain a very tough issue
>>> because scipy depends on packages that are complex and hard to build.
>>> Note that if you dont need smart lin. algebra you still have plenty of
>>> good stuff in scipy despite this lapack failure. Maybe what would be
>>> nice is for the scipy build process to clearly disable some specific
>>> libs if something goes wrong and report it at the end of the build.
>>>    
>>>      
>> That's one of the reason I worked on numscons: in numscons, all
>> dependencies are actually checked, contrary to numpy.distutils which
>> just checks for the *presence* of a dependency. For example, if your
>> atlas is somewhat buggy and cannot be linked, numscons detects it
>> because before using atlas, it tries to build/run a small program which
>> uses atlas, and this is logged.
>>
>> cheers,
>>
>> David
>> _______________________________________________
>> SciPy-user mailing list
>> [hidden email]
>> http://projects.scipy.org/mailman/listinfo/scipy-user
>>  
>>    
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
In reply to this post by cdavid
Well from my point of view, it is much harder compile scipy than to
compile gcc or a kernel because it looks like black magic :(

To be very pragmatic, I do agree on this  statement :

"it would be good to have less documentation, as an 'anti-incentive'."

but if you want the svn versions to be tested you need also a doc for "experts" users.

I do like to try to fix a bug in a numerical algo but first I would like to be able to install the svn scipy version and to run the scipy.test() without errors coming from the installation itself.

"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone".

Of course it is not that esay because scipy is based on a mix of C/fortran old (but nice) libs...

Cheers,
Xavier

> Johann Cohen-Tanugi wrote:
>  
>> well, I am not sure the doc marathon will deal with building scipy, at
>> least as a priority....
>>    
>
> Yes, I agree. I think too many people try to build all the dependencies
> by themselves, and are surprised it is difficult. Frankly, I almost
> think it would be good to have less documentation, as an
> 'anti-incentive'. Building software which rely on binaries linked with
> several languages is just something inherently difficult and requires a
> lot of knowledge for the platform. The fact that ATLAS, BLAS and LAPACK
> use non standard build procedures certainly does not help either.
>
>  
>>  This is going to remain a very tough issue
>> because scipy depends on packages that are complex and hard to build.
>> Note that if you dont need smart lin. algebra you still have plenty of
>> good stuff in scipy despite this lapack failure. Maybe what would be
>> nice is for the scipy build process to clearly disable some specific
>> libs if something goes wrong and report it at the end of the build.
>>    
>
> That's one of the reason I worked on numscons: in numscons, all
> dependencies are actually checked, contrary to numpy.distutils which
> just checks for the *presence* of a dependency. For example, if your
> atlas is somewhat buggy and cannot be linked, numscons detects it
> because before using atlas, it tries to build/run a small program which
> uses atlas, and this is logged.
>
> cheers,
>
> David
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

cdavid
Xavier Gnata wrote:
> Well from my point of view, it is much harder compile scipy than to
> compile gcc or a kernel because it looks like black magic :(
>  

No, it's not. Really. On a new debian/Ubuntu machine:

sudo apt-get install g++ gcc g77 atlas3-base-dev python-dev

And then, you can build numpy/scipy, and it will work 100 % of the time.
What is difficult is to build the dependencies, and people try to build
them by themselves, or in "weird" configurations.

Try building the kernel with ICC, or try building gcc with a libc which
is not glibc. For that matter, try to build any software from scratch,
and you will see it is not easier.

I think we should make it clearer on scipy install pages that you should
really use the packaged libraries when available. Before, major
distribution had broken blas/lapack, but those days are mostly over,

cheers,

David
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Johann Cohen-Tanugi-2
last time I checked the Fedora blas/lapack distributions were still
flawed.... Did that change for Fedora 9?
Johann

David Cournapeau wrote:

> Xavier Gnata wrote:
>  
>> Well from my point of view, it is much harder compile scipy than to
>> compile gcc or a kernel because it looks like black magic :(
>>  
>>    
>
> No, it's not. Really. On a new debian/Ubuntu machine:
>
> sudo apt-get install g++ gcc g77 atlas3-base-dev python-dev
>
> And then, you can build numpy/scipy, and it will work 100 % of the time.
> What is difficult is to build the dependencies, and people try to build
> them by themselves, or in "weird" configurations.
>
> Try building the kernel with ICC, or try building gcc with a libc which
> is not glibc. For that matter, try to build any software from scratch,
> and you will see it is not easier.
>
> I think we should make it clearer on scipy install pages that you should
> really use the packaged libraries when available. Before, major
> distribution had broken blas/lapack, but those days are mostly over,
>
> cheers,
>
> David
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
In reply to this post by cdavid
Indeed, scipy is very easy to compile when the lib are installed.

well atlas using the package is ok.
umfpack is not on my ubuntu.
Yes I'm able to compile scipy but it complains that umfpack (or
libsparesuite...) is missing when I run the scipy.test().

Maybe the scipy.test() should clearly split the errors in two groups :
One group including "real" bugs and one reporting that libs a missing
but that it is *not* a problem if you do not plan to use this part of scipy

I do agree that the doc should tell the user to use the .deb and I think
all this stuff be just vanish when gfortran will be the default compiler.

To tell you the story : I have installed gcc-4.3 on my hardy to be able
to use openmp with scipy.weave.inline (it works just fine for instance
to implement a TOTAL idl like function. A bug in gcc-4.2 prevent this to
work.).
I do hope that the next release of ubuntu will be based gcc-4.3 and on
gfortran *and* that they will provide us this nice atlas packages.

I must admit that I'm a user working "only" on large arrays so it is a
kind of a corner case ;)

Cheers,
Xavier
ps : I'm not sure but I don't think you can compile the kernel using icc
;). the kernel is written in gcc qnd not in C :)


> Xavier Gnata wrote:
>  
>> Well from my point of view, it is much harder compile scipy than to
>> compile gcc or a kernel because it looks like black magic :(
>>  
>>    
>
> No, it's not. Really. On a new debian/Ubuntu machine:
>
> sudo apt-get install g++ gcc g77 atlas3-base-dev python-dev
>
> And then, you can build numpy/scipy, and it will work 100 % of the time.
> What is difficult is to build the dependencies, and people try to build
> them by themselves, or in "weird" configurations.
>
> Try building the kernel with ICC, or try building gcc with a libc which
> is not glibc. For that matter, try to build any software from scratch,
> and you will see it is not easier.
>
> I think we should make it clearer on scipy install pages that you should
> really use the packaged libraries when available. Before, major
> distribution had broken blas/lapack, but those days are mostly over,
>
> cheers,
>
> David
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Michael Abshoff-2
Xavier Gnata wrote:

Hi.

> Indeed, scipy is very easy to compile when the lib are installed.
>
>  
> well atlas using the package is ok.
> umfpack is not on my ubuntu.
> Yes I'm able to compile scipy but it complains that umfpack (or
> libsparesuite...) is missing when I run the scipy.test().
>
> Maybe the scipy.test() should clearly split the errors in two groups :
> One group including "real" bugs and one reporting that libs a missing
> but that it is *not* a problem if you do not plan to use this part of scipy
>
> I do agree that the doc should tell the user to use the .deb and I think
> all this stuff be just vanish when gfortran will be the default compiler.
>
> To tell you the story : I have installed gcc-4.3 on my hardy to be able
> to use openmp with scipy.weave.inline (it works just fine for instance
> to implement a TOTAL idl like function. A bug in gcc-4.2 prevent this to
> work.).
> I do hope that the next release of ubuntu will be based gcc-4.3 and on
> gfortran *and* that they will provide us this nice atlas packages.
>
>  
Do you mean the 8.04 release? I was surprised to see that it shipped gcc
4.2.3.

> I must admit that I'm a user working "only" on large arrays so it is a
> kind of a corner case ;)
>
> Cheers,
> Xavier
> ps : I'm not sure but I don't think you can compile the kernel using icc
> ;). the kernel is written in gcc qnd not in C :)
>  

The Linux kernel can be compiled with the Intel C compiler since Intel
uses it as a test case, i.e. Intel's compiler try to be as close to gcc
as possible on Linux and MSVC on Windows.

Cheers,

Michae
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

Robin-62
In reply to this post by xavier.gnata (Bugzilla)
Hi,

I wrote the Ubuntu install guide on the wiki. I'm sorry you're having
so much trouble! I know most experts recommend using the system
packages, but at the time I spent a lot of time trying that and
couldn't get it to work - in the end this was the only way I had
success which is why I put it on the wiki.

Perhaps it is now easier to build with the distribution packages, but
I still think it's useful to have the instructions on the wiki...

 From looking at your build log:

On Sun, May 18, 2008 at 12:15 PM, Xavier Gnata <[hidden email]> wrote:
> FOUND:
>  libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
>   library_dirs = ['/usr/lib']
>  language = c
>   include_dirs = ['/usr/include']

It looks like you are picking up the libraries from /usr/lib - however
I notice from this:
> blas_opt_info:
> blas_mkl_info:
> libraries mkl,vml,guide not found in /usr/lib
> libraries mkl,vml,guide not found in /usr/local/lib/scipy/lib
> NOT AVAILABLE

that you must have specified /usr/local/lib/scipy/lib somewhere in the
site.cfg so I suspect the ATLAS you built yourself is there.
So I think you probably have a system ATLAS installed which is the one
being used from /usr/lib - this is built with g77 and since the rest
of numpy/scipy is built with gfortran that could be where the problems
are coming from.

Try checking your site.cfg to get it to pick up the versions you
built. (you could post your site.cfg file)

The only other thing is that in between builds you need to manually
delete /usr/lib/python2.5/site-packages/numpy and scipy and the build
directory in the numpy and scipy source directories.

I just ran through the install instructions on hardy with ATLAS 3.8.1
and latest svn (numpy 5188, scipy 4376), UMFPACK 5.2.0 and it seemed
to work fine.

I get no errors with numpy and 4 errors and 7 failures with scipy but
I am pretty sure these are unrelated to the build.

Cheers

Robin
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

xavier.gnata (Bugzilla)
I think the tutorial is fine :)
I also think I' just going to wait for the next version of ubuntu and I
will try again with a clean install of imprepid ibex.
Of course, I'm stil a svn user and the parts of scipy I really use are
running just fine :)

Michael : gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) but it is still buggy if you try to use openmp.


xavier

> Hi,
>
> I wrote the Ubuntu install guide on the wiki. I'm sorry you're having
> so much trouble! I know most experts recommend using the system
> packages, but at the time I spent a lot of time trying that and
> couldn't get it to work - in the end this was the only way I had
> success which is why I put it on the wiki.
>
> Perhaps it is now easier to build with the distribution packages, but
> I still think it's useful to have the instructions on the wiki...
>
>  From looking at your build log:
>
> On Sun, May 18, 2008 at 12:15 PM, Xavier Gnata <[hidden email]> wrote:
>  
>> FOUND:
>>  libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
>>   library_dirs = ['/usr/lib']
>>  language = c
>>   include_dirs = ['/usr/include']
>>    
>
> It looks like you are picking up the libraries from /usr/lib - however
> I notice from this:
>  
>> blas_opt_info:
>> blas_mkl_info:
>> libraries mkl,vml,guide not found in /usr/lib
>> libraries mkl,vml,guide not found in /usr/local/lib/scipy/lib
>> NOT AVAILABLE
>>    
>
> that you must have specified /usr/local/lib/scipy/lib somewhere in the
> site.cfg so I suspect the ATLAS you built yourself is there.
> So I think you probably have a system ATLAS installed which is the one
> being used from /usr/lib - this is built with g77 and since the rest
> of numpy/scipy is built with gfortran that could be where the problems
> are coming from.
>
> Try checking your site.cfg to get it to pick up the versions you
> built. (you could post your site.cfg file)
>
> The only other thing is that in between builds you need to manually
> delete /usr/lib/python2.5/site-packages/numpy and scipy and the build
> directory in the numpy and scipy source directories.
>
> I just ran through the install instructions on hardy with ATLAS 3.8.1
> and latest svn (numpy 5188, scipy 4376), UMFPACK 5.2.0 and it seemed
> to work fine.
>
> I get no errors with numpy and 4 errors and 7 failures with scipy but
> I am pretty sure these are unrelated to the build.
>
> Cheers
>
> Robin
> _______________________________________________
> SciPy-user mailing list
> [hidden email]
> http://projects.scipy.org/mailman/listinfo/scipy-user
>  

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

cdavid
In reply to this post by xavier.gnata (Bugzilla)
Xavier Gnata wrote:

> Indeed, scipy is very easy to compile when the lib are installed.
>
> well atlas using the package is ok.
> umfpack is not on my ubuntu.
> Yes I'm able to compile scipy but it complains that umfpack (or
> libsparesuite...) is missing when I run the scipy.test().
>
> Maybe the scipy.test() should clearly split the errors in two groups :
> One group including "real" bugs and one reporting that libs a missing
> but that it is *not* a problem if you do not plan to use this part of scipy
>  

Yes, it is a problem, I agree. There are too many dependencies in scipy,
with too much magic to make some things work. It would be much better to
cut the dependencies, and support fully a restricted set instead of
supporting many things at 50 %.

> I do agree that the doc should tell the user to use the .deb and I think
> all this stuff be just vanish when gfortran will be the default compiler.
>  

I do not share your optimism :) People will still have trouble with
atlas, etc...

>
> Cheers,
> Xavier
> ps : I'm not sure but I don't think you can compile the kernel using icc
> ;). the kernel is written in gcc qnd not in C :)
>  

You would be surprised :)

ftp://download.intel.com/support/performancetools/c/linux/sb/linuxkernelbuildwhitepaper.pdf

Looks easier than building gcc with a non glibc is more difficult, though.

_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
Reply | Threaded
Open this post in threaded view
|

Re: scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

cdavid
In reply to this post by Johann Cohen-Tanugi-2
Johann Cohen-Tanugi wrote:
> last time I checked the Fedora blas/lapack distributions were still
> flawed.... Did that change for Fedora 9?
>  

At least for FC 6, 7 and 8, I build blas/lapack which do work for numpy
and scipy. As I mentioned before, I do not use rpm-based distributions,
and it would be great to have someone who uses them and care about
numpy/scipy to take over.

I can't remember when/where we discuss it, but it would be good to have
someone from fedora to take over this.

cheers,

David
_______________________________________________
SciPy-user mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/scipy-user
12