Mailman 3 March 2009 - NumPy-Discussion

[Announce] Numpy 1.3.0 rc1
by David Cournapeau 02 Apr '09

02 Apr '09

Hi, I am pleased to announce the release of the rc1 for numpy 1.3.0. You can find source tarballs and installers for both Mac OS X and Windows on the sourceforge page: https://sourceforge.net/projects/numpy/ <https://sourceforge.net/projects/numpy/> The release note for the 1.3.0 release are below, The Numpy developers ========================= NumPy 1.3.0 Release Notes ========================= This minor includes numerous bug fixes, official python 2.6 support, and several new features such as generalized ufuncs. Highlights ========== Python 2.6 support ~~~~~~~~~~~~~~~~~~ Python 2.6 is now supported on all previously supported platforms, including windows. http://www.python.org/dev/peps/pep-0361/ Generalized ufuncs ~~~~~~~~~~~~~~~~~~ There is a general need for looping over not only functions on scalars but also over functions on vectors (or arrays), as explained on http://scipy.org/scipy/numpy/wiki/GeneralLoopingFunctions. We propose to realize this concept by generalizing the universal functions (ufuncs), and provide a C implementation that adds ~500 lines to the numpy code base. In current (specialized) ufuncs, the elementary function is limited to element-by-element operations, whereas the generalized version supports "sub-array" by "sub-array" operations. The Perl vector library PDL provides a similar functionality and its terms are re-used in the following. Each generalized ufunc has information associated with it that states what the "core" dimensionality of the inputs is, as well as the corresponding dimensionality of the outputs (the element-wise ufuncs have zero core dimensions). The list of the core dimensions for all arguments is called the "signature" of a ufunc. For example, the ufunc numpy.add has signature "(),()->()" defining two scalar inputs and one scalar output. Another example is (see the GeneralLoopingFunctions page) the function inner1d(a,b) with a signature of "(i),(i)->()". This applies the inner product along the last axis of each input, but keeps the remaining indices intact. For example, where a is of shape (3,5,N) and b is of shape (5,N), this will return an output of shape (3,5). The underlying elementary function is called 3*5 times. In the signature, we specify one core dimension "(i)" for each input and zero core dimensions "()" for the output, since it takes two 1-d arrays and returns a scalar. By using the same name "i", we specify that the two corresponding dimensions should be of the same size (or one of them is of size 1 and will be broadcasted). The dimensions beyond the core dimensions are called "loop" dimensions. In the above example, this corresponds to (3,5). The usual numpy "broadcasting" rules apply, where the signature determines how the dimensions of each input/output object are split into core and loop dimensions: While an input array has a smaller dimensionality than the corresponding number of core dimensions, 1's are pre-pended to its shape. The core dimensions are removed from all inputs and the remaining dimensions are broadcasted; defining the loop dimensions. The output is given by the loop dimensions plus the output core dimensions. Experimental Windows 64 bits support ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Numpy can now be built on windows 64 bits (amd64 only, not IA64), with both MS compilers and mingw-w64 compilers: This is *highly experimental*: DO NOT USE FOR PRODUCTION USE. See INSTALL.txt, Windows 64 bits section for more information on limitations and how to build it by yourself. New features ============ Formatting issues ~~~~~~~~~~~~~~~~~ Float formatting is now handled by numpy instead of the C runtime: this enables locale independent formatting, more robust fromstring and related methods. Special values (inf and nan) are also more consistent across platforms (nan vs IND/NaN, etc...), and more consistent with recent python formatting work (in 2.6 and later). Nan handling in max/min ~~~~~~~~~~~~~~~~~~~~~~~ The maximum/minimum ufuncs now reliably propagate nans. If one of the arguments is a nan, then nan is retured. This affects np.min/np.max, amin/amax and the array methods max/min. New ufuncs fmax and fmin have been added to deal with non-propagating nans. Nan handling in sign ~~~~~~~~~~~~~~~~~~~~ The ufunc sign now returns nan for the sign of anan. New ufuncs ~~~~~~~~~~ #. fmax - same as maximum for integer types and non-nan floats. Returns the non-nan argument if one argument is nan and returns nan if both arguments are nan. #. fmin - same as minimum for integer types and non-nan floats. Returns the non-nan argument if one argument is nan and returns nan if both arguments are nan. #. deg2rad - converts degrees to radians, same as the radians ufunc. #. rad2deg - converts radians to degrees, same as the degrees ufunc. #. log2 - base 2 logarithm. #. exp2 - base 2 exponential. #. trunc - truncate floats to nearest integer towards zero. #. logaddexp - add numbers stored as logarithms and return the logarithm of the result. #. logaddexp2 - add numbers stored as base 2 logarithms and return the base 2 logarithm of the result result. Masked arrays ~~~~~~~~~~~~~ Several new features and bug fixes, including: * structured arrays should now be fully supported by MaskedArray (r6463, r6324, r6305, r6300, r6294...) * Minor bug fixes (r6356, r6352, r6335, r6299, r6298) * Improved support for __iter__ (r6326) * made baseclass, sharedmask and hardmask accesible to the user (but read-only) * doc update gfortran support on windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gfortran can now be used as a fortran compiler for numpy on windows, even when the C compiler is Visual Studio (VS 2005 and above; VS 2003 will NOT work). Gfortran + Visual studio does not work on windows 64 bits (but gcc + gfortran does). It is unclear whether it will be possible to use gfortran and visual studio at all on x64. Arch option for windows binary ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Automatic arch detection can now be bypassed from the command line for the superpack installed: numpy-1.3.0-superpack-win32.exe /arch=nosse will install a numpy which works on any x86, even if the running computer supports SSE set. Deprecated features =================== Histogram ~~~~~~~~~ The semantics of histogram has been modified to fix long-standing issues with outliers handling. The main changes concern #. the definition of the bin edges, now including the rightmost edge, and #. the handling of upper outliers, now ignored rather than tallied in the rightmost bin. The previous behavior is still accessible using `new=False`, but this is deprecated, and will be removed entirely in 1.4.0. Documentation changes ===================== A lot of documentation has been added. Both user guide and references can be built from sphinx. New C API ========= Multiarray API ~~~~~~~~~~~~~~ The following functions have been added to the multiarray C API: * PyArray_GetEndianness: to get runtime endianness Ufunc API ~~~~~~~~~~~~~~ The following functions have been added to the ufunc API: * PyUFunc_FromFuncAndDataAndSignature: to declare a more general ufunc (generalized ufunc). New defines ~~~~~~~~~~~ New public C defines are available for ARCH specific code through numpy/npy_cpu.h: * NPY_CPU_X86: x86 arch (32 bits) * NPY_CPU_AMD64: amd64 arch (x86_64, NOT Itanium) * NPY_CPU_PPC: 32 bits ppc * NPY_CPU_PPC64: 64 bits ppc * NPY_CPU_SPARC: 32 bits sparc * NPY_CPU_SPARC64: 64 bits sparc * NPY_CPU_S390: S390 * NPY_CPU_IA64: ia64 * NPY_CPU_PARISC: PARISC New macros for CPU endianness has been added as well (see internal changes below for details): * NPY_BYTE_ORDER: integer * NPY_LITTLE_ENDIAN/NPY_BIG_ENDIAN defines Those provide portable alternatives to glibc endian.h macros for platforms without it. Portable NAN, INFINITY, etc... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ npy_math.h now makes available several portable macro to get NAN, INFINITY: * NPY_NAN: equivalent to NAN, which is a GNU extension * NPY_INFINITY: equivalent to C99 INFINITY * NPY_PZERO, NPY_NZERO: positive and negative zero respectively Corresponding single and extended precision macros are available as well. All references to NAN, or home-grown computation of NAN on the fly have been removed for consistency. Internal changes ================ numpy.core math configuration revamp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This should make the porting to new platforms easier, and more robust. In particular, the configuration stage does not need to execute any code on the target platform, which is a first step toward cross-compilation. http://projects.scipy.org/numpy/browser/trunk/doc/neps/math_config_clean.txt umath refactor ~~~~~~~~~~~~~~ A lot of code cleanup for umath/ufunc code (charris). Improvements to build warnings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Numpy can now build with -W -Wall without warnings http://projects.scipy.org/numpy/browser/trunk/doc/neps/warnfix.txt Separate core math library ~~~~~~~~~~~~~~~~~~~~~~~~~~ The core math functions (sin, cos, etc... for basic C types) have been put into a separate library; it acts as a compatibility layer, to support most C99 maths functions (real only for now). The library includes platform-specific fixes for various maths functions, such as using those versions should be more robust than using your platform functions directly. The API for existing functions is exactly the same as the C99 math functions API; the only difference is the npy prefix (npy_cos vs cos). The core library will be made available to any extension in 1.4.0. CPU arch detection ~~~~~~~~~~~~~~~~~~ npy_cpu.h defines numpy specific CPU defines, such as NPY_CPU_X86, etc... Those are portable across OS and toolchains, and set up when the header is parsed, so that they can be safely used even in the case of cross-compilation (the values is not set when numpy is built), or for multi-arch binaries (e.g. fat binaries on Max OS X). npy_endian.h defines numpy specific endianness defines, modeled on the glibc endian.h. NPY_BYTE_ORDER is equivalent to BYTE_ORDER, and one of NPY_LITTLE_ENDIAN or NPY_BIG_ENDIAN is defined. As for CPU archs, those are set when the header is parsed by the compiler, and as such can be used for cross-compilation and multi-arch binaries. Checksums ========= 5c6b2f02d0846317c6e7bffa39f6f828 release/installers/numpy-1.3.0rc1.zip 20cdddd69594420b0f8556bbc4a27a5a release/installers/numpy-1.3.0rc1.tar.gz f85231c4a27b39f7cb713ef22926931e release/installers/numpy-1.3.0rc1-py2.5-macosx10.5.dmg b24bb536492502611ea797d9410bb7c2 release/installers/numpy-1.3.0rc1-win32-superpack-python2.5.exe

12 37

Windows buildbot
by Charles R Harris 31 Mar '09

31 Mar '09

Hi David, Stefan, The windows buildbot is back online but seems to have a configuration problem. It would be nice to see that build working before the release, so it would be nice if you two could take a look at the error messages/contact Heller. Chuck

1 0

Optical autocorrelation calculated with numpy is slow
by João Luís Silva 31 Mar '09

31 Mar '09

Hi, I wrote a script to calculate the *optical* autocorrelation of an electric field. It's like the autocorrelation, but sums the fields instead of multiplying them. I'm calculating I(tau) = integral( abs(E(t)+E(t-tau))**2,t=-inf..inf) with script appended at the end. It's too slow for my purposes (takes ~5 seconds, and scales ~O(N**2)). numpy's correlate is fast enough, but isn't what I need as it multiplies instead of add the fields. Could you help me get this script to run faster (without having to write it in another programming language) ? Thanks, João Silva #-------------------------------------------------------- import numpy as np #import matplotlib.pyplot as plt n = 2**12 n_autocorr = 3*n-2 c = 3E2 w0 = 2.0*np.pi*c/800.0 t_max = 100.0 t = np.linspace(-t_max/2.0,t_max/2.0,n) E = np.exp(-(t/10.0)**2)*np.exp(1j*w0*t) #Electric field dt = t[1]-t[0] t_autocorr=np.linspace(-dt*n_autocorr/2.0,dt*n_autocorr/2.0,n_autocorr) E1 = np.zeros(n_autocorr,dtype=E.dtype) E2 = np.zeros(n_autocorr,dtype=E.dtype) Ac = np.zeros(n_autocorr,dtype=np.float64) E2[n-1:n-1+n] = E[:] for i in range(2*n-2): E1[:] = 0.0 E1[i:i+n] = E[:] Ac[i] = np.sum(np.abs(E1+E2)**2) Ac *= dt #plt.plot(t_autocorr,Ac) #plt.show() #--------------------------------------------------------

4 5

A module for homogeneous transformation matrices, Euler angles and quaternions
by Gareth Elston 30 Mar '09

30 Mar '09

I found a nice module for these transforms at http://www.lfd.uci.edu/~gohlke/code/transformations.py.html . I've been using an older version for some time and thought it might make a good addition to numpy/scipy. I made some simple mods to the older version to add a couple of functions I needed and to allow it to be used with Python 2.4. The module is pure Python (2.5, with numpy 1.2 imported), includes doctests, and is BSD licensed. Here's the first part of the module docstring: """Homogeneous Transformation Matrices and Quaternions. A library for calculating 4x4 matrices for translating, rotating, mirroring, scaling, shearing, projecting, orthogonalizing, and superimposing arrays of homogenous coordinates as well as for converting between rotation matrices, Euler angles, and quaternions. """ I'd like to see this added to numpy/scipy so I know I've got some reading to do (scipy.org/Developer_Zone and the huge scipy-dev discussions on Scipy development infrastructure / workflow) to make sure it follows the guidelines, but where would people like to see this? In numpy? scipy? scikits? elsewhere? I seem to remember that there was a first draft of a guide for developers being written. Are there any links available? Thanks, Gareth.

5 5

lost with slicing
by Partridge, Matthew BGI SYD 30 Mar '09

30 Mar '09

I apologise if I'm asking an obvious question or one that has already been addressed. I've tried to understand the documentation in the numpy manual on slicing, but I'm a bit lost. I'm trying to do indexing using both slices and index lists. I have a problem when I do something like: x[0, :, [0,1,2]] Here are a couple of examples: >>> a = numpy.arange(6).reshape(2,3) >>> print a [[0 1 2] [3 4 5]] >>> print a[:, [0,1,2]] # example 1 - this works as I expected [[0 1 2] [3 4 5]] >>> b = numpy.arange(6).reshape(1,2,3) >>> print b [[[0 1 2] [3 4 5]]] >>> print b[0, :, [0,1,2]] # example 2 - this seems to be the transpose of what I was expecting [[0 3] [1 4] [2 5]] >>> print b[0, [[0],[1]], [[0,1,2]]] # example 3 - this is what I expected [[0 1 2] [3 4 5]] Am I doing something wrong? Why do we get different behaviour in example 2 compared with example 1 or example 3? (I'm using numpy 1.0.3.1 on python 2.4.1 for windows, but I've tried some more recent versions of numpy as well.) mattp -- This message and any attachments are confidential, proprietary, and may be privileged. If this message was misdirected, Barclays Global Investors (BGI) does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BGI, unless the author is authorized by BGI to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BGI. Although BGI operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.

3 4

np.savez not multi-processing safe, alternatives?
by Wes McKinney 30 Mar '09

30 Mar '09

I have a process that stores a number of sets of 3 arrays output which can either be stored as a few .npy files or an .npz file with the same keys in each file (let's say, writing roughly 10,000 npz files, all containing the same keys 'a', 'b', 'c'). If I run multiple processes on the same machine (desirable, since they heavily database-IO-bound), over a period of hours some of the npz-writes will collide and fail due to the use of tempfile and tempfile.gettempdir() (either one of the .npy subfiles will be locked for writing or will get os.remove'd while the zip file is being written). So my question-- recommendations for a way around this, or possible to change the savez function to make it less likely to happen? (I am on Win32) Thanks, Wes

2 1

Re: [Numpy-discussion] Failure with 1.3.0b1 under Solaris 10 SPARC
by Jeff Blaine 30 Mar '09

30 Mar '09

Same problem with 1.3.0rc1 Jeff Blaine wrote: > Aside from this, the website for NumPy should have a link to the > list subscription address, not a link to the list itself (which > cannot be posted to unless one is a member). > > Python 2.4.2 (#2, Dec 6 2006, 17:18:19) > [GCC 3.3.5] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> import numpy > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File > "/afs/.rcf.mitre.org/lang/python/sun4x_510/2.4.2/lib/python2.4/site-packages/numpy/__init__.py", > > line 130, in ? > import add_newdocs > File > "/afs/.rcf.mitre.org/lang/python/sun4x_510/2.4.2/lib/python2.4/site-packages/numpy/add_newdocs.py", > > line 9, in ? > from lib import add_newdoc > File > "/afs/.rcf.mitre.org/lang/python/sun4x_510/2.4.2/lib/python2.4/site-packages/numpy/lib/__init__.py", > > line 4, in ? > from type_check import * > File > "/afs/.rcf.mitre.org/lang/python/sun4x_510/2.4.2/lib/python2.4/site-packages/numpy/lib/type_check.py", > > line 8, in ? > import numpy.core.numeric as _nx > File > "/afs/.rcf.mitre.org/lang/python/sun4x_510/2.4.2/lib/python2.4/site-packages/numpy/core/__init__.py", > > line 5, in ? > import multiarray > ImportError: ld.so.1: python: fatal: relocation error: file > /afs/.rcf.mitre.org/lang/python/sun4x_510/2.4.2/lib/python2.4/site-packages/numpy/core/multiarray.so: > > symbol __builtin_isfinite: referenced symbol not found > >>> > > See build.log attached as well. > > >

2 4

SWIG and numpy.i
by Kevin Françoisse 30 Mar '09

30 Mar '09

Hi everyone, I have been using NumPy for a couple of month now, as part of my research project at the university. But now, I have to use a big C library I wrote myself in a python project. So I choose to use SWIG for the interface between both my python script and my C library. To make things more comprehensible, I wrote a small C methods that illustrate my problem: /* matrix.c */ #include <stdlib.h> #include <stdio.h> /* Compute the sum of a vector of reals */ double vecSum(int* vec,int m){ int i; double sum =0.0; for(i=0;i<m;i++){ sum += vec[i]; } return sum; } /***/ /* matrix.h */ double vecSum(int* vec,int m); /***/ /* matrix.i */ %module matrix %{ #define SWIG_FILE_WITH_INIT #include "matrix.h" %} extern double vecSum(int* vec, int m); %include "numpy.i" %init %{ import_array(); %} %apply (int* IN_ARRAY1, int DIM1) {(int* vec, int m)}; %include "matrix.h" /***/ I'm using a python script to compile my swig interface and my C files (running Mac OS X 10.5) /* matrixSetup.py */ from distutils.core import setup, Extension import numpy setup(name='matrix', version='1.0', ext_modules =[Extension('_matrix', ['matrix.c','matrix.i'], include_dirs = [numpy.get_include(),'.'])]) /***/ Everything seems to work fine ! But when I test my wrapped module in python with an small NumPy array, here what I get : >>> import matrix >>> from numpy import * >>> a = arange(10) >>> matrix.vecSum(a,a.shape[0]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: in method 'vecSum', argument 1 of type 'int *' How can I tell SWIG that my Integer NumPy array should represent a int* array in C ? Thank you very much, Kevin

2 4

Command line args for the Intel compilers (32 bit)
by Christian Marquardt 29 Mar '09

29 Mar '09

Hi, I've been carrying these modifcations of the build-in compiler command line arguments for the 32-bit Intel compilers for quite some while now; maybe they are interesting for other people as well... I've been using this with ifort (IFORT) 10.1 20080801 on a Suse Linux 10.3. Rationale for individual changes: - numpy-1.3.0rc1/numpy/distutils/fcompiler/intel.py: - For pentiumM's, options are changed from '-tpp7 -xB' to '-xN': The compiler documentation says that -tpp<?> and -xB are deprecated and will be removed in future versions. - 'linker_so' gets an additional "-xN": If code is compiled with -x<?>, additional "vector math" libraries (libvml*) need to be linked in, or loading the shared objects may fail at runtime; so I added this to the link command. If other '-x<?>' options are used by the numpy distutils, the linker command should be modified accordingly - so this patch probably is not generic. - numpy-1.3.0rc1/numpy/distutils/intelccompiler.py: - A dedicated C++ compiler (icpc) is introduced and used for compiling C++ code, *and* for linking: I have found that C++ extensions require additional runtime libraries that are not linked in with the normal icc command, causing the loading of C++ extensions to fail at runtime. This used to be a problem with scipy in earlier versions, but I think currently, there's no C++ any more in scipy (but I could be wrong). Hope this is useful, Christian.

1 0

Re: [Numpy-discussion] Numpy v1.3.0b1 on Linux w/ Intel compilers - unknown file type
by Christian Marquardt 29 Mar '09

29 Mar '09

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 (test_linalg.TestEigvalsh) ---------------------------------------------------------------------- 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 249, 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+0.j, -2.60555128+0.j]) y: array([-2.60555128 +1.11022302e-16j, 4.60555128 -1.11022302e-16j]) ====================================================================== FAIL: test_csingle (test_linalg.TestEigvalsh) ---------------------------------------------------------------------- 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 249, 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+0.j, -2.60555124+0.j], dtype=complex64) y: array([-2.60555124 +1.11022302e-16j, 4.60555124 -1.11022302e-16j], dtype=complex64) ---------------------------------------------------------------------- Ran 2029 tests in 19.729s FAILED (KNOWNFAIL=1, failures=4) MEDEA /home/marq> ----- "Charles R Harris" <charlesr.harris(a)gmail.com> wrote: > > > > On Thu, Mar 26, 2009 at 9:06 PM, Charles R Harris < charlesr.harris(a)gmail.com > wrote: > > > > > 2009/3/26 Christian Marquardt < christian(a)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(a)scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Dr. Christian Marquardt Email: christian(a)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

2 2