Mailman 3 August 2015 - SciPy-Dev

ANN: Numpy 1.10.0b1 release
by Charles R Harris Aug. 11, 2015

Aug. 11, 2015

Hi All, give this release a whirl and report any problems either on the numpy-discussion list or by opening an issue on github. I'm pleased to announce the first beta release of Numpy 1.10.0. There is over a year's worth of enhancements and bug fixes in the 1.10.0 release, so please give this release a whirl and report any problems either on the numpy-discussion list or by opening an issue on github. Tarballs, installers, and release notes may be found in the usual place at Sourceforge <https://sourceforge.net/projects/numpy/files/NumPy/1.10.0b1/>. Chuck

1 0

Optimization success threshold?
by Ryan J. Kinnear Aug. 10, 2015

Aug. 10, 2015

Dear list, I'm using some of the optimization routines in scipy to help design high frequency electronic filters, it takes a very long time to evaluate the cost function just once (order of seconds). It's also not necessary to get a "perfect" design, it can quit as soon as it reaches a value that is good enough. As far as I can tell, there isn't really a straightforward way to tell the optimizer to quit once it gets below some threshold. This can be hacked in with exceptions or the callback, but is that the best way to do it? Would it be valuable to add a "success threshold" to the optimization routines? -RK

5 7

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 142, Issue 6
by Matt Newville Aug. 10, 2015

Aug. 10, 2015

Hi Ryan, Hi Ryan, Date: Sun, 09 Aug 2015 21:31:16 -0700 > From: "ryan" <ryan(a)kinnear.ca> > Subject: Re: [SciPy-Dev] Optimization success threshold? > To: "SciPy Developers List" <scipy-dev(a)scipy.org> > Message-ID: <web-33855797(a)mail2.webnames.ca> > Content-Type: text/plain;charset=utf-8 > > I actually think it was misunderstood yes, I will try to improve my > explanation. > > The ftol and xtol parameters halt the optimizer when the objective isn't > changing very much (it thinks it has converged). But for my application > (microwave filter design), cost function evaluations are very expensive, up > to a couple seconds on simple models, and up to even 10 min + for > electromagnetic simulations. We have some notion of what a "good enough" > objective function value is (e.g. reflected power below -20dB) and we want > the optimizer to stop as soon as it finds some parameters that satisfy this > criteria so that it doesn't keep running long simulations for no reason. I > would call it something like a success threshold option. > > This seems like a reasonable feature, especially for expensive cost > functions or non convex problems - which is why I'm posting in scipy-dev. > Although even though there is no explicit option for specifying a success > threshold, there may be a reasonable idiom for doing this that I am just > unaware of. > > -RK > > I'm not sure whether it would be of interest to you, but we just merged-in the ability for a per-iteration callback function halt fitting in lmfit ( https://github.com/lmfit/lmfit-py/pull/245). This is currently in the master branch at github, and works in a manner very similar to Andrew Nelson's suggestion and PR: if the per-iteration-callback function returns True, the fit is halted immediately. See http://cars9.uchicago.edu/software/python/lmfit/fitting.html#fit-itercb-lab… for "development docs". I do agree that having this ability generally available in scipy.optimize would be useful. I think it's somewhat easier to do within lmfit because we already have a wrapper to the users objective / cost function to convert between "current variable values" and "Parameters". As a side-effect, we can easily (and uniformly for all supported minimization methods) inject running and checking the return value of such a callback function there. --Matt Newville

1 0

backwards-incompatible change in Akima1DInterpolator?
by Andreas Hilboll Aug. 6, 2015

Aug. 6, 2015

Currently, interpolate.Akima1DInterpolator does not use Ppoly's ``extrapolate`` kwarg, but always sets ``extrapolate=False``. I would like to expose the extrapolation feature in the API of Akima1DInterpolator. However, Ppoly's default value for extrapolate is True. So there are two choices: a. Make Akima1DInterpolator's extrapolate default to False. This is backward-compatible, but inconsistent with the usual Ppoly behaviour. b. Make Akima1DInterpolator's extrapolate default to True. This is consistent with Ppoly, but is not backwards-compatible. One way to go could be add a DeprecationWarning or similar now for 0.17, and then only expose the extrapolate kwarg in 0.18. Any opinions on how to attack this issue? -- Andreas.

2 1

signal.dlsim cannot handle complex input #4964
by Tommaso Fabbri Aug. 6, 2015

Aug. 6, 2015

Hi All, I would like to have to some feedback about the issue #4964. I think it can be easily solved with the superposition principle (first applying it on the real part of the input and then on the imaginary one). What do you think about it? Can I proceed with this change? Thank you so much. -- Tommaso Fabbri

1 0

`scipy.signal` feedback for PR #4881, ltid for discrete-time systems
by Freddy Rietdijk Aug. 6, 2015

Aug. 6, 2015

Hi everyone, This is a call for feedback on a PR. A while ago PR #4881 <https://github.com/scipy/scipy/pull/4881>was opened to add the class `ltid` for linear discrete-time systems. Before the PR, there was a discussion on this topic in #2912 <https://github.com/scipy/scipy/issues/2912>. So far, the PR hasn't had much feedback. If you have any, please add it. It would be nice to get this feature in as soon as possible, because that clears the way for adding more system specific methods for filtering and such. Frederik

1 0

Weekly Summary 2015/08/05
by Abraham Escalante Aug. 5, 2015

Aug. 5, 2015

Hello all, Here is last last week's progress and this week's plan for `scipy.stats` improvements. *Week 9 topics:* - NaN policy implementation details done. The PR is now in bikeshedding phase (agreeing on keyword and option names). - `bayes_mvs` has been merged. - `f_oneway` now passes NIST test cases. Some details still remain to be addressed (like addition of examples). *Week 10 topics:* - Reach a NaN policy naming consensus and merge. - `mstats` consistency with `stats` will be resumed once NaN policy PR is merged. - Finish details on `f_oneway` and merge. - Once `f_oneway` is merged, `linregress` will be dealt with, using the same treatment. - `kstat` and `kstatvar` still have some documentation details to add. For your reference: - Open Pull Requests <https://github.com/scipy/scipy/pulls/aeklant> - Open StatisticsCleanup issues <https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3ASt…> Regards, Abraham.

1 0

`scipy.stats` NaN handling policy
by Abraham Escalante Aug. 3, 2015

Aug. 3, 2015

Hello all, As some of you may know, for the last two months or so we have been trying to get the community to converge on a policy to handle NaN values in `scipy.stats`. I will not go into details because it would take too long, but you can follow the discussion in gh-571 <https://github.com/scipy/scipy/issues/571> or the PR in gh-5007 <https://github.com/scipy/scipy/pull/5007>. The implementation details are all but complete at this point but I would like to ask for opinions on the API naming. In summary, I added a keyword called "nan_policy", with options "propagate", "raise" and "omit", where "propagate" returns a NaN value, "raise" throws a ValueError and "omit" delegates to the equivalent masked array function, omitting the NaN values. Alternate names proposed: - "nan_policy" --> "nan_check", "on_nan", "nan_action" - "propagate" --> "undefined" - "omit" --> "ignore", "missing" We are still open for naming suggestions as long as the community agrees. If people seem happy with the choices we have already made, this PR will be merged soonish (two or three days maybe). Cheers, Abraham.

2 1

RFC: non-linear least squares
by Evgeni Burovski Aug. 2, 2015

Aug. 2, 2015

Hi, I'd like to draw attention to the great work Nikolay Mayorov is doing for his GSoC on improving non-linear least squares functionality in scipy. So far he single-handedly implemented two trust-region type algorithms for nonlinear LSQ: rectangular trust region dogleg ('dogbox') and trust region reflective algorithm ('trf', this one is similar to what MATLAB is using as its default NLSQ method). Both of these algorithms natively handle box constraints on fit parameters. Both are implemented to work with dense or sparse Jacobians, so that they are suitable for large-scale problems (up to and in excess of 10k variables). One other feature of the implementation is modified loss functions for robust LSQ. Several useful loss functions are available out of the box, and there is flexibility for using custom user-supplied loss functions. Several examples are available in Nikolay's GSoC blog at <https://nmayorov.wordpress.com/>, along with narrative discussion of the mathematical content, and results of benchmarking his algorithms against general-purpose optimizers (L-BFGS-B in particular) and MINUIT-type constrained LSQ optimizer (specifically, leastsqbound --- which is equivalent to LMFIT). The relevant PR is under review at <https://github.com/scipy/scipy/pull/5044>. We plan on merging this PR in some reasonably near future, and we'd like to ask for help: * If you are an expert on mathematical optimization, we'd be grateful if you help reviewing the code; * If you are a user of nonlinear least squares, we'd be grateful if you test drive the new functionality and let us know how it works on your problems. * We'd welcome comments on the user interface. Cheers, Evgeni

1 0

Proposal: Spherical Voronoi Diagrams
by Tyler Reddy Aug. 2, 2015

Aug. 2, 2015

*Basic idea*: Implement spherical Voronoi diagram code in scipy.spatial, which is where current computational geometry algorithms reside, including Voronoi, ConvexHull, and Delaunay. Spherical Voronoi diagrams are extremely useful for parsing spherical objects in biology (i.e., viruses), planetary physics, search and rescue, airspace territory assignment, network coverage, etc. The current planar Voronoi diagram code is not capable of handling this. *The current state of the code*: With plenty of helpful feedback after my talk at PyData London 2015 presenting some of the challenges ( https://www.slideshare.net/slideshow/embed_code/key/1bKCEyHa789nBe), I've been able to refine the code ( https://github.com/tylerjereddy/py_sphere_Voronoi). The algorithm and usage examples are presented in the documentation ( http://py-sphere-voronoi.readthedocs.org/en/latest/voronoi_utility.html). Empirical testing indicates that the algorithm exhibits quadratic time complexity, while the best theoretical results in the literature are loglinear. For several computational geometry calculations it is relatively common to use a lower-performing algorithm if it is easier to implement. The minimum number of input points (generators) tolerated is 4 and maximum on a modern laptop is ~ 70,000 with 16 GB of physical memory. There are probably a lot of opportunities to improve the code. I have some plots of the current performance profiles, if needed. In many cases, the reconstitution of spherical surface area achieved by summing the spherical polygon (Voronoi region) surface areas is > 99 %. Nearly-degenerate Voronoi regions (with vertices almost on top of each other) could perhaps be handled more gracefully--they currently return areas of approximately 0. The integrity of the code is currently maintained by a number of unit tests. *Question*: Is this perhaps of interest for integration into scipy? I suspect the standards are pretty high to get the pull request for a whole new functionality into the package, so I thought it best to inquire this way first before the potentially substantial time investment of converting the code to scipy standards from my current in-house layout. I know there are guidelines I can follow for the pull request as well, but if there are any basic suggestions from glancing at the current state of the code that might be helpful as well. Thanks, Tyler

1 0