Mailman 3 March 2018 - SciPy-Dev

WIP: Class based Optimizers
by Andrew Nelson March 5, 2018

March 5, 2018

The #8414 PR on github (https://github.com/scipy/scipy/pull/8414) introduces an `Optimize` class for `scipy.optimize`. The `Optimize` class can be advanced like an iterator, or be advanced to convergence with the `solve` method. The PR is intended to provide a cleaner interface to the minimisation process, with the user being able to interact with the solver during iteration. This allows the variation of solver hyper-parameters, or other user definable interactions. As such `callback`s become redundant, as you can access all the optimizer information required. Other historical parameters may become redundant in these objects, such as `disp`. This is also a chance for a ground-zero approach to how people interact with optimizers. The PR is intended as a Request For Comment to gain feedback on architecture of the solvers. Given that it's a key part of infrastructure this may create a large amount of feedback, if I don't reply to it all bear in mind that I don't have unlimited time resource. In it's current state I've implemented `Optimizer`, `Function`, `LBFGS` and `NelderMead` classes. `LBFGS` and `NelderMead` are being called by the corresponding functions already in existence. The current test suite passes, but no unit tests have been written for the functionality. I'd prefer to add such a specific test suite once the overall architecture is settled. These optimisers were straightforward to translate. However, I don't know how this approach would translate to other minimisers, or things like `least_squares`. If a design could be agreed, then perhaps the best approach would be to tackle the remaining optimizers on a case by case basis once this PR is merged.

9 16

Spline interpolation in ndimage
by Jaime Fernández del Río March 5, 2018

March 5, 2018

Hi all, We have been discussing in issue #8465 <https://github.com/scipy/scipy/issues/8465> about the extension modes for the interpolation module of ndimage. As some other issues linked in that one show, this is an old problem, that has been recurringly discussed, and there mostly is agreement on what the correct behavior should be. But as all things ndimage, implementing any change is hard, in this case not only because the code is complicated, but also because of the mathematical subtleties of the interpolation method used. In trying to come up with a way forward for this I think I can handle the code complexity, but am having trouble being sure that I come up with a sound math approach. I think I have more or less figured it out, but I don't have a good academic background on signal processing, so was hoping that someone who does (I'm thinking of you, Chuck!) can read my longish description of things below and validate or correct it. My main source of knowledge has been: M. Unser, "Splines: a perfect fit for signal and image processing," in IEEE Signal Processing Magazine, vol. 16, no. 6, pp. 22-38, Nov 1999. Recommendations for bigger, better readings on the subject are also welcome! ----- In what follows I'll assume the input image is 2-D and NxN for simplicity, but I think everything generalizes easily If I'm understanding it right, all of our interpolation functions use B-splines for interpolation. So instead of having NxN discrete values on a grid, we have NxN B-splines centered at the grid points, and we keep the NxN coefficients multiplying each spline to reproduce the original image at the grid points exactly. If the spline order is < 2, the spline coefficients are the same as the image values. But if order >= 2 (and we use 3 by default), these have to be calculated in a non-trivial fashion. This can be done efficiently by applying a separable filter, which is implemented in ndimage.spline_filter. Because B-splines have compact support, when using splines of order n we only need to consider the B-splines on an (n + 1)x(n + 1) grid neighborhood of the point being interpolated. This is more or less straightforward, until you move close to the edges and all of a sudden some of the points in your grid neighborhood fall outside the original image grid. We have our extend mode, which controls how this points outside should be mapped to points inside. But here is where things start getting tricky... When the spline coefficients are computed (i.e. when ndimage.spline_filter is called), assumptions have to be made about boundary conditions. But ndimage.spline_filter does not take a mode parameter to control this! So what I think ndimage does is compute the spline coefficients assuming "mirror symmetric" boundary conditions, i.e.: a b c d c b | a b c d | c b a b c d So if our interpolated point is within the image boundaries, but some of the grid points in its (n + 1)x(n + 1) neighborhood fall outside the boundary, the code uses a mirror symmetric extension mode to fill in those values. This approach has a funny smell to it, but even if it's formally incorrect I think it would only be marginally so, as the values are probably going to be very close to the correct ones. The problem comes when the point being interpolated is outside the boundaries of the image. We cannot use mirror-symmetric spline coefficients to extend if e.g. we have been asked to extend using wrap mode. So what ndimage does is first map the value outside the boundaries to a value within the boundaries, using the given extension mode, then interpolate it as before, using mirror-symmetric coefficients if needed because its (n + 1)x(n + 1) neighborhood extends outside. Again, this smells funny, but it is either correct or very close to correct. This is mostly all good and well, except for the "wrap" and "reflect" extension modes: in these cases the area within one pixel of the image boundaries is different from anything inside the image, so we cannot use that approach. So what ndimage does is basically make shit up and use something similar, but not quite right. "reflect" is mostly correct, except for within that pixel of the boundary, but "wrap" is a surprising and confusing mess. So how do we fix this? I see two ways forward: 1. What seems the more correct approach would be to compute the spline coefficients taking into account the extension mode to be used, then use the same extension mode to fill in the neighborhood values when interpolating for a point outside the boundaries. 1. First question is whether this is doable? I need to work out the math, but for "wrap" it looks like it should be, not 100% sure if also is for "reflect". 2. Assuming it is it has the main advantage of doing things in a more general and understandable way once you have enough background knowledge. 3. It does go a little bit against our API design: you can control whether the input is spline-filtered automatically with a parameter, the idea being that you may want to do the filtering yourself if you are going to apply several different transformations to the same image. If the mode of the filtering has to be synced with the mode of the transformation, letting the user do it themselves is a recipe for disaster, because it's going to lead to very hard to track bugs. 4. As elsewhere in ndimage, the current implementation does a lot of caching, which works because it always interpolates for a point within the image boundaries. If we started interpolating for points outside the boundaries without first mapping to within there may be a performance hit which has to be evaluated. 2. The other approach is, for "wrap" and "reflect" modes, pad the input image with an extra pixel in each direction, then compute our current "mirror symmetric" spline coefficients, and leave things as they are right now, aside from some changes to the mapping of values to take the extra pixels into account. 1. This looks like a nightmare of special cases everywhere and potential off-by-one errors while putting it together, but it would just go along with the ugliness of the existing code. 2. It's unclear what we would do if we are given an input with prefilter=False, so this also breaks the current API, probably even more so. Any thoughts or recommendations 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 3

GSoC
by Hritik Narayan March 5, 2018

March 5, 2018

I'm having trouble identifying issues/problems that I could contribute to. Could someone help out? (Apart from the ideas listed on the Github page) I definitely want to pick SciPy as my GSoC organisation because frankly, I'd love contributing to something that is so powerful. -- Hritik

2 1

GSoC
by Hritik Narayan March 4, 2018

March 4, 2018

Hey everyone, I want to contribute to SciPy via GSoC, want to get into touch with possible mentors for clarification. Mainly, are the final proposals to be mailed directly to the mentor, or are they to be posted on a mailing list? -- Hritik, UTC +5:30

2 1

Contributing to SciPy through GSoC
by Anubhav Patel March 4, 2018

March 4, 2018

Hi everyone, I want to work on SciPy as part of GSoC and I have few queries. 1. On the Ideas Page, there was a mention of scipy.spatial.transform module. I want to know what will be the exact purpose of this module? 2. Whether the idea for a module for numerical differentiation was dropped completely? 3. Apart from those ideas listed on ideas page, are there any other area where you guys would like to see contribution on?

4 4

SciPy IRC channel lacks moderation
by Mike Graham March 3, 2018

March 3, 2018

Hi, The SciPy IRC channel on Freenode has been without moderation for a while. On rare occasion, we get trolls in the channel. For example, recently we had a couple instances of a troll posting the n-word in channel and tagging many users (most likely with the intent of sending them notifications). It would also be nice if someone could do things like fix dead links in the channel's topic statement. I would suggest that either the channel be discontinued (and removed from https://www.scipy.org/scipylib/mailing-lists.html ) or that the SciPy organization appoint a "Group Contact" with Freenode to administrate the channel. (Freenode requires the organization a channel is named after to notify them of the desired GC.) Nathan Goldbaum and Nathaniel J. Smith are channel regulars -- if you are looking for someone to appoint as GC, you might try to recruit one of them. Best, Mike

5 9

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 173, Issue 3
by 3ukip0s02＠sneakemail.com March 3, 2018

March 3, 2018

On Thu Mar 1 10:40:16 EST 2018, Todd wrote: > Similarly, there is an fft-based version of correlation equivalent to > fftconvolve that isn't implemented, > > 2D and n-d versions of fft convolution > and correlation that aren't implemented, etc. > correlate and convolve are both N-D, and implemented using fftpack when possible, which is compiled fortran, so I'm not sure those would benefit much. convolve2d and correlate2d could benefit from FFT. Only reason they don't is because of the boundary conditions, but I think they could be adapted to FFT if the inputs were extended in the relevant ways first? A lot of these issues apply elsewhere in scipy.signal. For example the > stft/spectrogram uses a slow, naive implementation. > All of the _spectral_helper functions like stft() and spectrogram() are fftpack-based, as well. Is there a lot of room for improvement here?

1 0

Re: [SciPy-Dev] GSoC 2018 : Rotation formalism
by Robert Lucente March 1, 2018

March 1, 2018

You guys are probably aware of the stuff below but just in case. Quaternions and spatial rotation https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation

7 6

GSoC 2018: Blendenpik (A least-square solver)
by Jordi Montes Feb. 28, 2018

Feb. 28, 2018

Hello, I am Jordi Montes, an enthusiastic student of discrete mathematics wanting to participate in this GSoC. My idea is to take advantage of the current method for dimensinality reduction of scipy (clarkson_woodruff_transformation) and build a least-square solver on top of it. The principal motivation is that it outperforms the other solvers in many real world applications, even those in LAPACK. I already discussed this in the mailing list before the GSoC admission term started, but I have also written a formal proposal (which is attached in this email). As always, feel free to ask about any doubt that comes to your mind or point to any improvement that you think I could make. Thanks, Jordi.

2 1