Merge pull request #3477 from RosettaCommons/vmullig/simpler_polylinear_interpolation
Actually correct "as-angles" polylinear interpolation
For peptoids and N-methyl amino acids, we need the polylinear interpolation used to interpolate well centres to work near the -180/180 wraparound point. Andy and I scratched our heads for a long time about little numerical problems that we were seeing in the derivatives with his approach from pull request #2851. In the end, we decided that, since the goal was to avoid weird behaviour at the wraparound point for interpolated angle values, we could achieve that just as easily by much simpler means. The basic approach here is:
- Determine if the values being interpolated are generally closer to 0 or to the 180/-180 discontinuity.
- If the former, interpolate as values.
- If the latter, shift into the [0,360) range, interpolate as values, then shift back to (-180,180].
~~This might break down if unusually extreme values are being interpolated, but then, interpolation isn't well suited to really extreme cases.~~
**UPDATE:** This _was_ breaking in cases relevant to peptoids, so I went back and implemented an _actually_ correct N-dimensional polylinear interpolation scheme. The new approach uses a recursive function that carries out a series of evaluations for successively lower dimensions. The 1-dimensional interpolator avoids the 0/360 or -180/180 angle discontinuities by using the shortest interpolation between two values, as described above; since higher-dimensional interpolators call the 1D interpolator, they also handle the discontinuity properly.
Tasks:
- [x] Implement the interpolation
- [x] Check whether it solves the remaining problems in the peptoid branch (#2513).
- Not all of them. But that's okay -- it's a start.
- [x] Check that this works with the lysine Dunbrack test cherry-picked from closed pull request #2851.
- [x] Shorten this test.
- [x] Check additional unit tests pulled from that branch.
- [x] Check what this does to canonical scoring. I may have to special-case the N=2 case.
- I think we're okay. The generalization covers the N=2 case correctly.
- [x] Beauty.
- [x] Documentation.
So there are a bunch of integration test trajectory changes from this branch, but no changes to scoring and no unit test failures. This tends to happen when one refactors Dunbrack or other core scoring code. Andy and I have both looked at the integration tests, and we're both pretty convinced that the failures fall into one of two categories:
- Very tiny numerical differences that accumulate, since we're doing some math in a different way.
- Changes to exotic noncanonicals that we actually expect (since we're interpolating Dunbrack libraries that rely on more than two mainchain torsions properly, now).
**SO EXPECT A BUNCH OF INTEGRATION TEST CHANGES, IF YOUR TEST DOES PACKING OR MINIMIZATION AND USES FA_DUN.**