# This adds root finding to pchip as this is possible to do optimal because pchip is a monotonic interpolation. #3260

Open
wants to merge 3 commits into
from

## Conversation

Projects
None yet
5 participants
Contributor

### bmcage commented Jan 31, 2014

 Alternative would be fsolve and friends, but those would not use the known structure of pchip. A typical use for pchip is an interpolation that can be inverted. This adds a root finding to pchip that uses the pchip form to invert fast. I am not sure this is the best way. It might be better to use phcip to obtain yi=f(xi) and yi' = f'(xi), then create the cubic monotonic interpolation through yi with derivatives yi' as self.pchipinv. This should be the correct f^-1. Then when asking roots, one can use this self.pchipinv. The algorithm proposed here works differently: search the cubic for the y value given, calculate the 3 cubic roots. As it is a monotonic function only 1 of the roots will be in the correct interval. Some problems: computing cubic roots gives imaginary parts which need to be discarded. See the np.allclose(ires, 0., atol=1e-10) to discard this. -10 is hard coded return value can be numerically close to the bounding edges. See the np.allclose(x1-rres, 0., atol=1e-10) to recognize this. -10 is hard coded Use of newaxis to dump the results: x[c] = ress[:, np.newaxis] I believe this will be correct for the use cases possible
``` This adds root finding to pchip as this is possible because ```
```pchip is a monotonic interpolation.
Alternative would be fsolve and friends, but those would not use the known structure of pchip```
``` 5239a59 ```
Owner

### pv commented Jan 31, 2014

 It could be more efficient to convert `pchip` to use the new PPoly piecewise polynomial representation, which has efficient root finding already implemented. We will probably eventually deprecate polyint.PiecewisePolynomial in favor of that.

Closed

Contributor

### bmcage commented Jan 31, 2014

 PPoly seems not optimal to use. It's not actually root finding but inversion, more like fsolve. You then know the interval. After all pchip is monotone, so you know there is one, and only one value that satisfies y=f(x). My problem 1 and 2 however can be fixed by using the same inversion fuction as PPoly: real_roots in https://github.com/scipy/scipy/blob/master/scipy/interpolate/_ppoly.pyx Would this real_roots be exposed?
Owner

### pv commented Jan 31, 2014

 The root finding internal function is exposed as `scipy.interpolate._ppoly.real_roots`. I see, the point is that you can find the correct interval fast via searchsorted in y. One could think about adding an additional argument "assume_monotonic" to `real_roots`, so that the binary search can be done inside the routine itself.

Merged

Contributor

### bmcage commented Feb 7, 2014

 I tried the other possible approach: add an inverse function that returns an interpolated object which is the inverse. This is not working however, too unstable. The numerical precision errors in solution values or inverse derivatives, are such that the inverse interpolated polynomial is very different over large intervals. So that approach is a no go, root finding will be the only acceptable approach. So, an assume_monotonic added to real_roots is an option. Approach here can be done via inheritance if needed in current scipy
``` rewrite in terms of real_roots from _ppoly ```
``` c6401f1 ```

### coveralls commented Feb 7, 2014

 Coverage remained the same when pulling c6401f1 on bmcage:monohermspline into 233ad82 on scipy:master.

Owner

### pv commented Feb 13, 2014

 This should be reimplemented on top of current master branch, as gh-3267 converted Pchip to use BPoly. Actually, I think this PR would best be done by adding a method `def solve(self, y, assume_monotonic=False):` to the PPoly piecewise polynomial class. After that, a similar method could be added to `Pchip`. For `assume_monotonic == True`, we should use the faster approach here, and for `assume_monotonic=False` a slower approach that finds all the roots. Ideally, the `solve` method would be written in Cython directly in the `real_roots` routine.
Member

### ev-br commented Feb 13, 2014

 If/when `assume_monotonic` is added, the behavior should be at least very clearly documented: ``````In [21]: %history import numpy as np from scipy.interpolate import pchip xi = [1., 2., 3., 4.] yi = [-1., 1, -1, 1] p = pchip(xi, yi) `````` ``````In [22]: p.root(1) Out[22]: array(3.9999999947957403) In [23]: p.root(0.5) Out[23]: array(3.6736481776669305) ``````
Member

### ev-br commented Feb 13, 2014

 @bmcage can you provide an example where the inverse interpolation gives unacceptable numerical errors?
Contributor

### bmcage commented Feb 14, 2014

 @ev-br I pushed my local branch with that test: https://github.com/bmcage/scipy/tree/monohermsplineinv If you then run the test: \$ python runtests.py --python scipy/interpolate/tests/test_polyint.py you will see the bad interpolation In test_inv_vGn of test_polyint.py uncomment the part using pylab to create a plot to see it. That is the function I need to inverse hundred of thousands of times in an inverse algorithm.
Member

### ev-br commented Feb 16, 2014

 Hmm... This example looks a bit artificial to me, is it actual data you're interpolating? What is the actual problem you're solving? In any case, since the `h` is logarithmically spaced and `u` follows a power law, have you tried working with them in the log space? [If this turns into a discussion about how to deal with these exact data, we might want to move it from a github issue to the scipy-user mailing list]
Contributor

### bmcage commented Feb 16, 2014

 I'm doing it logwise in reality. It's just a testcase which shows how it can fail dramatically. Rootfinding does not cause such errors.

### pv added needs-work labels Feb 19, 2014

``` add example to slsqp itself ```
``` be7caa0 ```

### bmcage added a commit to bmcage/centrifuge-1d that referenced this pull request May 20, 2015

``` add a monotone interpolation based on scipy/scipy#3260 ```
``` 62588e8 ```

Merged

Closed