Mailman 3 June 2012 - SciPy-Dev

SLSQP Constrained Optimizer Status
by Rob Falck 25 Nov '13

25 Nov '13

I'm currently implementing the Sequential Least Squares Quadratic Programming (SLSQP) optimizer, by Dieter Kraft, for use in Scipy. The Fortran code being wrapped with F2PY is here: http://www.netlib.org/toms/733 (its use within Scipy has been cleared) SLSQP provides for bounds on the independent variables, as well as equality and inequality constraint functions, which is a capability that doesn't exist in scipy.optimize. Currently the code works, although the constraint normals are being generated by approximation. I'm working on a way to pass these in. I think the most elegant way will be a single function that returns the matrix of constraint normals. For a demonstration of what the code can do, here is an optimization of f(x,y) = 2xy + 2x - x**2 - 2y**2 Example 14.2 in Chapra & Canale gives the maximum as x=2.0, y=1.0. The unbounded optimization tests find this solution. As expected, its faster when derivatives are provided rather than approximated. Unbounded optimization. Derivatives approximated. Elapsed time: 1.45792961121 ms Results [[1.9999999515712266, 0.99999996181577444], -1.9999999999999984, 4, 0, 'Optimization terminated successfully.'] Unbounded optimization. Derivatives provided. Elapsed time: 1.03211402893 ms Results [[1.9999999515712266, 0.99999996181577444], -1.9999999999999984, 4, 0, 'Optimization terminated successfully.'] The following example uses an equality constraint to find the optimal when x=y. Bound optimization. Derivatives approximated. Elapsed time: 1.384973526 ms Results [[0.99999996845920858, 0.99999996845920858], -0.99999999999999889, 4, 0, 'Optimization terminated successfully.'] I've tried to conform to the syntax used by the other optimizers in scipy.optimize. The function definition and doc string are below. If anyone is interested in testing it out, let me know. def fmin_slsqp( func, x0 , eqcons=[], f_eqcons=None, ieqcons=[], f_ieqcons=None, bounds = [], fprime = None, fprime_cons=None,args = (), iter = 100, acc = 1.0E-6, iprint = 1, full_output = 0, epsilon = _epsilon ): """ Minimize a function using Sequential Least SQuares Programming Description: Python interface function for the SLSQP Optimization subroutine originally implemented by Dieter Kraft. Inputs: func - Objective function (in the form func(x, *args)) x0 - Initial guess for the independent variable(s). eqcons - A list of functions of length n such that eqcons[j](x0,*args) == 0.0 in a successfully optimized problem f_eqcons - A function of the form f_eqcons(x, *args) that returns an array in which each element must equal 0.0 in a successfully optimized problem. If f_eqcons is specified, eqcons is ignored. ieqcons - A list of functions of length n such that ieqcons[j](x0,*args) >= 0.0 in a successfully optimized problem f_ieqcons - A function of the form f_ieqcons(x0, *args) that returns an array in which each element must be greater or equal to 0.0 in a successfully optimized problem. If f_ieqcons is specified, ieqcons is ignored. bounds - A list of tuples specifying the lower and upper bound for each independent variable [ (xl0, xu0), (xl1, xu1), ...] fprime - A function that evaluates the partial derivatives of func fprime_cons - A function of the form f(x, *args) that returns the m by n array of constraint normals. If not provided, the normals will be approximated. Equality constraint normals precede inequality constraint normals. args - A sequence of additional arguments passed to func and fprime iter - The maximum number of iterations (int) acc - Requested accuracy (float) iprint - The verbosity of fmin_slsqp. iprint <= 0 : Silent operation iprint == 1 : Print summary upon completion (default) iprint >= 2 : Print status of each iterate and summary full_output - If 0, return only the minimizer of func (default). Otherwise, output final objective function and summary information. epsilon - The step size for finite-difference derivative estimates. Outputs: ( x, { fx, gnorm, its, imode, smode }) x - The final minimizer of func. fx - The final value of the objective function. its - The number of iterations. imode - The exit mode from the optimizer, as an integer. smode - A string describing the exit mode from the optimizer. Exit modes are defined as follows: -1 : Gradient evaluation required (g & a) 0 : Optimization terminated successfully. 1 : Function evaluation required (f & c) 2 : Number of equality constraints larger than number of independent variables 3 : More than 3*n iterations in LSQ subproblem 4 : Inequality constraints incompatible 5 : Singular matrix E in LSQ subproblem 6 : Singular matrix C in LSQ subproblem 7 : Rank-deficient equality constraint subproblem HFTI 8 : Positive directional derivative for linesearch 9 : Iteration limit exceeded -- - Rob Falck

4 16

interp2d bounds checking
by Pierre Haessig 07 Jul '12

07 Jul '12

Hi, I just have a small question about scipy.interpolate.interp2d I noticed that bounds checking when calling the interpolation instance seems to be ineffective. I found a ticket about this issue, but not much activity around it. http://projects.scipy.org/scipy/ticket/1072 I looked at the code and at the documentation ( http://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.inter… https://raw.github.com/scipy/scipy/master/scipy/interpolate/interpolate.py ) and it seems that the `bounds_error` argument is never used in the initialization of the interp2d object (unlike inter1d). I'm not at all a specialist of 2D interpolation but I guess that bounds checking in 2D is not as easy as in 1D... Maybe, if there is no easy way to check bounds in interp2d, we should just add a "big warning" in the docstring stating that `bounds_error` is not currently used (and therefore `fill_value` as well). What do you think ? Best, Pierre about docstring editing, I didn't find the "Edit page" link on interp2d page. Did I miss something ?

4 5

Equidistant Sphere Points
by Arvind Rao 29 Jun '12

29 Jun '12

Hi All, For model fitting and numerical integration, I have developed a routine that generates N equidistant points on the sphere, by way of an intrinsic gradient flow. Now, I would like to port it over to python. Would there be interest in adding such a function to SciPy? Sincerely, -- *Arvind S. Rao, PhD* Section of Biomedical Image Analysis Department of Radiology University of Pennsylvania 3600 Market Street, Suite 380 Philadelphia, PA 19104

2 1

scipy.signal.normalize problems?
by Josh Lawrence 29 Jun '12

29 Jun '12

Hey all, I've been having some problems designing a Chebyshev filter and I think I have narrowed down the hang-up to scipy.signal.normalize. I think what's going on in my case is that line 286 of filter_design.py (the first allclose call in the normalize function) is producing a false positive. Here's the function definition: def normalize(b, a): """Normalize polynomial representation of a transfer function. If values of b are too close to 0, they are removed. In that case, a BadCoefficients warning is emitted. """ b, a = map(atleast_1d, (b, a)) if len(a.shape) != 1: raise ValueError("Denominator polynomial must be rank-1 array.") if len(b.shape) > 2: raise ValueError("Numerator polynomial must be rank-1 or" " rank-2 array.") if len(b.shape) == 1: b = asarray([b], b.dtype.char) while a[0] == 0.0 and len(a) > 1: a = a[1:] outb = b * (1.0) / a[0] outa = a * (1.0) / a[0] if allclose(outb[:, 0], 0, rtol=1e-14): <------------------ Line 286 warnings.warn("Badly conditioned filter coefficients (numerator): the " "results may be meaningless", BadCoefficients) while allclose(outb[:, 0], 0, rtol=1e-14) and (outb.shape[-1] > 1): outb = outb[:, 1:] if outb.shape[0] == 1: outb = outb[0] return outb, outa I marked line 286. If I reproduce all the steps carried out by scipy.signal.iirdesign, I end up with a (b, a) pair which results of scipy.signal.lp2lp and looks like this: In [106]: b_lp2 Out[106]: array([ 1.55431359e-06+0.j]) In [107]: a_lp2 Out[107]: array([ 1.00000000e+00 +0.00000000e+00j, 3.46306104e-01 -2.01282794e-16j, 2.42572185e-01 -6.08207573e-17j, 5.92946943e-02 +0.00000000e+00j, 1.82069156e-02 +5.55318531e-18j, 2.89328123e-03 +0.00000000e+00j, 4.36566281e-04 -2.95766719e-19j, 3.50842810e-05 -3.19180568e-20j, 1.64641246e-06 -1.00966301e-21j]) scipy.signal.iirdesign takes b_lp2, a_lp2 (my local variable names to keep track of what's going on) and runs them through scipy.signal.bilinear (in filter_design.py bilinear is called on line 624 within iirfilter. iirdesign calls iirfilter which calls bilinear). Inside bilinear, normalize is called on line 445. I've made my own class with bilinear copied and pasted from filter_design.py to test things. In bilinear, the input to normalize is given by b = [ 1.55431359e-06 1.24345087e-05 4.35207804e-05 8.70415608e-05 1.08801951e-04 8.70415608e-05 4.35207804e-05 1.24345087e-05 1.55431359e-06] a = [ 72269.02590913 -562426.61430468 1918276.19173089 -3745112.83646825 4577612.13937628 -3586970.61385926 1759651.18184723 -494097.93515708 60799.46134722] In normalize, right before the allclose() call, outb is defined by outb = [[ 2.15073272e-11 1.72058618e-10 6.02205162e-10 1.20441032e-09 1.50551290e-09 1.20441032e-09 6.02205162e-10 1.72058618e-10 2.15073272e-11]] From what I read of the function normalize, it should only evaluate true if all of the coefficients in outb are smaller than 1e-14. However, that's not what is going on. I have access to MATLAB and if I go through the same design criteria to design a chebyshev filter, I get the following: b = 1.0e-08 * Columns 1 through 5 0.002150733144728 0.017205865157826 0.060220528052392 0.120441056104784 0.150551320130980 Columns 6 through 9 0.120441056104784 0.060220528052392 0.017205865157826 0.002150733144728 which matches up rather well for several significant figures. I apologize if this is not clearly explained, but I'm not sure what to do. I tried messing around with the arguments to allclose (switching it to be allclose(0, outb[:,0], ...), or changing the keyword from rtol to atol). I am also not sure why normalize is setup to run on rank-2 arrays. I looked through filter_design.py and none of the functions contained in it send a rank-2 array to normalize from what I can tell. Any thoughts? Cheers, Josh Lawrence

2 8

UnivariateSpline evaluated on a ND array
by Pierre Haessig 27 Jun '12

27 Jun '12

Hi, While playing a bit with UnivariateSpline... >>> from scipy.interpolate import UnivariateSpline >>> s = UnivariateSpline([0,1], [0,1],k=1) ...I noticed that the evaluation fails if the input is not flat: Fine with 1D input : >>> s(np.linspace(0,1,100)) array([ 0. , 0.11111111, 0.22222222, 0.33333333, 0.44444444, 0.55555556, 0.66666667, 0.77777778, 0.88888889, 1. ]) but fails with 2D input : >>> s(np.linspace(0,1,10).reshape(5,2)) [...] /usr/lib/python2.7/dist-packages/scipy/interpolate/fitpack.pyc in splev(x, tck, der, ext) [...] --> 548 y, ier =_fitpack._spl_(x, der, t, c, k, ext) [...] ValueError: object too deep for desired array Do you think it would be a good move to add *inside* the UnivariateSpline.__call__ method a small machinery which performs the "flatten -> spline eval -> unflatten" operation ? On the other hand, the Docstring of scipy.interpolate.splev which called within UnivariateSpline states explicately that input should be 1D. If this limitation should be propagated to UnivariateSpline, then it should be clarified in the Docstring of UnivariateSpline.__call__ (https://github.com/scipy/scipy/blob/master/scipy/interpolate/fitpack2.py#L2… if I'm right) What do you think is the best solution ? Best, Pierre

2 1

Adding new wrappers (dassl, daspk version 2, cvode version 2.7.0) to scipy.integrate?
by Geoff Oxberry 22 Jun '12

22 Jun '12

I posted a feature request ticket (#1678, http://projects.scipy.org/scipy/ticket/1678) about this on the SciPy Dev Wiki, and Ralf Gommers suggested that I follow up on the scipy-dev mailing list. To recap the gist of my ticket, there are problems for which DVODE (currently wrapped in scipy.integrate.ode) are inadequate, such as in computational combustion. It would be helpful to researchers in combustion to wrap updated numerical integration libraries (such as DASSL, DASPK, and CVODE); DAE solver wrappers would also be very helpful (technically, DASSL and DASPK are DAE solvers, but one thing at a time here). Since some of these wrappers already exist in scikits.odes, would it be possible to merge them into scipy.integrate.ode? If so, in the process, could the Sundials wrappers also be updated to operate with Sundials version 2.5.0 instead of Sundials version 2.4.0? The newest version of Sundials contains only minor changes to the API (a few integer arguments are changed to long integers to accommodate larger problem sizes), and several bugs are fixed. There have been many e-mails on the Sundials-users mailing list requesting a good, well-maintained and supported Python interface to Sundials with a reputable institution behind it. It looks like scikits.odes is the best-maintained Python interface out there, since pysundials and python-sundials are no longer maintained, and the Assimulo documentation uses some nomenclature that is nonstandard in numerical analysis (which makes me doubt the software). Furthermore, I know that users in the combustion community, frustrated with this situation, have implemented their own wrappers to such solvers (see for instance, https://github.com/jwallen/PyDAS, written by a colleague of mine). I am willing to help with this effort after I graduate (I am in the process of finishing my PhD) in a few months. Geoff

4 4

Adding new wrappers (dassl, daspk version 2, cvode version 2.7.0) to scipy.integrate?
by Geoff Oxberry 20 Jun '12

20 Jun '12

Claus, What made me skittish about the API documentation of Assimulo is when you describe the CVODE in the "Documentation contents" page of your documentation (http://www.jmodelica.org/assimulo) as an "explicit solver". That, to me, seemed "non-standard". After an initial moment of confusion, I realized that you were instead talking about explicit ordinary differential equations, not explicit methods for integrating ODEs. (I believe my comments on the Trac Ticket reflect this.) As someone who's seen enough software thrown out there by people who either don't maintain it, or don't document it, I get very skeptical when I see something that looks out of place in documentation. Anyone who jumps to the Assimulo home page will immediately realize the distinction you're making; I just happened to type in "assimulo documentation" because I had already been recommended the package by a user on Computational Science Stack Exchange (of which I am a moderator). When I downloaded your project to compile the Trac ticket report, I did notice that your project is among the more actively maintained wrappers of Sundials out there, and receiving an e-mail from you is a pleasant surprise. I also appreciate that your project has documentation. Of the six wrappers to Sundials or DASSL that I know of out there, Assimulo looks like it's the best documented. Recently, I attempted to integrate a stiff system of ODEs derived from the GRI-Mech 3.0 combustion chemistry model with DVODE, varying the absolute tolerances from 1e-9 to 1e-20 and the relative tolerances from 1e-6 to 1e-15. For whatever reason, I don't obtain the expected solution behavior, but I do obtain the expected solution behavior with the MATLAB wrapper to CVODE, and I also obtain this behavior with a modified version of DASSL (that simulation was programmed in Fortran 90). Perhaps I should give Assimulo's wrapper a try, especially since I've found that IDA tends to work well on my problems also. That said, I still believe that DVODE in scipy.integrate should be supplemented (or even replaced) by CVODE. DVODE has had a long history of successful use in combustion chemistry, but CVODE, DASSL, DASPK, and IDA seem to have superior stepping heuristics for these sorts of problems, based on my 5 or so years of experience working on them. Thank you for your response, Geoff

2 2

ANN: SciPy 0.11.0 beta 1 released
by Ralf Gommers 14 Jun '12

14 Jun '12

Hi, I am pleased to announce the availability of the first beta release of SciPy0.11.0. For this release over 120 tickets and pull requests have been closed, and many new features have been added. Also noteworthy is that the number of contributors for this release has risen to over 50. Some of the highlights are: - A new module, sparse.csgraph, has been added which provides a number of common sparse graph algorithms. - New unified interfaces to the existing optimization and root finding functions have been added. Sources and binaries can be found at http://sourceforge.net/projects/scipy/files/scipy/0.11.0b1/, release notes are copied below. Please try this release and report any problems on the mailing list. Cheers, Ralf ========================== SciPy 0.11.0 Release Notes ========================== .. note:: Scipy 0.11.0 is not released yet! .. contents:: SciPy 0.11.0 is the culmination of 8 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. Highlights of this release are: - A new module has been added which provides a number of common sparse graph algorithms. - New unified interfaces to the existing optimization and root finding functions have been added. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Our development attention will now shift to bug-fix releases on the 0.11.x branch, and on adding new features on the master branch. This release requires Python 2.4-2.7 or 3.1-3.2 and NumPy 1.5.1 or greater. New features ============ Sparse Graph Submodule ---------------------- The new submodule :mod:`scipy.sparse.csgraph` implements a number of efficient graph algorithms for graphs stored as sparse adjacency matrices. Available routines are: - :func:`connected_components` - determine connected components of a graph - :func:`laplacian` - compute the laplacian of a graph - :func:`shortest_path` - compute the shortest path between points on a positive graph - :func:`dijkstra` - use Dijkstra's algorithm for shortest path - :func:`floyd_warshall` - use the Floyd-Warshall algorithm for shortest path - :func:`breadth_first_order` - compute a breadth-first order of nodes - :func:`depth_first_order` - compute a depth-first order of nodes - :func:`breadth_first_tree` - construct the breadth-first tree from a given node - :func:`depth_first_tree` - construct a depth-first tree from a given node - :func:`minimum_spanning_tree` - construct the minimum spanning tree of a graph ``scipy.optimize`` improvements ------------------------------- The optimize module has received a lot of attention this release. In addition to added tests, documentation improvements, bug fixes and code clean-up, the following improvements were made: - A unified interface to minimizers of univariate and multivariate functions has been added. - A unified interface to root finding algorithms for multivariate functions has been added. - The L-BFGS-B algorithm has been updated to version 3.0. Unified interfaces to minimizers ```````````````````````````````` Two new functions ``scipy.optimize.minimize`` and ``scipy.optimize.minimize_scalar`` were added to provide a common interface to minimizers of multivariate and univariate functions respectively. For multivariate functions, ``scipy.optimize.minimize`` provides an interface to methods for unconstrained optimization (`fmin`, `fmin_powell`, `fmin_cg`, `fmin_ncg`, `fmin_bfgs` and `anneal`) or constrained optimization (`fmin_l_bfgs_b`, `fmin_tnc`, `fmin_cobyla` and `fmin_slsqp`). For univariate functions, ``scipy.optimize.minimize_scalar`` provides an interface to methods for unconstrained and bounded optimization (`brent`, `golden`, `fminbound`). This allows for easier comparing and switching between solvers. Unified interface to root finding algorithms ```````````````````````````````````````````` The new function ``scipy.optimize.root`` provides a common interface to root finding algorithms for multivariate functions, embeding `fsolve`, `leastsq` and `nonlin` solvers. ``scipy.linalg`` improvements ----------------------------- New matrix equation solvers ``````````````````````````` Solvers for the Sylvester equation (``scipy.linalg.solve_sylvester``, discrete and continuous Lyapunov equations (``scipy.linalg.solve_lyapunov``, ``scipy.linalg.solve_discrete_lyapunov``) and discrete and continuous algebraic Riccati equations (``scipy.linalg.solve_continuous_are``, ``scipy.linalg.solve_discrete_are``) have been added to ``scipy.linalg``. These solvers are often used in the field of linear control theory. QZ and QR Decomposition ```````````````````````` It is now possible to calculate the QZ, or Generalized Schur, decomposition using ``scipy.linalg.qz``. This function wraps the LAPACK routines sgges, dgges, cgges, and zgges. The function ``scipy.linalg.qr_multiply``, which allows efficient computation of the matrix product of Q (from a QR decompostion) and a vector, has been added. Pascal matrices ``````````````` A function for creating Pascal matrices, ``scipy.linalg.pascal``, was added. Sparse matrix construction and operations ----------------------------------------- Two new functions, ``scipy.sparse.diags`` and ``scipy.sparse.block_diag``, were added to easily construct diagonal and block-diagonal sparse matrices respectively. ``scipy.sparse.csc_matrix`` and ``csr_matrix`` now support the operations ``sin``, ``tan``, ``arcsin``, ``arctan``, ``sinh``, ``tanh``, ``arcsinh``, ``arctanh``, ``rint``, ``sign``, ``expm1``, ``log1p``, ``deg2rad``, ``rad2deg``, ``floor``, ``ceil`` and ``trunc``. Previously, these operations had to be performed by operating on the matrices' ``data`` attribute. LSMR iterative solver --------------------- LSMR, an iterative method for solving (sparse) linear and linear least-squares systems, was added as ``scipy.sparse.linalg.lsmr``. Discrete Sine Transform ----------------------- Bindings for the discrete sine transform functions have been added to ``scipy.fftpack``. ``scipy.interpolate`` improvements ---------------------------------- For interpolation in spherical coordinates, the three classes ``scipy.interpolate.SmoothSphereBivariateSpline``, ``scipy.interpolate.LSQSphereBivariateSpline``, and ``scipy.interpolate.RectSphereBivariateSpline`` have been added. Binned statistics (``scipy.stats``) ----------------------------------- The stats module has gained functions to do binned statistics, which are a generalization of histograms, in 1-D, 2-D and multiple dimensions: ``scipy.stats.binned_statistic``, ``scipy.stats.binned_statistic_2d`` and ``scipy.stats.binned_statistic_dd``. Deprecated features =================== ``scipy.sparse.cs_graph_components`` has been made a part of the sparse graph submodule, and renamed to ``scipy.sparse.csgraph.connected_components``. Calling the former routine will result in a deprecation warning. ``scipy.misc.radon`` has been deprecated. A more full-featured radon transform can be found in scikits-image. ``scipy.io.save_as_module`` has been deprecated. A better way to save multiple Numpy arrays is the ``numpy.savez`` function. The `xa` and `xb` parameters for all distributions in ``scipy.stats.distributions`` already weren't used; they have now been deprecated. Backwards incompatible changes ============================== Removal of ``scipy.maxentropy`` ------------------------------- The ``scipy.maxentropy`` module, which was deprecated in the 0.10.0 release, has been removed. Logistic regression in scikits.learn is a good and modern alternative for this functionality. alternative for this functionality. Minor change in behavior of ``splev`` ------------------------------------- The spline evaluation function now behaves similarly to ``interp1d`` for size-1 arrays. Previous behavior:: >>> from scipy.interpolate import splev, splrep, interp1d >>> x = [1,2,3,4,5] >>> y = [4,5,6,7,8] >>> tck = splrep(x, y) >>> splev([1], tck) 4. >>> splev(1, tck) 4. Corrected behavior:: >>> splev([1], tck) array([ 4.]) >>> splev(1, tck) array(4.) This affects also the ``UnivariateSpline`` classes. Behavior of ``scipy.integrate.complex_ode`` ------------------------------------------- The behavior of the ``y`` attribute of ``complex_ode`` is changed. Previously, it expressed the complex-valued solution in the form:: z = ode.y[::2] + 1j * ode.y[1::2] Now, it is directly the complex-valued solution:: z = ode.y Minor change in behavior of T-tests ----------------------------------- The T-tests ``scipy.stats.ttest_ind``, ``scipy.stats.ttest_rel`` and ``scipy.stats.ttest_1samp`` have been changed so that 0 / 0 now returns NaN instead of 1. Other changes ============= The SuperLU sources in ``scipy.sparse.linalg`` have been updated to version 4.3 from upstream. The function ``scipy.signal.bode``, which calculates magnitude and phase data for a continuous-time system, has been added. The two-sample T-test ``scipy.stats.ttest_ind`` gained an option to compare samples with unequal variances, i.e. Welch's T-test. ``scipy.misc.logsumexp`` now takes an optional ``axis`` keyword argument. Authors ======= This release contains work by the following people (contributed at least one patch to this release, names in alphabetical order): * Jeff Armstrong * Chad Baker * Brandon Beacher + * behrisch + * borishim + * Matthew Brett * Lars Buitinck * Luis Pedro Coelho + * Johann Cohen-Tanugi * David Cournapeau * dougal + * Ali Ebrahim + * endolith + * Bjørn Forsman + * Robert Gantner + * Sebastian Gassner + * Christoph Gohlke * Ralf Gommers * Yaroslav Halchenko * Charles Harris * Jonathan Helmus + * Andreas Hilboll + * Marc Honnorat + * Jonathan Hunt + * Maxim Ivanov + * Thouis (Ray) Jones * Christopher Kuster + * Denis Laxalde + * Travis Oliphant * Joonas Paalasmaa + * Fabian Pedregosa * Josef Perktold * Gavin Price + * Jim Radford + * Andrew Schein + * Skipper Seabold * Jacob Silterra + * Scott Sinclair * Alexis Tabary + * Martin Teichmann * Matt Terry + * Nicky van Foreest + * Jacob Vanderplas * Patrick Varilly + * Pauli Virtanen * Nils Wagner + * Darryl Wally + * Stefan van der Walt * Liming Wang + * David Warde-Farley + * Warren Weckesser * Sebastian Werk + * Mike Wimmer + * Tony S Yu + A total of 54 people contributed to this release. People with a "+" by their names contributed a patch for the first time.

2 1

Fwd: Software paper invitation (Swift UVOT grism Python software)
by Paul Kuin 13 Jun '12

13 Jun '12

Hi All, I was thinking that this email invitation I got for publishing about (my) software might be of interest to some of you also (for other stuff of course & Depending on what you develop & whether it is of interest to the 'research community'). Paul ---------- Forwarded message ---------- From: Brian Hole <brian.hole(a)ubiquitypress.com> Date: Tue, Jun 12, 2012 at 11:36 AM Subject: Software paper invitation (Swift UVOT grism Python software) Dear Dr Kuin, I’m writing to you in connection with the Swift UVOT grism Python software you have ... We believe that this is important software of great use to the research community, and we would like to offer you a method of increasing its reuse and impact. Ubiquity Press (http://www.ubiquitypress.com/) is a researcher-led open access publisher based on the UCL campus, and we are in the process of launching a journal with the Software Sustainability Institute (http://www.software.ac.uk), called the Journal of Open Research Software (http://openresearchsoftware.metajnl.com). We would like to offer you the opportunity of contributing a software paper about the above software to the journal. Software papers are short descriptions of the software, which detail the methodology with which it was produced, link to its location in an archive, and very importantly, detail its reuse potential. The aim of the paper is to make other researchers aware of the software and encourage its reuse, and provide the creators of the software with a way to gain recognition for its production. The papers are of course citable, and we will track these citations as with any other article type so that you can see who is using the software and what kind of impact it is having. All software papers are peer reviewed, and require that the software itself be available in a repository such as UCL Discovery that can guarantee its long-term preservation and availability. Please let us know if you are interested in contributing a paper, or if you have any questions. All the best, Brian -- Brian Hole Ubiquity Press Ltd. ... www.ubiquitypress.com www.twitter.com/ubiquitypress

1 0

Missing functions in scipy.signals reference manual
by Nabil Freij 13 Jun '12

13 Jun '12

Hey, It appears that several functions in scipy.signals.bspline (cspline1d_eval for example) are missing from the reference manual. Is there any reason for this? KInd regards, Nabil

2 1