Mailman 3 March 2011 - SciPy-Dev

SLSQP Constrained Optimizer Status
by Rob Falck Nov. 24, 2013

Nov. 24, 2013

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

Question about subpackage/submodule API
by Warren Weckesser May 23, 2011

May 23, 2011

The recent discussion about what to call the module in Pim Schellart's nice Lomb-Scargle contribution brought up a question for me that I have not seen discussed before. In many cases, a subpackage contains many modules, and the assorted functions and classes in these modules are made available in the (sub)package-level namespace by importing them from within __init__.py. For example, scipy/stats contains distributions.py, kde.py, morestats.py, mstats.py, rv.py, stats.py and vonmises.py. Except for mstats.py, the contents of all these are imported into the __init__.py namespace and included in __all__, so users can say, for example, >>> from scipy.stats import bayes_mvs instead of >>> from scipy.stats.more_stats import bayes_mvs Is this an *intentional* definition of an API? For example, is it "wrong" for a user to refer to the submodule 'more_stats' explicitly when importing? I think the answer is yes, because I don't think any promise is being made that the submodule won't be renamed or refactored as scipy development progresses. But I'd like to be sure that that is everyone else's understanding. If that is not the case, then changes that I have made in the past have violated the deprecation policy. For example, a while back I moved the functions in signal/filter_design.py that were related to FIR filters to their own module, fir_filter_design.py. By making appropriate changes to signal/__init__.py, all the function were still importable from scipy.signal. So, from my point of view, I didn't change the public API and no deprecation was necessary. But if scipy.signal.filter_design is part of the public API, then I should have made sure that something like >>> from scipy.signal.filter_design import firwin still worked after the refactor. Note: I'm not saying that *all* submodules should be private and have their objects exposed only through __init__.py. I'm just looking for some clarification of existing policy. Warren

6 12

Harwell Boeing support
by Nils Wagner April 3, 2011

April 3, 2011

Hi David, Is there a chance, that the Harwell Boeing format will be available in the trunk ? I saw that you have started a branch. http://projects.scipy.org/scipy/ticket/354 Nils

2 1

Re: [SciPy-Dev] Git Push
by Joshua Grant April 1, 2011

April 1, 2011

Hello. I've made some commits and would like to push them back into the repository at github.com/scipy/scipy.git but I'm getting and error of "error: Cannot access URL https://github.com/scipy/scipy/, return code 22". Do I have to push to check in changes? And if so, any ideas? Thanks.

2 2

Willing to contribute to SciPy & NumPy ...
by Sylvain Bellemare March 31, 2011

March 31, 2011

Hi, I would like to seriously start contributing to NumPy and/or SciPy, as much as I possibly can. Because NumPy & SciPy are new to me, I'm not so sure whether I could be of some help. But if my help is welcomed, and if it makes sense to ask: "What could I best contribute to?", then perhaps some background information about myself would be useful ... *ACADEMICS* I completed an undergraduate degree in Computer Science, along with some mathematics and physics courses. For the mathematics, I did some Calculus, Linear Algebra, Differential Equations, Fourier series, Fourier & Laplace transform. In Physics, I did up to and including a first course in Quantum Mechanics. I also did some undergraduate research work, that involved computational high energy physics (proton-proton collision). The work was done with some Mathematica packages (FeynArts <http://www.feynarts.de/>). *INDUSTRY* I currently work in the software industry and for the past few months, have been performing both software development and system administration tasks. In terms of object-oriented programming, my main experience is with Java. I'm a beginner with Python. I used Python at work to automate the reverse-engineering process of some Java programs. Career-wise, one of my goals is to go into scientific computing, and use Python as the main programming language, and to perhaps pursue graduate studies in Computational Physics, hence my current interest for contributing to NumPy & SciPy. If you wish to know more about me I have a LinkedIn profile at http://www.linkedin.com/in/sylvainbellemare. *DOCUMENTATION* Documentation-wise, I can use LaTeX. For instance, my resume, which is attached with this email, was written with LaTeX. It's noteworthy to mention that I like to work on documentation, as long as it balances with coding work [?]. If that makes any sense to you and you have ideas on projects that I could contribute to, please let me know, and I'll be very happy to do my very best to contribute. Best regards, -Sylvain

3 2

ANN: Numpy 1.6.0 beta 1
by Ralf Gommers March 31, 2011

March 31, 2011

Hi, I am pleased to announce the availability of the first beta of NumPy 1.6.0. Due to the extensive changes in the Numpy core for this release, the beta testing phase will last at least one month. Please test this beta and report any problems on the Numpy mailing list. Sources and binaries can be found at: http://sourceforge.net/projects/numpy/files/NumPy/1.6.0b1/ For (preliminary) release notes see below. Enjoy, Ralf ========================= NumPy 1.6.0 Release Notes ========================= This release includes several new features as well as numerous bug fixes and improved documentation. It is backward compatible with the 1.5.0 release, and supports Python 2.4 - 2.7 and 3.1 - 3.2. Highlights ========== * Re-introduction of datetime dtype support to deal with dates in arrays. * A new 16-bit floating point type. * A new iterator, which improves performance of many functions. New features ============ New 16-bit floating point type ------------------------------ This release adds support for the IEEE 754-2008 binary16 format, available as the data type ``numpy.half``. Within Python, the type behaves similarly to `float` or `double`, and C extensions can add support for it with the exposed half-float API. New iterator ------------ A new iterator has been added, replacing the functionality of the existing iterator and multi-iterator with a single object and API. This iterator works well with general memory layouts different from C or Fortran contiguous, and handles both standard NumPy and customized broadcasting. The buffering, automatic data type conversion, and optional output parameters, offered by ufuncs but difficult to replicate elsewhere, are now exposed by this iterator. Legendre, Laguerre, Hermite, HermiteE polynomials in ``numpy.polynomial`` ------------------------------------------------------------------------- Extend the number of polynomials available in the polynomial package. In addition, a new ``window`` attribute has been added to the classes in order to specify the range the ``domain`` maps to. This is mostly useful for the Laguerre, Hermite, and HermiteE polynomials whose natural domains are infinite and provides a more intuitive way to get the correct mapping of values without playing unnatural tricks with the domain. Fortran assumed shape array and size function support in ``numpy.f2py`` ----------------------------------------------------------------------- F2py now supports wrapping Fortran 90 routines that use assumed shape arrays. Before such routines could be called from Python but the corresponding Fortran routines received assumed shape arrays as zero length arrays which caused unpredicted results. Thanks to Lorenz Hüdepohl for pointing out the correct way to interface routines with assumed shape arrays. In addition, f2py interprets Fortran expression ``size(array, dim)`` as ``shape(array, dim-1)`` which makes it possible to automatically wrap Fortran routines that use two argument ``size`` function in dimension specifications. Before users were forced to apply this mapping manually. Other new functions ------------------- ``numpy.ravel_multi_index`` : Converts a multi-index tuple into an array of flat indices, applying boundary modes to the indices. ``numpy.einsum`` : Evaluate the Einstein summation convention. Using the Einstein summation convention, many common multi-dimensional array operations can be represented in a simple fashion. This function provides a way compute such summations. ``numpy.count_nonzero`` : Counts the number of non-zero elements in an array. ``numpy.result_type`` and ``numpy.min_scalar_type`` : These functions expose the underlying type promotion used by the ufuncs and other operations to determine the types of outputs. These improve upon the ``numpy.common_type`` and ``numpy.mintypecode`` which provide similar functionality but do not match the ufunc implementation. Changes ======= Changes and improvements in the numpy core ------------------------------------------ ``numpy.distutils`` ------------------- Several new compilers are supported for building Numpy: the Portland Group Fortran compiler on OS X, the PathScale compiler suite and the 64-bit Intel C compiler on Linux. ``numpy.testing`` ----------------- The testing framework gained ``numpy.testing.assert_allclose``, which provides a more convenient way to compare floating point arrays than `assert_almost_equal`, `assert_approx_equal` and `assert_array_almost_equal`. ``C API`` --------- In addition to the APIs for the new iterator and half data type, a number of other additions have been made to the C API. The type promotion mechanism used by ufuncs is exposed via ``PyArray_PromoteTypes``, ``PyArray_ResultType``, and ``PyArray_MinScalarType``. A new enumeration ``NPY_CASTING`` has been added which controls what types of casts are permitted. This is used by the new functions ``PyArray_CanCastArrayTo`` and ``PyArray_CanCastTypeTo``. A more flexible way to handle conversion of arbitrary python objects into arrays is exposed by ``PyArray_GetArrayParamsFromObject``. Removed features ================ ``numpy.fft`` ------------- The functions `refft`, `refft2`, `refftn`, `irefft`, `irefft2`, `irefftn`, which were aliases for the same functions without the 'e' in the name, were removed. ``numpy.memmap`` ---------------- The `sync()` and `close()` methods of memmap were removed. Use `flush()` and "del memmap" instead. ``numpy.lib`` ------------- The deprecated functions ``numpy.unique1d``, ``numpy.setmember1d``, ``numpy.intersect1d_nu`` and ``numpy.lib.ufunclike.log2`` were removed. ``numpy.ma`` ------------ Several deprecated items were removed from the ``numpy.ma`` module:: * ``numpy.ma.MaskedArray`` "raw_data" method * ``numpy.ma.MaskedArray`` constructor "flag" keyword * ``numpy.ma.make_mask`` "flag" keyword * ``numpy.ma.allclose`` "fill_value" keyword ``numpy.distutils`` ------------------- The ``numpy.get_numpy_include`` function was removed, use ``numpy.get_include`` instead. Checksums ========= 89f52ae0f0ea84cfcb457298190bee14 release/installers/numpy-1.6.0b1-py2.7-python.org.dmg 8dee06b362540b2c8c033399951e5386 release/installers/numpy-1.6.0b1-win32-superpack-python2.5.exe c1b11bf48037ac8fe025bfd297969840 release/installers/numpy-1.6.0b1-win32-superpack-python2.6.exe 2b005cb359d8123bd5ee3063d9eae3ac release/installers/numpy-1.6.0b1-win32-superpack-python2.7.exe 45627e8f63fe34011817df66722c39a5 release/installers/numpy-1.6.0b1-win32-superpack-python3.1.exe 1d8b214752b19b51ee747a6436ca1d38 release/installers/numpy-1.6.0b1-win32-superpack-python3.2.exe aeab5881974aac595b87a848c0c6344a release/installers/numpy-1.6.0b1.tar.gz 3ffc6e308f9e0614531fa3babcb75544 release/installers/numpy-1.6.0b1.zip

7 11

review request: median in scipy.ndimage.measurements
by Thouis (Ray) Jones March 25, 2011

March 25, 2011

I was prompted to add median() to the set of per-object measurements available in scipy.ndimage.measurements. It was not a difficult change to add, given the existing structure. Any comments on the following? https://github.com/thouis/scipy/compare/master...ndimage-measurements-median I was thinking of also adding median_positions(), but I'm not sure it's that useful. Thouis Jones

1 0

ANN: SfePy 2011.1
by Robert Cimrman March 24, 2011

March 24, 2011

I am pleased to announce release 2011.1 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method. The code is based on NumPy and SciPy packages. It is distributed under the new BSD license. Home page: http://sfepy.org Mailing lists, issue tracking: http://code.google.com/p/sfepy/ Git (source) repository: http://github.com/sfepy Documentation: http://docs.sfepy.org/doc Highlights of this release -------------------------- - discontinuous approximations - user-defined material nonlinearities - improved surface approximations - speed-up mesh reading - extensive clean-up - less code For more information on this release, see http://sfepy.googlecode.com/svn/web/releases/2011.1_RELEASE_NOTES.txt (full release notes, rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Vladimír Lukeš, Andre Smit, Logan Sorenson

1 0

SciPy 2011 Call for Papers
by Amenity Applewhite March 23, 2011

March 23, 2011

Hello, SciPy 2011 <http://conference.scipy.org/scipy2011/index.php>, the 10th Python in Science conference, will be held July 11 - 16, 2011, in Austin, TX. At this conference, novel applications and breakthroughs made in the pursuit of science using Python are presented. Attended by leading figures from both academia and industry, it is an excellent opportunity to experience the cutting edge of scientific software development. The conference is preceded by two days of tutorials, during which community experts provide training on several scientific Python packages. *We'd like to invite you to consider presenting at SciPy 2011.* The list of topics that are appropriate for the conference includes (but is not limited to): * new Python libraries for science and engineering; * applications of Python to the solution of scientific or computational problems; * high performance, parallel and GPU computing with Python; * use of Python in science education. *Specialized Tracks* This year we also have two specialized tracks. They will be run concurrent to the main conference. *Python in Data Science Chair: Peter Wang, Streamitive, Inc.* This track focuses on the advantages and challenges of applying Python in the emerging field of "data science". This includes a breadth of technologies, from wrangling realtime data streams from the social web, to machine learning and semantic analysis, to workflow and repository management for large datasets. *Python and Core Technologies Chair: Anthony Scopatz, Enthought, Inc.* In an effort to broaden the scope of SciPy and to engage the larger community of software developers, we are pleased to introduce the _Python & Core Technologies_ track. Talks will cover subjects that are not directly related to science and engineering, yet nonetheless affect scientific computing. Proposals on the Python language, visualization toolkits, web frameworks, education, and other topics are appropriate for this session. *Talk/Paper Submission* We invite you to take part by submitting a talk abstract on the conference website at: http://conference.scipy.org/scipy2011/papers.php Papers are included in the peer-reviewed conference proceedings, to be published online. *Important dates for authors:* Friday, April 15: Tutorial proposals due (remember: stipends will be provided for Tutorial instructors) http://conference.scipy.org/scipy2011/tutorials.php Sunday, April 24: Paper abstracts due Sunday, May 8: Student sponsorship request due http://conference.scipy.org/scipy2011/student.php Tuesday, May 10: Accepted talks announced Monday, May 16: Student sponsorships announced Monday, May 23: Early Registration ends Sunday, June 20: Papers due Monday-Tuesday, July 11 - 12: Tutorials Wednesday-Thursday, July 13 - July 14: Conference Friday-Saturday, July 15 - July 16: Sprints The SciPy 2011 Team @SciPy2011 http://twitter.com/SciPy2011 _________________________ Amenity Applewhite Enthought, Inc. <http://www.enthought.com> Scientific Computing Solutions

1 0

Documentation fixes with new git repo
by Erik Tollerud March 18, 2011

March 18, 2011

Now that the scipy repo is on git, what is the workflow for purely documentation fixes? Given all the references on docs.scipy.org talk about SVN, I speculate it doesn't work - should I just fork the scipy repo and submit a pull request via git with changes in the docstrings? -- Erik Tollerud

3 2