Mailman 3 December 2007 - SciPy-Dev

Re: [SciPy-dev] SLSQP Constrained Optimizer Status
by dmitrey Dec. 19, 2007

Dec. 19, 2007

hi all, Excuse me for repeating this message once again, my 1st one that I had sent yesterday seems to be lost because of scipy.org server down for several hours -------------------------------------------------- Hi Rob, could you check the line 224 (slsqp.py) a = numpy.concatenate( (fprime_cons(x),zeros([la,1])),1) I found the problem is here (lines 163-165): meq = len(eqcons) # meq = The number of equality constraints m = meq + len(ieqcons) # m = The total number of constraints la = array([1,m]).max() # la = So when user pass for example f_eqcons instead of eqcons, there is no appropriate handling of the situation in the code above these lines, so it produces la = 1 and error in concatenate. I'll try to continue checking slsqp connecting it to OpenOpt after you'll inform about fixing the bug, ok? Regards, D.

1 0

tests in sandbox package multigrid
by Nils Wagner Dec. 17, 2007

Dec. 17, 2007

Hi Nathan, nearly all tests of your sandbox package multigrid work for me. Cheers, Nils python -i svn/scipy/scipy/sandbox/multigrid/tests/test_sa.py Found 6/6 tests for __main__ .E.... ====================================================================== ERROR: check_sa_constant_interpolation (__main__.TestSA) ---------------------------------------------------------------------- Traceback (most recent call last): File "svn/scipy/scipy/sandbox/multigrid/tests/test_sa.py", line 63, in check_sa_constant_interpolation S_expected = reference_sa_constant_interpolation(A,epsilon) File "svn/scipy/scipy/sandbox/multigrid/tests/test_sa.py", line 267, in reference_sa_constant_interpolation R = set(range(n)) NameError: global name 'set' is not defined ---------------------------------------------------------------------- Ran 6 tests in 5.965s FAILED (errors=1)

2 1

Trac server error: no space left on device
by Stefan van der Walt Dec. 17, 2007

Dec. 17, 2007

To whom it may concern, The machine on which the trac server is hosted has run out of hard-disk space. OSError: [Errno 28] No space left on device: '/home/scipy/trac/numpy/attachments/ticket/630' Regards Stéfan

1 0

Hanging out in IRC today
by Travis E. Oliphant Dec. 15, 2007

Dec. 15, 2007

We are all hanging out in irc.freenode.net today during the Sprint. The room is scipy. Come join us if you would like to coordinate activity. -Travis O.

2 2

Gmail chat
by Travis E. Oliphant Dec. 14, 2007

Dec. 14, 2007

If anybody wants to join the gmail group chat, send your gmail account information to fernando perez (or me): -Travis O.

1 0

We are sprinting at Berkley
by Travis E. Oliphant Dec. 14, 2007

Dec. 14, 2007

Hey everybody, A group of us (Robert K, Travis O, Fernando P, Jarrod M, Chris, and Tom) are at Berkley today sprinting on SciPy. Hopefully we will be able to make some great progress towards 0.7.0 and some useful clean-up. If anybody would like to join us we are on (and will be in) irc.freenode.net on channel scipy throughout the next 3 days (until Sunday). Come and dive in if you have some time to help (or even if you don't --- make the time ;-) ) Best regards, -Travis O.

1 0

ANN: SFE-00.35.01
by Robert Cimrman Dec. 14, 2007

Dec. 14, 2007

Let me announce SFE-00.35.01, bringing per term integration - now each term can use its own quadrature points. This is a major change at the heart of the code - some parts may not work as all terms were not migrated yet to the new framework. All test examples work, though, as well as acoustic band gaps. See http://ui505p06-mbs.ntc.zcu.cz/sfe . SFE is a finite element analysis software written almost entirely in Python. The code is released under BSD license. best regards, r.

1 0

feedback on scipy.sparse
by Nathan Bell Dec. 14, 2007

Dec. 14, 2007

I wanted to gather some feedback on the state of scipy.sparse and possible changes and improvements. ===== Constructors ===== Here are the current constructors for the various sparse classes: csr_matrix and csc_matrix def __init__(self, arg1, dims=None, dtype=None, copy=False): dok_matrix and lil_matrix def __init__(self, A=None, shape=None, dtype=None, copy=False): coo_matrix def __init__(self, arg1, dims=None, dtype=None): Empty matrices can now be constructed with xxx_matrix( (M,N) ) for all formats. 1) Should we prefer 'dims' over 'shape' or vice versa? IMO 'shape' is arguably more natural since all the types have a .shape attribute 2) It would be nice if xxx_matrix( A ) always worked when A is a sparse or dense matrix. Does anyone object to this? The functionality is already present (though the various .toxxx() methods) 3) When the user defines the dim (or shape) argument but the data violates these bounds, what should happen? IMO this merits an exception, as opposed to expanding the dimensions to accommodate the data. ===== sparse.py and sparse functions ===== sparse.py currently weighs in at nearly 3000 lines and will continue growing. I propose that we move the functions (e.g. spidentity(), spdiags(), spkron(), etc. ) to a separate file. Any comments or proposals for the name of this file? Would it be prudent to move the classes into separate files also? Also, these functions always return a specific sparse format. For example spidentity() always returns a csc_matrix, spkron() always returns a coo_matrix, etc. Currently, a user who wanted the identity matrix in CSR format would have to do a CSC->CSR conversion on the result of spidentity(). This is somewhat wasteful since the spidentity() could easily have generated the CSR format instead. It would be better to allow the user to specify the desired return type in the function call. For example, spidentity(n, dtype='d',format='csr') instead of spidentity(n, dtype='d').tocsr() Sometimes a given function has a very natural return type. For instance, when we have a dia_matrix() implementation (I'm working on one) then spdiags() would naturally use this format. If the user specified another type, spdiags( ..., format='csr') then spdiags() would, at worst, create the matrix in DIA format first and then convert to CSR (with dia_matrix.tocsr() ). I like this approach because it allows the implementation to be clever when cleverness is possible, but also doesn't place an undue burden on the programmer when implementing a new method. Furthermore, it shields the user from internal implementation changes that might change the default return format. I propose the following policy. Functions get a new parameter 'format' which defaults to None. The default implies that the function will return the matrix in whatever format is most natural (and subject to change). For example: spidentity(n, dtype='d',format=None) might return a dia_matrix(), or a special identity matrix format in the future. At a minimum, the valid values of 'format' will include the three-letter abbreviations of the currently supported sparse matrix types (i.e. 'csr', 'csc', 'coo', 'lil', etc). Comments? Also, feel free to respond with any other comments related to scipy.sparse -- Nathan Bell wnbell(a)gmail.com

4 17

conversion among sparse formats
by Nathan Bell Dec. 8, 2007

Dec. 8, 2007

I've added a small benchmark to the scipy.sparse unittests (enabled with level 5) that compares the cost of converting among the various sparse formats. The matrix is 900x900 with approximately 5 nonzeros per row (5-point finite difference stencil). Using the latest SVN, you can produce the table below with the following command: python -c 'from scipy.sparse import test; test(5)' Sparse Matrix Conversion ==================================================================== format | tocsr() | tocsc() | tocoo() | tolil() | todok() -------------------------------------------------------------------- csr | 0.000002 | 0.000292 | 0.000356 | 3.460000 | n/a csc | 0.000312 | 0.000002 | 0.000358 | 3.450000 | n/a coo | 0.000389 | 0.000361 | 0.000002 | 3.460000 | n/a lil | 0.024000 | 0.024000 | 0.022000 | 3.540000 | n/a dok | 0.027500 | 0.060000 | 0.025000 | 3.510000 | n/a The numbers are the time (in seconds) to convert a matrix in format on the left to each of the formats using the to___() methods. Some observations: 1) None of the formats supports todok(). Does anyone want/need this? 2) Something is definitely wrong with tolil() since the reverse conversions (e.g. lil_matrix.tocsr()) are 100x faster. 3) Conversion among CSR/CSC/COO is relatively cheap, so it should be leveraged when going between the 'slow' but flexible formats (lil and dok) and the 'fast' but inflexible formats (csr/csc/coo). Specifically, when converting any 'fast' format to a 'slow' format, you should first convert to the most convenient 'fast' format. Conversely, when converting from a 'slow' to a 'fast' format, using another 'fast' format as an intermediate incurs no noticable overhead. 4) lil_matrix and dok_matrix are the only construction-oriented formats we have, so it's important that they be reasonably quick. -- Nathan Bell wnbell(a)gmail.com

1 2

Scikit for manifold learning techniques
by Matthieu Brucher Dec. 6, 2007

Dec. 6, 2007

Hi, I'd like to create a new scikit (I know I didn't put much effort in the optimizers, but it will change when I will have more time) for manifold learning. At first, I'd like to implement some usual techniques like Isomap, LLE (some are in neuroimaging I heard) with different levels of interaction. I do this in my PhD thesis, so it is almost available like a scikit. It would be a twin-like of the Dimensionality Reduction toolbox for MatLab but with a different interaction : directly call the right global function (like isomap, mds, nlm or gedodesicNLM ATM) or give directly to an optimizer the cost function you want with a distance matrix (it will use my own optimizers). Eigenmaps will be available shortly (I have a referee that want it, so I will implement it), it will use scipy.sparse, and I hope I'll be able to propose two interfaces as well. If everything goes smoothly, I'll propose my own dimensionality reduction technique in the scikit as well. Comments ? Matthieu -- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher

4 7