Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
They are, also in v1..3.0rc1 Many thanks! Christian - Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/27 Christian Marquardt christ...@marquardt.sc Error messages? Sure;-) python -c 'import numpy; numpy.test()' Running unit tests for numpy NumPy version 1.3.0b1 NumPy is installed in /opt/apps/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Aug 31 2008, 15:16:34) [GCC Intel(R) C++ gcc 4.2 mode] nose version 0.10.4 ...K.FF..FF.. OK, the tests should be fixed in r6773. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Dr. Christian Marquardt Email: christ...@marquardt.sc Wilhelm-Leuschner-Str. 27 Tel.: +49 (0) 6151 95 13 776 64293 Darmstadt Mobile: +49 (0) 179 290 84 74 Germany Fax: +49 (0) 6151 95 13 885 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
Error messages? Sure;-) python -c 'import numpy; numpy.test()' Running unit tests for numpy NumPy version 1.3.0b1 NumPy is installed in /opt/apps/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Aug 31 2008, 15:16:34) [GCC Intel(R) C++ gcc 4.2 mode] nose version 0.10.4 ...K.FF..FF.. == FAIL: test_cdouble (test_linalg.TestEigh) -- Traceback (most recent call last): File /opt/apps/lib/python2.5/site-packages/numpy/linalg/tests/test_linalg.py, line 221, in test_cdouble self.do(a) File /opt/apps/lib/python2.5/site-packages/numpy/linalg/tests/test_linalg.py, line 259, in do assert_almost_equal(ev, evalues) File /opt/apps/lib/python2.5/site-packages/numpy/linalg/tests/test_linalg.py, line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File /opt/apps/lib/python2.5/site-packages/numpy/testing/utils.py, line 215, in assert_almost_equal return assert_array_almost_equal(actual, desired, decimal, err_msg) File /opt/apps/lib/python2.5/site-packages/numpy/testing/utils.py, line 321, in assert_array_almost_equal header='Arrays are not almost equal') File /opt/apps/lib/python2.5/site-packages/numpy/testing/utils.py, line 302, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 4.60555128, -2.60555128]) y: array([-2.60555128 +1.11022302e-16j, 4.60555128 -1.11022302e-16j]) == FAIL: test_csingle (test_linalg.TestEigh) -- Traceback (most recent call last): File /opt/apps/lib/python2.5/site-packages/numpy/linalg/tests/test_linalg.py, line 217, in test_csingle self.do(a) File /opt/apps/lib/python2.5/site-packages/numpy/linalg/tests/test_linalg.py, line 259, in do assert_almost_equal(ev, evalues) File /opt/apps/lib/python2.5/site-packages/numpy/linalg/tests/test_linalg.py, line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File /opt/apps/lib/python2.5/site-packages/numpy/testing/utils.py, line 215, in assert_almost_equal return assert_array_almost_equal(actual, desired, decimal, err_msg) File /opt/apps/lib/python2.5/site-packages/numpy/testing/utils.py, line 321, in assert_array_almost_equal header='Arrays are not almost equal') File /opt/apps/lib/python2.5/site-packages/numpy/testing/utils.py, line 302, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 4.60555124, -2.60555124], dtype=float32) y: array([-2.60555124 +1.11022302e-16j, 4.60555124 -1.11022302e-16j], dtype=complex64) == FAIL: test_cdouble
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
Hi David, I *guess* that the compiler command line does not work with your changes, and that distutils got confused, and fails somewhere later (or sooner, who knows). Without actually seeing the errors you got, it is difficult to know more - but I would make sure the command line arguments are ok instead of focusing on the .src error, cheers, David I'n not sure if I understand... The compiler options I have changed seem to work (and installation without the build_clib --compiler=intel option to setup.py works fine with them). To be sure I've compiled numpy from the distribution tar file without any patches. With python setup.py config --compiler=intel \ config_fc --fcompiler=intel \ build_ext --compiler=intel build everything compiles fine (and builds the internal lapack, as I haven't given the MKL paths, and have no other lapack / blas installed). With python setup.py config --compiler=intel \ config_fc --fcompiler=intel \ build_clib --compiler=intel \ build_ext --compiler=intel build the attempt to build fails (complete output is below). The python installation I use is also build with the Intel icc compiler; so it does pick up that compiler by default. Maybe something is going wrong in the implementation of build_clib in the numpy distutils? Where would I search for that in the code? Many thanks, Chris. snip, snip MEDEA /home/marq/src/python/04_science/01_numpy/numpy-1.3.0b1python setup.py config --compiler=intel config_fc --fcompiler=intel build_clib --compiler=intel build_ext --compiler=intel build Running from numpy source directory. non-existing path in 'numpy/distutils': 'site.cfg' F2PY Version 2 blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in /opt/intel/mkl/10.0.2.018/lib/32 NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /opt/apps/lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib NOT AVAILABLE atlas_blas_info: libraries f77blas,cblas,atlas not found in /opt/apps/lib libraries f77blas,cblas,atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib NOT AVAILABLE /home/marq/src/python/04_science/01_numpy/numpy-1.3.0b1/numpy/distutils/system_info.py:1383: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) blas_info: libraries blas not found in /opt/apps/lib libraries blas not found in /usr/local/lib libraries blas not found in /usr/lib NOT AVAILABLE /home/marq/src/python/04_science/01_numpy/numpy-1.3.0b1/numpy/distutils/system_info.py:1392: UserWarning: Blas (http://www.netlib.org/blas/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [blas]) or by setting the BLAS environment variable. warnings.warn(BlasNotFoundError.__doc__) blas_src_info: NOT AVAILABLE /home/marq/src/python/04_science/01_numpy/numpy-1.3.0b1/numpy/distutils/system_info.py:1395: UserWarning: Blas (http://www.netlib.org/blas/) sources not found. Directories to search for the sources can be specified in the numpy/distutils/site.cfg file (section [blas_src]) or by setting the BLAS_SRC environment variable. warnings.warn(BlasSrcNotFoundError.__doc__) NOT AVAILABLE lapack_opt_info: lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in /opt/intel/mkl/10.0.2.018/lib/32 NOT AVAILABLE NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /opt/apps/lib libraries lapack_atlas not found in /opt/apps/lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib numpy.distutils.system_info.atlas_threads_info NOT AVAILABLE atlas_info: libraries f77blas,cblas,atlas not found in /opt/apps/lib libraries lapack_atlas not found in /opt/apps/lib libraries f77blas,cblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib numpy.distutils.system_info.atlas_info NOT AVAILABLE /home/marq/src/python/04_science/01_numpy/numpy-1.3.0b1/numpy/distutils/system_info.py:1290: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
2009/3/27 Christian Marquardt christ...@marquardt.sc Error messages? Sure;-) python -c 'import numpy; numpy.test()' Running unit tests for numpy NumPy version 1.3.0b1 NumPy is installed in /opt/apps/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Aug 31 2008, 15:16:34) [GCC Intel(R) C++ gcc 4.2 mode] nose version 0.10.4 ...K.FF..FF.. OK, the tests should be fixed in r6773. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
Hello, I tried to compile and install numpy 1.3.0b1 on a Suse Linux 10.3 with Python 2.5.x and an Intel C and Fortran compilers 10.1 as well as the MKL 10.0. The distutils do find the compilers and the MKL (when using similar settings as I used successfully for all previous numpy versions sonce 1.0.4 or so), but then bail out with the following error: ...python setup.py install [...] running config running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_clib Found executable /opt/intel/cc/10.1.018/bin/icc Could not locate executable ecc customize IntelCCompiler customize IntelCCompiler using build_clib building 'npymath' library compiling C sources C compiler: icc error: unknown file type '.src' (from 'numpy/core/src/npy_math.c.src') I think the error message does not even come from the compiler... I'm lost... What does it mean, and why are there source files named ...c.src? Many thanks, Christian ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
On Thu, Mar 26, 2009 at 6:25 PM, Christian Marquardt christ...@marquardt.sc wrote: Hello, I tried to compile and install numpy 1.3.0b1 on a Suse Linux 10.3 with Python 2.5.x and an Intel C and Fortran compilers 10.1 as well as the MKL 10.0. The distutils do find the compilers and the MKL (when using similar settings as I used successfully for all previous numpy versions sonce 1.0.4 or so), but then bail out with the following error: ...python setup.py install [...] running config running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_clib Found executable /opt/intel/cc/10.1.018/bin/icc Could not locate executable ecc customize IntelCCompiler customize IntelCCompiler using build_clib building 'npymath' library compiling C sources C compiler: icc error: unknown file type '.src' (from 'numpy/core/src/npy_math.c.src') I think the error message does not even come from the compiler... I'm lost... What does it mean, and why are there source files named ...c.src? That file should be preprocessed to produce npy_math.c which ends up in the build directory. I don't know what is going on here, but you might first try deleting the build directory just to see what happens. There might be some setup file that is screwy/outdated also. Did you download the beta and do a clean extract? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
2009/3/26 Christian Marquardt christ...@marquardt.sc Hmm. I downloaded the beta tar file and started from the untarred contents plus a patch for the Intel compilers (some changes of the command line arguments for the compiler and a added setup.cfg file specifying the paths to the Intel MKL libraries) which applied cleanly. I then ran python setup.py config --compiler=intel config_fc --fcompiler=intel build_clib --compiler=intel build_ext --compiler=intel install which failed. After playing around a bit, I found that it seems that the build_clib --compiler=intel subcommand which causes the trouble; after disabling it, that is with python setup.py config --compiler=intel config_fc --fcompiler=intel build_ext --compiler=intel install things compile fine - and all but four of the unit tests fail (test_linalg.TestEigh and test_linalg.TestEigvalsh in both test_csingle and test_cdouble - should I be worried?) Four unit tests fail, or all fail except four? I assume you meant the former. I'm not sure what the failures mean, can you check if they are really bad or just some numbers a little bit off. I'm guessing these routines are calling into MKL. How are the .src files converted? The *.xxx.src files are templates that are processed by numpy/distutils/conv_template.py to produce *.xxx files. When you have to repeat basically the same code with umpteen different types a bit of automation helps. The actual conversion is controlled by the setup/scons files, I don't remember exactly where. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
Oh sorry - you are right (too late in the night here in Europe). The output is similar in all four cases - it looks like AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 4.60555124+0.j, -2.60555124+0.j], dtype=complex64) y: array([-2.60555124 +1.11022302e-16j, 4.60555124 -1.11022302e-16j], dtype=complex64) Are x and y the expected and actual results? That would just show that there are small rounding errors in the imaginary part, and that MKL returns the results in another order, no? - Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/26 Christian Marquardt christ...@marquardt.sc Hmm. I downloaded the beta tar file and started from the untarred contents plus a patch for the Intel compilers (some changes of the command line arguments for the compiler and a added setup.cfg file specifying the paths to the Intel MKL libraries) which applied cleanly. I then ran python setup.py config --compiler=intel config_fc --fcompiler=intel build_clib --compiler=intel build_ext --compiler=intel install which failed. After playing around a bit, I found that it seems that the build_clib --compiler=intel subcommand which causes the trouble; after disabling it, that is with python setup.py config --compiler=intel config_fc --fcompiler=intel build_ext --compiler=intel install things compile fine - and all but four of the unit tests fail (test_linalg.TestEigh and test_linalg.TestEigvalsh in both test_csingle and test_cdouble - should I be worried?) Four unit tests fail, or all fail except four? I assume you meant the former. I'm not sure what the failures mean, can you check if they are really bad or just some numbers a little bit off. I'm guessing these routines are calling into MKL. How are the .src files converted? The *.xxx.src files are templates that are processed by numpy/distutils/conv_template.py to produce *.xxx files. When you have to repeat basically the same code with umpteen different types a bit of automation helps. The actual conversion is controlled by the setup/scons files, I don't remember exactly where. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Dr. Christian Marquardt Email: christ...@marquardt.sc Wilhelm-Leuschner-Str. 27 Tel.: +49 (0) 6151 95 13 776 64293 Darmstadt Mobile: +49 (0) 179 290 84 74 Germany Fax: +49 (0) 6151 95 13 885 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
2009/3/26 Christian Marquardt christ...@marquardt.sc Oh sorry - you are right (too late in the night here in Europe). The output is similar in all four cases - it looks like AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 4.60555124+0.j, -2.60555124+0.j], dtype=complex64) y: array([-2.60555124 +1.11022302e-16j, 4.60555124 -1.11022302e-16j], dtype=complex64) Are x and y the expected and actual results? That would just show that there are small rounding errors in the imaginary part, and that MKL returns the results in another order, no? Looks like a sorting error, the eigen values should be sorted. So it looks like a buggy test from here. Having an imaginary part to the eigenvalues returned by a routine that is supposed to process Hermitean matrices doesn't look right, but the errors are in the double precision range, which is pretty good for float32. I think we need a ticket to fix those tests. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
On Thu, Mar 26, 2009 at 9:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/3/26 Christian Marquardt christ...@marquardt.sc Oh sorry - you are right (too late in the night here in Europe). The output is similar in all four cases - it looks like AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 4.60555124+0.j, -2.60555124+0.j], dtype=complex64) y: array([-2.60555124 +1.11022302e-16j, 4.60555124 -1.11022302e-16j], dtype=complex64) Are x and y the expected and actual results? That would just show that there are small rounding errors in the imaginary part, and that MKL returns the results in another order, no? Looks like a sorting error, the eigen values should be sorted. So it looks like a buggy test from here. Having an imaginary part to the eigenvalues returned by a routine that is supposed to process Hermitean matrices doesn't look right, but the errors are in the double precision range, which is pretty good for float32. I think we need a ticket to fix those tests. Can you post the actual error messages? It will make it easier to find where the failure is. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
2009/3/27 Christian Marquardt christ...@marquardt.sc: Hmm. I downloaded the beta tar file and started from the untarred contents plus a patch for the Intel compilers (some changes of the command line arguments for the compiler and a added setup.cfg file specifying the paths to the Intel MKL libraries) which applied cleanly. I then ran python setup.py config --compiler=intel config_fc --fcompiler=intel build_clib --compiler=intel build_ext --compiler=intel install which failed. After playing around a bit, I found that it seems that the build_clib --compiler=intel subcommand which causes the trouble; after disabling it, that is with I *guess* that the compiler command line does not work with your changes, and that distutils got confused, and fails somewhere later (or sooner, who knows). Without actually seeing the errors you got, it is difficult to know more - but I would make sure the command line arguments are ok instead of focusing on the .src error, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
