Mailman 3 October 2005 - SciPy-Dev

newcore atlas info on Gentoo
by Darren Dale 20 Jan '06

20 Jan '06

In order to get scipy-0.3.2 to build on Gentoo Linux, I use site.cfg in the distutils module. This is necessary because Gentoo has renamed the libf77blas.* libraries to libblas.* in order to allow users to easily switch between different libraries, ATLAS and Intel's MKL for example. When I compile newcore using the old site.cfg, my atlas info is properly reported. However, when I compile newscipy, the atlas info is reportedly unavailable. I looked into system_info.atlas_info and friends, and discovered that _lib_names is not informed by site.cfg, it is hardcoded with ['f77blas', 'cblas'], or ['ptf77blas','ptcblas'], etc. If I remove the 'f77', my atlas info is correctly reported. Darren

3 10

Release of SciPy Core 0.4 (Beta)
by Travis Oliphant 24 Nov '05

24 Nov '05

This is to announce the release of SciPy Core 0.4.X (beta) It is available at sourceforge which you can access by going to http://numeric.scipy.org Thanks to all who helped me with this release, especially Robert Kern Pearu Peterson Now, let's start getting this stable.... -Travis Oliphant

9 29

array logical ops error?
by Robert Cimrman 10 Nov '05

10 Nov '05

Hi all, is this the expected behaviour? IMHO (b * c) == (b and c), (b + c) == (b or c) should hold... In [1]:import scipy In [2]:print scipy.__scipy_version__ 0.4.2_1407 In [3]:print scipy.__core_version__ 0.4.3.1401 In [4]:a = scipy.array( [1,2,3,4] ) In [5]:a Out[5]:array([1, 2, 3, 4]) In [6]:b = a == 3 In [7]:b Out[7]:array([False, False, True, False], dtype=bool) In [8]:c = a > 3 In [9]:c Out[9]:array([False, False, False, True], dtype=bool) In [10]:b and c Out[10]:array([False, False, False, True], dtype=bool) In [11]:b * c Out[11]:array([False, False, False, False], dtype=bool) In [12]:b or c Out[12]:array([False, False, True, False], dtype=bool) In [13]:b + c Out[13]:array([False, False, True, True], dtype=bool) r.

10 30

float exception, fblas cgemv - newscipy
by Arnd Baecker 01 Nov '05

01 Nov '05

Hi, on another debian sarge based 32Bit machine (where I made a couple of links so that ATLAS is found) I get the following check_default_beta_y (scipy.linalg.fblas.test_fblas.test_cgemv) ... zsh: 8527 floating point exception The shortest example to reproduce this is gdb file /usr/bin/python run from scipy import * from scipy.basic.random import normal a = normal(0.,1.,(3,3)) x = arange(shape(a)[0]) print a print x linalg.fblas.cgemv(1,a,x) Giving >>> print a [[-0.70685647 0.65494695 0.9179007 ] [-0.30862233 0.58137533 2.01614468] [ 0.18585164 -0.8134587 1.23613689]] >>> print x [0 1 2] >>> linalg.fblas.cgemv(1,a,x) Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 16384 (LWP 26791)] 0x404167a0 in ATL_cgemvC_a1_x1_bXi0_y1 () from /usr/lib/sse2/libatlas.so.3 Does anyone else see this? Any ideas what to do with this? Best, Arnd System details: ipython import scipy scipy.__core_version__ scipy.__scipy_version__ scipy.__scipy_config__.show() gives Python 2.3.5 (#2, Sep 4 2005, 22:01:42) In [1]:import scipy Importing io to scipy Importing fftpack to scipy Importing special to scipy Importing cluster to scipy Importing sparse to scipy Importing utils to scipy Importing interpolate to scipy Importing integrate to scipy Importing signal to scipy Importing optimize to scipy Importing linalg to scipy Importing stats to scipy In [2]:scipy.__core_version__ Out[2]:'0.4.3.1376' In [3]:scipy.__scipy_version__ Out[3]:'0.4.2_1400' In [4]:scipy.__scipy_config__.show() dfftw_info: NOT AVAILABLE blas_opt_info: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib/sse2'] define_macros = [('ATLAS_INFO', '"\\"3.6.0\\""')] language = c djbfft_info: NOT AVAILABLE atlas_blas_threads_info: NOT AVAILABLE lapack_opt_info: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib/atlas', '/usr/lib/'] define_macros = [('ATLAS_INFO', '"\\"3.6.0\\""')] language = f77 atlas_info: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib/atlas', '/usr/lib/'] language = f77 define_macros = [('ATLAS_INFO', '"\\"3.6.0\\""')] fftw_info: NOT AVAILABLE atlas_blas_info: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib/sse2'] language = c define_macros = [('ATLAS_INFO', '"\\"3.6.0\\""')] atlas_threads_info: NOT AVAILABLE Atlas: ls -l /usr/lib/atlas total 17168 lrwxrwxrwx 1 root root 12 Oct 25 00:32 libblas.so -> libblas.so.3 lrwxrwxrwx 1 root root 14 Mar 23 2005 libblas.so.2 -> libblas.so.2.3 -rw-r--r-- 1 root root 3051888 Mar 4 2005 libblas.so.2.3 lrwxrwxrwx 1 root root 14 Nov 18 2004 libblas.so.3 -> libblas.so.3.0 -rw-r--r-- 1 root root 3443424 Oct 27 2004 libblas.so.3.0 lrwxrwxrwx 1 root root 14 Oct 25 00:32 liblapack.so -> liblapack.so.3 lrwxrwxrwx 1 root root 16 Mar 23 2005 liblapack.so.2 -> liblapack.so.2.3 -rw-r--r-- 1 root root 5500688 Mar 4 2005 liblapack.so.2.3 lrwxrwxrwx 1 root root 16 Nov 18 2004 liblapack.so.3 -> liblapack.so.3.0 -rw-r--r-- 1 root root 5537840 Oct 27 2004 liblapack.so.3.0 drwxr-xr-x 2 root root 4096 Nov 18 2004 sse2 ls -l /usr/lib/ | grep atlas drwxr-xr-x 3 root root 4096 Oct 25 00:32 atlas lrwxrwxrwx 1 root root 16 Mar 22 2004 libatlas.so -> sse2/libatlas.so lrwxrwxrwx 1 root root 15 Mar 23 2005 libatlas.so.2 -> libatlas.so.2.3 -rw-r--r-- 1 root root 2835272 Mar 4 2005 libatlas.so.2.3 lrwxrwxrwx 1 root root 15 Nov 18 2004 libatlas.so.3 -> libatlas.so.3.0 -rw-r--r-- 1 root root 3234288 Oct 27 2004 libatlas.so.3.0 lrwxrwxrwx 1 root root 34 Mar 22 2004 liblapack.so -> /usr/lib/atlas/sse2/liblapack.so.3 lrwxrwxrwx 1 root root 25 Mar 22 2004 liblapack_atlas.so -> sse2/liblapack_atlas.so.3 lrwxrwxrwx 1 root root 22 Mar 23 2005 liblapack_atlas.so.2 -> liblapack_atlas.so.2.3 -rw-r--r-- 1 root root 60568 Mar 4 2005 liblapack_atlas.so.2.3 lrwxrwxrwx 1 root root 22 Nov 18 2004 liblapack_atlas.so.3 -> liblapack_atlas.so.3.0 -rw-r--r-- 1 root root 131224 Oct 27 2004 liblapack_atlas.so.3.0

2 1

Adding to an array with __radd__()
by Ed Schofield 01 Nov '05

01 Nov '05

Sparse matrix objects now support adding a sparse matrix to a dense matrix of the same dimensions with the syntax: newdense = sparse + dense I'd like to add support for the opposite order too: newdense = dense + sparse but this doesn't seem possible currently. This operation calls the __radd__() method of the sparse matrix object multiple times, each time passing a single element from the dense matrix. The problem is that the sparse matrix's __radd__ function also needs to know the shape of the matrix and the position of the element it's receiving. Could we change the default behaviour of ndarray objects to invoke the right-hand object's __radd__ function just once, passing the dense array? I think this is the default behaviour for Python objects. What code would break if we made this change? -- Ed

5 14

PyArray_CanCastSafely(exact,inexact) on 64-bit
by Pearu Peterson 01 Nov '05

01 Nov '05

Hi Travis, Number of scipy.test failures occuring on 64-bit systems are due to the fact that PyArray_CanCastSafely(PyArray_LONG,PyArray_DOUBLE) returns true. Though sizeof(long)==sizeof(double) holds on 64-bit machines, shouldn't PyArray_CanCastSafely return false on (exact,inexact) arguments and vice versa? By the definition of can_cast, no bitwise information is lost, but it is not meaningful to pass (double*)(<pointer to long array>) to a numeric function, for example. Or may be I should use some different function than PyArray_CanCastSafely in this situation? Pearu

3 8

Is "bool" the right name?
by Todd Miller 31 Oct '05

31 Oct '05

Trying to add some newcore compatibility to numarray, I bowled through the obvious name collision between the new numarray "bool" and the Python scalar type "bool." The name collision is easy enough to work around in the numarray internals, but it occurred to me that "bool8" might be a better name since it is more explicit, consistent with the other type names, and clearly resolves the recurring question "Is this a 1-bit bool or not?". So, while newcore is still young, does it make sense to rename "bool" to "bool8"? Regards, Todd

3 3

Question about 64-bit integers being cast to double precision
by Travis Oliphant 31 Oct '05

31 Oct '05

What is the opinion of people here regarding the casting of 64-bit integers to double precision. In scipy (as in Numeric), there is the concept of "Casting safely" to a type. This concept is used when choosing a ufunc, for example. My understanding is that a 64-bit integer cannot be cast safely to a double-precision floating point number, because precision is lost in the conversion. However, at least a signed 64-bit integer can usually be cast safely to a long double precision floating point number. This is not too big a deal on 32-bit systems where people rarely request 64-bit integers. However, on some 64-bit systems (where the C long is 64-bit), Python's default integer is 64-bit. Therefore, simple expressions like sqrt(2) which require conversion to floating point will look for the first floating point number that it can convert a 64-bit integer to safely. This can only be a long double. The result is that on 64-bit systems, the long double type gets used a lot more. Is this acceptable? expected? What do those of you on 64-bit systems think? -Travis

8 19

Broken Python Type Alias
by Christopher Hanley 31 Oct '05

31 Oct '05

Greetings, The alias to the python type "sb.float" that previously was working in my regression testing system now raises an attribute error. However, "sb.float_" still functions correctly. Example: In [16]: x = sb.ones((10,),dtype=sb.float) --------------------------------------------------------------------------- exceptions.AttributeError Traceback (most recent call last) /data/sparty1/dev/devCode/<console> AttributeError: 'module' object has no attribute 'float' My regression tests first showed this behavior yesterday morning with the checkout of newcore revision 1396. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338

2 2

Reliability of results
by Nils Wagner 31 Oct '05

31 Oct '05

Hi all, We should take care of using linalg.inv blindly (test_inv.py). So how can we improve the behaviour of linalg.solve, linalg.lu, linalg.inv etc. with respect to "nearly" singular matrices (floating point arithmetic) ? Any pointer would be appreciated. Is it possibe to add the condition number to the output of linalg.solve, linalg.inv, ... ? For example linalg.lstsq returns the singular values. lstsq(a, b, cond=None, overwrite_a=0, overwrite_b=0) lstsq(a, b, cond=None, overwrite_a=0, overwrite_b=0) -> x,resids,rank,s Return least-squares solution of a * x = b. Inputs: a -- An M x N matrix. b -- An M x nrhs matrix or M vector. cond -- Used to determine effective rank of a. Outputs: x -- The solution (N x nrhs matrix) to the minimization problem: 2-norm(| b - a * x |) -> min resids -- The residual sum-of-squares for the solution matrix x (only if M>N and rank==N). rank -- The effective rank of a. s -- Singular values of a in decreasing order. The condition number of a is abs(s[0]/s[-1]). Nils

1 0