Mailman 3 March 2006 - SciPy-User

block diagram or UML generator
by Ryan Krauss March 2, 2006

March 2, 2006

Does anyone know of a Python tool to automatically generate a block diagram or UML sketch of a class based on parsing existing python code? I am trying to think about how to talk about my code from a big picture perspective in my thesis and I don't think that my committee members will care a lot about the details or want to read too much actual code. Any suggestions? Thanks, Ryan

3 2

Compiling scipy on Cygwin
by Jose Luis Gomez Dans March 2, 2006

March 2, 2006

Hi! I have succeeded compiling the SVN version of Numpy on Cygwin. It works, and with it, so does F2PY (using g77/Cygwin). This is very good news. However, I can't yet compile scipy on Cygwin. While I have the LAPACK and BLAS libraries installed from the Cygwin repository, these are not found by the setup program. Do I need to use ATLAS, or compile my own LAPACK+BLAS? Can I use Cygwins version? Thanks! Jose -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

1 0

scipy.stats.ttest_ind broken?
by Zachary Pincus March 1, 2006

March 1, 2006

Hi folks, I'm using scipy 0.4.6 with numpy 0.9.5, and I have noticed that the t- test in the stats library is broken. scipy.stats.ttest_ind([1,2,3], [4,5,6]) ------------------------------------------------------------------------ --- exceptions.TypeError Traceback (most recent call last) /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/scipy/stats/stats.py in ttest_ind(a, b, axis, printit, name1, name2, writemode) 1461 if type(t) == ArrayType: 1462 probs = reshape(probs,t.shape) -> 1463 if len(probs) == 1: 1464 probs = probs[0] 1465 TypeError: len() of unsized object What's happening is that betai is returning a scalar value, which has no length. This causes the len(probs) call to fail. Zach Pincus Program in Biomedical Informatics and Department of Biochemistry Stanford University School of Medicine

1 1

Re: [SciPy-user] gfortran, ifc, compat-g77
by Eric Emsellem March 1, 2006

March 1, 2006

Hi, I thought I answered to your email before. Yes compiling on Suse 10 was not a problem for me. Let me know. Cheers Eric > Hi all, > > It seems to me that installing numpy/scipy on SuSE10.0 is not > straightforward in contrast > to prior versions. > > If I remove compat-g77 and try to rebuild numpy from scratch the ifc is > used. > I thought that gfortran will be used in that case. > Am I missing something ? > > Anyway > > -- =============================================================== Observatoire de Lyon emsellem(a)obs.univ-lyon1.fr 9 av. Charles-Andre tel: +33 4 78 86 83 84 69561 Saint-Genis Laval Cedex fax: +33 4 78 86 83 86 France http://www-obs.univ-lyon1.fr/eric.emsellem ===============================================================

2 1

gfortran, ifc, compat-g77
by Nils Wagner March 1, 2006

March 1, 2006

Hi all, It seems to me that installing numpy/scipy on SuSE10.0 is not straightforward in contrast to prior versions. If I remove compat-g77 and try to rebuild numpy from scratch the ifc is used. I thought that gfortran will be used in that case. Am I missing something ? Anyway python setup.py build results in ld: skipping incompatible build/temp.linux-x86_64-2.4/libfblas_src.a when searching for -lfblas_src ld: cannot find -lfblas_src ld: skipping incompatible build/temp.linux-x86_64-2.4/libfblas_src.a when searching for -lfblas_src ld: cannot find -lfblas_src error: Command "/opt2/intel/compiler70/ia32/bin/ifc -shared build/temp.linux-x86_64-2.4/numpy/core/blasdot/_dotblas.o -Lbuild/temp.linux-x86_64-2.4 -lfblas_src -o build/lib.linux-x86_64-2.4/numpy/core/_dotblas.so" failed with exit status 1 Nils Is there someone on the list who has successfully installed numpy/scipy with or without ATLAS using SuSE 10.0 ? http://www.novell.com/products/linuxpackages/professional/compat-g77.html

3 6

New sparse matrix functionality
by Ed Schofield March 1, 2006

March 1, 2006

Hi all, I'd created a new SVN branch with some new functionality and changes to sparse matrices. This post describes what's new and what's different versus the main branch. If you have an existing SVN tree, you can pull in my branch with the command "svn switch http://svn.scipy.org/svn/scipy/branches/ejs". One of the conclusions of Jonathan Guyer's comparison between scipy.sparse and PySparse in November (http://article.gmane.org/gmane.comp.python.scientific.devel/3187/match=scip… and http://old.scipy.org/wikis/featurerequests/SparseSolvers) was that SciPy's support for efficient construction of sparse matrices is weak. My patch adds a new data type, lil_matrix, that stores non-zeros as a list of sorted Python lists. For the simple benchmark of creating a new 10^3 x 10^5 matrix with 10^4 non-zero elements in random locations and converting to CSR and CSC matrices, the lil_matrix format is slightly more than twice as fast as dok_matrix. It's a row-wise format, so conversion to CSR is very fast, whereas conversion to CSC goes through CSR internally. Index lookups use binary searches, so they take log time. I think the implementation is already complete enough for most uses -- so please try it out and tell me how you go! Another of Jonathan's observations was that SciPy had no support for slicing matrices with A[i, :] like in PySparse. My patch adds support for slice notation and NumPy-style fancy indexing to dok_matrix and lil_matrix objects. With this it's possible to build sparse matrices quickly -- for example: >>> a = lil_matrix((3,5)) >>> a[1,[2,3,4]] = range(3) >>> a[2,:] = 3 * a[1,:] A third new feature is a .sum() method, which takes a single axis argument like in NumPy. My branch also changes one aspect of the existing behaviour: the todense() method now returns a dense (NumPy) matrix, rather than a dense array. Converting to a dense array is now available under a toarray() method (or .A attribute) instead. The rationale behind this change is to emphasize that sparse matrices are closer to dense matrices than to dense arrays in their attributes (e.g. .T for transpose) and behaviour (e.g. * means inner product). I've also been careful to make multiplication between sparse matrices and dense row or column vectors (matrix objects with unit length or height) return matrices of the correct dimensions, rather than arrays. Several unit tests relied on the old behaviour, and I've changed these accordingly. Most of these test changes are just simplifications -- for example assert_array_equal((a*c).todense(), a.todense() * c) instead of assert_array_equal((a*c).todense(), dot(a.todense(), c)) -- but I'd appreciate some criticism and feedback on which behaviour people prefer. These changes have highlighted a problem present in both the main trunk and my branch: that multiplying a dense matrix 'a' by a sparse matrix 'b' is not possible using the syntax 'a*b'. I'll follow this up with a proposal to numpy-discussion on how we can solve this. -- Ed

3 6

Modified makefile for gcc 4.x
by Nils Wagner March 1, 2006

March 1, 2006

Hi Hanno, Please can you send me your modified ATLAS makefile. Thanks in advance Nils

1 0