Mailman 3 October 2008 - SciPy-Dev

Re: [SciPy-dev] [SciPy-user] SciPy Sprint Weekend: 1 and 2 November
by Stéfan van der Walt Oct. 24, 2008

Oct. 24, 2008

2008/10/24 David Warde-Farley <dwf(a)cs.toronto.edu>: > I think you mean 2008? ;) Yes, of course! Event: SciPy Sprint Date: 1, 2 November 2008 Find us on: irc.freenode.net in channel #scipy I hope that all of you can join us. Nathan has put a lot of work into sparse matrices, David has been working on build systems, other David improved special functions, we have a brand new spatial module by Anne, other other David is documenting ndimage, Damian implemented hierarchical clustering and Tiziano is contributing generalised eigenproblems. This is going to be a very useful release -- we must just get it out the door! Cheers Stéfan

1 0

Should scipy 0.7 be compatible with 1.1 serie at all ?
by David Cournapeau Oct. 23, 2008

Oct. 23, 2008

Hi, When building scipy against numpy 1.2.0, there are quite a few deprecation warnings related to recent changes in the C API. Should we update the code for 1.2.0, or shall we keep backward compatibility with 1.1.x serie ? cheers, David

4 6

ANN: Enthought Python Distribution - New Release
by Travis Vaught Oct. 21, 2008

Oct. 21, 2008

Greetings, Enthought, Inc. is very pleased to announce the newest release of the Enthought Python Distribution (EPD) Py2.5 v4.0.30002: http://www.enthought.com/epd This release contains updates to many of EPD's packages, including NumPy, IPython, matplotlib, VTK, etc. This is also the first release to include a 3.x version of the Enthought Tool Suite (http://code.enthought.com/ ). The release notes for this release, including the list of included packages, may be found here: https://svn.enthought.com/epd/wiki/Python2.5.2/4.0.300/GA Many thanks to the EPD team for putting this release together, and to the community of folks who have provided all of the valuable tools bundled here. Best Regards, Travis --------- About EPD --------- The Enthought Python Distribution (EPD) is a "kitchen-sink-included" distribution of the Python™ Programming Language, including over 80 additional tools and libraries. The EPD bundle includes NumPy, SciPy, IPython, 2D and 3D visualization, database adapters, and a lot of other tools right out of the box. http://www.enthought.com/products/epd.php It is currently available as an easy, single-click installer for Windows XP (x86), Mac OS X (a universal binary for Intel 10.4 and above) and RedHat EL3 (x86 and amd64). EPD is free for 30-day trial use and for use in degree-granting academic institutions. An annual Subscription and installation support are available for commercial use (http://www.enthought.com/products/epddownload.php ) including an Enterprise Subscription with support for particular deployment environments (http://www.enthought.com/products/enterprise.php ).

1 0

Re: [SciPy-dev] Genetic Algorithm documentation
by Simone Caschili Oct. 20, 2008

Oct. 20, 2008

Thanks Nil for your answer. I had already found that documentation but I would like to get a tutorial or an official documentation about scipy Genetic Algorithm implementation. Could you recommend any official documentation/tutorial ? Simone > > On Mon, 20 Oct 2008 16:44:38 +0200 > "Simone Caschili" <simon.caschili(a)gmail.com> wrote: >> Hello, >> >> I am thinking to use scipy to implement a genetic >>algorithm project, >> but I have found any documentation about it. >> >> Could you suggest me where I can find it? >> > > http://scipy.org/scipy/scikits/browser/trunk/learn/scikits/learn/machine/ga > > > Nils

1 0

Genetic Algorithm documentation
by Simone Caschili Oct. 20, 2008

Oct. 20, 2008

Hello, I am thinking to use scipy to implement a genetic algorithm project, but I have found any documentation about it. Could you suggest me where I can find it? Thank you very much. Simone

2 1

scipy.sparse.dok_matrix changes
by James Philbin Oct. 20, 2008

Oct. 20, 2008

Hi, I've recently been using dok_matrix a fair bit and have made a few improvements, mainly: i. Improved the docstring. ii. Fixed the constructor (this fixes #755). iii. Reduced the codepath for the common case of setting an individual element (~2x speedup). There's more work to do on dok_matrix, but this patch might be useful for some people: --- Index: scipy/sparse/tests/test_base.py =================================================================== --- scipy/sparse/tests/test_base.py (revision 4801) +++ scipy/sparse/tests/test_base.py (working copy) @@ -1162,8 +1162,27 @@ except: caught += 1 assert_equal(caught,5) + + def test_ctor(self): + caught = 0 + # Empty ctor + try: + A = dok_matrix() + except TypeError, e: + caught+=1 + assert_equal(caught, 1) + + # Dense ctor + b = matrix([[1,0,0,0],[0,0,1,0],[0,2,0,3]],'d') + A = dok_matrix(b) + assert_equal(A.todense(), b) + # Sparse ctor + c = csr_matrix(b) + assert_equal(A.todense(), c.todense()) + + class TestLIL( _TestCommon, _TestHorizSlicing, _TestVertSlicing, _TestBothSlicing, _TestGetSet, _TestSolve, _TestArithmetic, _TestInplaceArithmetic, Index: scipy/sparse/dok.py =================================================================== --- scipy/sparse/dok.py (revision 4801) +++ scipy/sparse/dok.py (working copy) @@ -14,45 +14,65 @@ class dok_matrix(spmatrix, dict): """Dictionary Of Keys based matrix. This is an efficient - structure for constructing sparse matrices + structure for constructing sparse matrices incrementally. + + This can be instatiated in several ways: + dok_matrix(D) + with a dense matrix, D + + dok_matrix(S) + with a sparse matrix, S + + dok_matrix((M,N), [dtype]) + create the matrix with initial shape (M,N) + dtype is optional, defaulting to dtype='d' + + Notes + ----- + Allows for efficient O(1) access of individual elements. + Duplicates are not allowed. + Can be efficiently converted to a coo_matrix once constructed. + + Examples + -------- + >>> from scipy.sparse import * + >>> from scipy import * + >>> S = dok_matrix((5,5), dtype=float32) + >>> for i in range(5): + >>> for j in range(5): + >>> S[i,j] = i+j # Update element + """ - def __init__(self, A=None, shape=None, dtype=None, copy=False): - """ Create a new dictionary-of-keys sparse matrix. An optional - argument A is accepted, which initializes the dok_matrix with it. - This can be a tuple of dimensions (M, N) or a (dense) array - to copy. - """ - #TODO deprecate argument A in favor of arg1 style - + + def __init__(self, arg1, shape=None, dtype=None, copy=False): dict.__init__(self) spmatrix.__init__(self) - self.dtype = getdtype(dtype, A, default=float) - if A is not None: - if isinstance(A, tuple): - # Interpret as dimensions - if not isshape(A): - raise TypeError, "dimensions must be a 2-tuple of positive"\ - " integers" - self.shape = A - elif isspmatrix(A): - if isspmatrix_dok(A) and copy: - A = A.copy() - else: - A = A.todok() - self.update( A ) - self.shape = A.shape - self.dtype = A.dtype + + self.dtype = getdtype(dtype, default=float) + if isinstance(arg1, tuple) and isshape(arg1): # (M,N) + M, N = arg1 + self.shape = (M, N) + elif isspmatrix(arg1): # Sparse ctor + if isspmatrix_dok(arg1) and copy: + arg1 = arg1.copy() else: - #must be dense, convert to COO first, then to DOK - try: - A = asarray(A) - except: - raise ValueError, "unrecognized form for" \ - " %s_matrix constructor" % self.format - from coo import coo_matrix - self.update( coo_matrix(A).todok() ) - self.shape = A.shape - self.dtype = A.dtype + arg1 = arg1.todok() + self.update(arg1) + self.shape = arg1.shape + self.dtype = arg1.dtype + else: # Dense ctor + try: + arg1 = asarray(arg1) + except: + raise TypeError('invalid input format') + + if len(arg1.shape)!=2: + raise TypeError('expected rank <=2 dense array or matrix') + + from coo import coo_matrix + self.update( coo_matrix(arg1).todok() ) + self.shape = arg1.shape + self.dtype = arg1.dtype def getnnz(self): return dict.__len__(self) @@ -90,7 +110,7 @@ # Bounds checking if isintlike(i): - if i < 0: + if i < 0: i += self.shape[0] if i < 0 or i >= self.shape[0]: raise IndexError, "index out of bounds" @@ -177,13 +197,10 @@ def __setitem__(self, key, value): try: - assert len(key) == 2 - except (AssertionError, TypeError): - raise TypeError, "index must be a pair of integers, slices, or" \ - " sequences" - i, j = key + i, j = key + except (ValueError, TypeError): + raise TypeError, "index must be a pair of integers or slices" - # First deal with the case where both i and j are integers if isintlike(i) and isintlike(j): if i < 0: @@ -193,20 +210,14 @@ if i < 0 or i >= self.shape[0] or j < 0 or j >= self.shape[1]: raise IndexError, "index out of bounds" - if isintlike(value) and value == 0: - if key in self.keys(): # get rid of it something already there - del self[key] + + if isscalar(value): + if value==0: + del self[(i,j)] + else: + dict.__setitem__(self, (i,j), self.dtype.type(value)) else: - # Ensure value is a single element, not a sequence - if isinstance(value, float) or isintlike(value) or \ - isinstance(value, complex): - dict.__setitem__(self, (i,j), self.dtype.type(value)) - newrows = max(self.shape[0], int(key[0])+1) - newcols = max(self.shape[1], int(key[1])+1) - self.shape = (newrows, newcols) - else: - raise TypeError, "cannot set matrix element to non-scalar" - return # done + raise TypeError, "cannot set matrix element to a non-scalar" else: # Either i or j is a slice, sequence, or invalid. If i is a slice # or sequence, unfold it first and call __setitem__ recursively. --- Thanks, James

2 3

parameter control in scipy.optimize.leastsq
by Maximilian Fabricius Oct. 20, 2008

Oct. 20, 2008

Hello, I have been using scipy for about one and a half years now and have been extremely pleased. In this time I have made extensive use of scipy.optimize.leastsq. While I am generally fairly happy with its performance, I think it does lacks one important feature which I am used to from similar routines in other languages. (Please excuse if I have just missed that feature so far.) I would like to be able to control which parameters actually are fitted. For example I would like to be able to do leastsq( redsiduals, p0, args=(y), fit=([True,True,False,True]) ) where the parameter "fit" would tell leastsq to leave the parameter p0[2] untouched while fitting the others. Right now I have to modify my source code to change the parameters which are actually fit. I'd be happy to participate and start getting my hands dirty if someone would point out where to start. Regards, Maximilian

3 7

ANNOUNCE: EPD with Py2.5 version 4.0.30002 RC2 available for testing
by Dave Peterson Oct. 17, 2008

Oct. 17, 2008

Hello, We've recently posted the RC2 build of EPD (the Enthought Python Distribution) with Python 2.5 version 4.0.30002 to the EPD website. You may download the RC from here: http://www.enthought.com/products/epdbeta.php You can check out the release notes here: https://svn.enthought.com/epd/wiki/Python2.5.2/4.0.300/RC2 Please help us test it out and provide feedback on the EPD Trac instance: https://svn.enthought.com/epd or via e-mail to epd-support(a)enthought.com. If everything goes well, we are planning a final release for this coming Tuesday, October 21st. About EPD --------- The Enthought Python Distribution (EPD) is a "kitchen-sink-included" distribution of the Python™ Programming Language, including over 60 additional tools and libraries. The EPD bundle includes NumPy, SciPy, IPython, 2D and 3D visualization, database adapters, and a lot of other tools right out of the box. http://www.enthought.com/products/epd.php It is currently available as a single-click installer for Windows XP (x86), Mac OS X (a universal binary for OS X 10.4 and above), and RedHat 3 and 4 (x86 and amd64). EPD is free for academic use. An annual subscription and installation support are available for individual commercial use. An enterprise subscription with support for particular deployment environments is also available for commercial purchase. -- Dave

1 0

Re: [SciPy-dev] [Numpy-discussion] Proposal: scipy.spatial
by Anne Archibald Oct. 12, 2008

Oct. 12, 2008

2008/9/30 Peter <numpy-discussion(a)maubp.freeserve.co.uk>: > On Tue, Sep 30, 2008 at 5:10 AM, Christopher Barker > <Chris.Barker(a)noaa.gov> wrote: >> >> Anne Archibald wrote: >>> I suggest the creation of >>> a new submodule of scipy, scipy.spatial, >> >> +1 >> >> Here's one to consider: >> http://pypi.python.org/pypi/Rtree >> and perhaps other stuff from: >> http://trac.gispython.org/spatialindex/wiki >> which I think is LGPL -- can scipy use that? > > There is also a KDTree module in Biopython (which is under a BSD/MIT > style licence), > http://biopython.org/SRC/biopython/Bio/KDTree/ > > The current version is in C, there is an older version available in > the CVS history in C++ too, > http://cvs.biopython.org/cgi-bin/viewcvs/viewcvs.cgi/biopython/Bio/KDTree/?… I think the profusion of different implementations is an argument for including this in scipy. I think it is also an argument for providing a standard interface with (at least potentially) several different implementations. At the moment, that proposed interface looks like: T = KDTree(data) distances, indices = T.query(xs) # single nearest neighbor distances, indices = T.query(xs, k=10) # ten nearest neighbors distances, indices = T.query(xs, k=None, distance_upper_bound=1.0) # all within 1 of x In the first two cases, missing neighbors are represented with an infinite distance and an invalid index. In the last case, distances and indices are both either lists (if there's only one query point) or object arrays of lists (if there are many query points). If only one neighbor is requested, the array does not have a dimension of length 1 in the which-neighbor position. If (potentially) many neighbors are returned, they are sorted by distance, nearest first. What do you think of this interface? It may make sense to provide additional kinds of query - nearest neighbors between two trees, for example - some of which would be available only for some implementations. Anne

4 14

cython in scipy?
by Anne Archibald Oct. 11, 2008

Oct. 11, 2008

Hi, I've just been trying to clean up scipy.stats.vonmises.cdf: it's currently badly broken (tickets 747, 748, and 749). I can fix the outright bugs, but it also has distressingly large roundoff error under some circumstances. I'd like to simply implement the standard algorithm (Hill 1977) for evaluating it. Unfortunately, it involves evaluating a series with a number of terms that depends on the parameter, so vectorizing a python version (which is already written) is going to be a nuisance. On the other hand, it would be very easy to translate this into cython and get C performance out of it. So: is it okay to include cython code in scipy? What is the best way to go about this? Include the cython source in setup.py somehow? Check the generated C into svn and run cython by hand when I remember to? Thanks, Anne

8 15