Mailman 3 July 2017 - SciPy-Dev

Are you using Bento to build scipy?
by CJ Carey 16 Jul '18

16 Jul '18

With the 1.0 release coming up, I figured this is a good time to take the pulse of the community regarding Bento. The project seems to have been abandoned before reaching stability, and it seems that the core problems it was trying to address have been at least partially fixed by the more official build systems. If you use Bento and would like to keep using it post 1.0, or if my previous sentence is wrong, please let me know!

10 15

N dimensional Gaussian quadrature
by oss 01 Sep '17

01 Sep '17

Hi scipy-dev, We ve implemented and tested n dimensional fixed_quad function with choice of orders for each dimension separately (useful when known singular points need to be avoided). See the diff below. We re open for any request for improvement. https://github.com/scipy/scipy/compare/master...multiwave:n_fixed_quad <https://github.com/scipy/scipy/compare/master...multiwave:n_fixed_quad> Thanks tryfon@multiwave

1 1

Normalizing derivatives of Gaussian kernels
by Jaime Fernández del Río 26 Jul '17

26 Jul '17

There is an interesting issue that was posted yesterday: #7644 <https://github.com/scipy/scipy/issues/7644> in a nutshell, when ndimage does an N-dimensional convolution with a Gaussian kernel, we separate it into N 1-dimensional convolutions, one along each axis. If the border is set to 'constant' mode, we need to replace that constant with the result of convolving the 1D kernel with that constant value, something we are currently not doing. In an ideal world that would mean leaving the constant alone if the order of the Gaussian kernel is zero, or setting it to zero if the order is larger than zero, because that's what the integrals from -inf to +inf of those kernels are supposed to be. In real life we get things right for zero order (because we normalize the kernel values to add up to 1.0) and the odd-ordered higher orders, (because they are antisymmetric, so they naturally add up to zero). But for even-ordered Gaussian kernels, which are symmetric, truncation means that we get a slightly negative sum, and that e.g. convolution of a constant field with a second order kernel, which should return all zeros, returns a small negative error. There are two ways we can solve this: 1. Make our separable approach to Gaussian filtering equivalent to what one would get without treating the filter as separable, by multiplying the constant value by the sum of the 1-D kernel after each 1-D convolution. This will at least make ndimage consistent with itself. 2. Normalize the Gaussian kernels of higher order, so that their total sums are equal to zero. I'm not sure if there's is a standard way of doing this in the literature, my searches haven't found anything. But e.g. all kernels you find as being an approximation to the Laplacian of Gaussian do add up to exactly zero. Thoughts and comments are very welcome. Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

2 1

Stochastic branch and bound optimization algorithm
by Benoit Rosa 26 Jul '17

26 Jul '17

Hi all, I recently implemented a stochastic branch and bound algorithm in python for one of my projects (namely, 3D registration without an initial guess, requiring global optimization over the SE3 group). After trying basinhopping without much success, I went for a modified stochastic branch and bound algorithm, described in those two papers (disclaimer: I'm an author in one of those) [1] C. Papazov and D. Burschka, Stochastic global optimization for robust point set registration, Comput. Vis. Image Understand. 115 (12) (2011) 1598-1609 [2] C. Gruijthuijsen, B. Rosa, P.T. Tran, J. Vander Sloten, E. Vander Poorten, D. Reynaerts, An automatic registration method for radiation-free catheter navigation guidance, J. Med. Robot Res. 1 (03) (2016), 1640009 Since I wanted to compare with other optimization algorithms, I implemented things by modifying the basinhopping file, and as such my implementation (git commit here: https://github.com/benoitrosa/scipy/commit/49a2c23b74b69dc4250e20e21db75bd0… ) is fully compatible with Scipy already. I have added a bit of documentation in the file too. If you want an idea, on my project (for which I can't share the code now), this algorithm finds the global optimum over the S03 space (i.e. rotations) in 4.5 seconds on average, where basinhopping takes more than 15 seconds, and doesn't necessarily converge to the correct solution. More about the algorithm itself: it's a common branch and bound algorithm (i.e. recursive traversal of a tree and bisecting of leaves to find an optimum), with two additions: 1 - The tree is traversed stochastically. This is governed by a temperature parameter, much like simulated annealing algorithms. At each node, there is a probability of going towards a "less promising" (understand: cost function higher) branch, this probability being governed by the temperature parameter. In the beginning, "bad" branches will be selected, ensuring an exploration of large portions of the space. As the number of iterations increases the temperature decreases, and the algorithms goes more towards the most promising branches/leaves, getting higher resolution in that part of the space. 2 - When creating a new leaf and evaluating the cost function there, the value is propagated down the tree, until reaching the root or a node with a lower cost. This ensures a smart traversal of the tree. Moreover, it also makes sure that at any time, the root node has the lowest cost, making it easy to query for the best solution when it is interrupted. Another advantage of this algorithm is that parameter tuning is pretty easy. It only needs the bounds of the search space (no initial guess), a sampling function (default is uniform) and a cost function (obviously). Additional parameters are the number of iterations, and the start and stop temperatures (start should be high to accept many "bad solutions" in the beginning, and stop should be tending to zero). If that algorithm is of interest to the SciPy community, I'd be happy to clean up the code and make a pull request ! Best, Benoit

3 3

More efficient spherical Voronoi algorithm
by Malte Ziebarth 25 Jul '17

25 Jul '17

Dear Scipy developers, during a project, I worked with spherical Voronoi tesselations. At the time I started, no python implementation of the spherical Voronoi tesselations existed, so I started to implement one. The algorithm I implemented is an existing Fortune's sphere variant which runs in O(N log N). I figured this may be interesting to the Scipy library since the existing method is at least O(N^2). You can find the code here: github.com/mjziebarth/ACOSA In that compilation, there's also methods to calculate the Delaunay triangulation, convex hull, and alpha shape of a point set on a sphere. Now to my question: Are you interested in the Voronoi tesselation algorithm and possibly some of the others as well? If so, I would start porting the code to scipy. In that case, some style guidance from one of the more involved developers would be helpful. Best, Malte Ziebarth

2 2

minimize_constrained interface
by Antonio Ribeiro 25 Jul '17

25 Jul '17

Hi all! I am working on a constrained optimizer solver for my GSoC project. I started on a separate repository and I am working now on a pull request to integrate it to SciPy. In order to prooced we have to make the following decision: should we fit the constrained solver to the ``minimize`` interface or should we create a new one? The best idea we came up with to try to fit the new solver into the ``minimize`` interface is to create a ``Constraints`` class and use it to pass the constraints specifications. I am, however, more and more conviced that the best option would be to create a new function ``minimized_constrained``. This new interface would be used to constrained minimization problems and I would include both SLSQP and COBLYA to it. The ``minimize`` interface would be reserved for unconstrained and bound-constrained problems. I think it would be better for the following reasons: 1. The ``minimize`` interface would be kept simple and reserved for unconstrained problems and problems with simple bound constraints. 2. We would have more freedom designing a ``minimize_constrained`` interface that best suit our needs. 3. The burden of implementing and including SLSQP and COBLYA to a new interface is not much greater than the burden of fitting the constrained solver being implemented into minimize. 4. This new interface could be used for new constrained solvers included to scipy. Let me elaborate on 1: I want to include finite-derivative options, quasi-newton options, different ways of passing constraints, different ways of passing second order information... All of that requires a great deal of documentation and the need of including several arguments to the function signature. And my point is: why to complicate ``minimize`` interface for something that will only be used by a single solver method? The idea is to create a new interface so we keep ``minimize`` interface clean and easy to use. It would also give us more freedom for creating a better ``minimize_constrained`` interface. I would much appreciate any feedback on this. I created a github issue (#7648) for this discussion: <https://github.com/scipy/scipy/issues/7648 <https://github.com/scipy/scipy/issues/7648> > Best, Antônio

1 0

Appveyor and Windows builds
by Andrew Nelson 20 Jul '17

20 Jul '17

Hi all, I wanted to say that I think the recent work going on to get scipy building on windows with mingwpy is fantastic, keep up the good work. It's great to see how you're teasing out all the problems and solving them. As part of these changes #7616 is going to add CI testing for windows builds on Appveyor. From my experience on another project (whose build requirements are much smaller) the rate limiting step in the testing of PR commits are the Appveyor checks, Travis finishes in a fraction of the time. Of course, it's hard to complain when OSS gets checked for free. I'm wondering whether that's going to be an issue with the scipy dev process. cheers, Andrew. -- _____________________________________ Dr. Andrew Nelson _____________________________________

2 1

GSoC status update
by Ralf Gommers 20 Jul '17

20 Jul '17

Hi all, Here's an update on the status of our GSoC projects. Antonio is making some great progress on his large-scale constrained optimizer. He has written a couple of nice blog posts to explain parts of the design at https://antonior92.github.io/year-archive/. So far he has been working in a separate repo ( https://github.com/antonior92/ip-nonlinear-solver); a first pull request is forthcoming though. The wiki (https://github.com/antonior92/ip-nonlinear- solver/wiki) and issues 4 and 5 on that repo give a good overview of progress. Aswhin unfortunately did not pass the first evaluation. His progress until that evaluation can be seen in his repo ( https://github.com/ashwinpathak20/scipy, branches diff-1 and hessian-diff) and his blog (https://ashwinpathak20.github.io/year-archive/). Matt and I (his co-mentors) do thank him for the effort he put into his project. All student blogs for projects under the PSF can be found at https://blogs.python-gsoc.org/ Cheers, Ralf

1 0

welcome Tyler and Cathy to the core team
by Ralf Gommers 16 Jul '17

16 Jul '17

Hi all, On behalf of the SciPy developers I'd like to welcome Tyler Reddy and Cathy Douglass as members of the core dev team. Tyler has been contributing to scipy.spatial for well over a year. He's the author of SphericalVoronoi and distance.directed_hausdorff - https://github.com/scipy/scipy/pulls/tylerjereddy. Cathy has been active in fixing issues in various modules as well as PR reviewing and issue triaging for the past two months - https://github.com/scipy/scipy/pulls/cdouglass. I'm looking forward to their continued contributions! Cheers, Ralf

4 3

Adding statistical distances
by Charles-Philippe Masson 16 Jul '17

16 Jul '17

Hi, I am a data scientist at Datadog, a cloud monitoring company. We have been working with statistical distances, which are distances between distributions, and more specifically on a family of distances that can be computed from CDFs, e.g., the first Wasserstein distance and the Cramér-von Mises distance. We wrote and optimized some code in Python to compute those distances. Since those distances have various applications, we think that it might be helpful to others and that is why we intend to share it. Here is the PR: https://github.com/scipy/scipy/pull/7563 I put the code in scipy.stats.stats as statistical distances share common features and applications with statistical tests (such as chisquare or ks_2samp) but let me know if that is not the appropriate place. Looking forward to hearing your feedback, Charles

2 1