Cubic monotone interpolation.

[mbostock]

• [x] tests
• [x] documentation
• [x] decide on start and end slopes: one-sided
• [x] fix one-sided slope with h0 = 0 or h1 = 0
• [x] decide how to deal with non-monotonic data in x (h0 < 0 or h1 < 0): document it

[mbostock]

Test case from Wikipedia:

Seems to differ a bit from Fritsch–Carlson. And actually centripetal Catmull–Rom splines look a bit better in this case while coincidentally preserving monotonicty.

[ghost]

If you happen to be looking for data that produces some overshoot then at least points [[0, 224], [100, 200], [107, 180], [502, 300], [580, 120], [607, 148], [900, 400]] seem to do the trick with natural and catmullRom.

[mbostock]

Here’s your example:

I agree that uniform Catmull–Rom splines don’t do very well here (red, α = 0), but centripetal does (green, α = 0.5). I also think from this example that using zero slope for the first and last point may not be the best default behavior, although it is simple…

[mbostock]

I changed the default α for Catmull–Rom splines to 0.5 in 5a21ab2feade0c6bd2db38f144a7666a475a8607. This is a better default behavior and also has the nice side-effect that curve(cardinal) and curve(catmullRom) now behave differently.

[ghost]

Yeah. The monotone ones (be it Steffen or Fritsch-Carlson) are somewhat useful for plotting smooth lines through data points where you might want to avoid overshoot but can't choose the curve parameters beforehand. They rarely provide the best looking solution though.

I'll have a look at replacing the zero slopes at boundaries with something better. For example just choosing the slope between the boundary point and its neighbor might be ok.

[mbostock]

Yes, the monotonicity guarantee is still useful for data visualization even if centripetal Catmull–Rom is perhaps the best in the general case.

And yep, that’s what I would try for the first and last slope, too. Send me a PR to the monotone branch if you get it working? Thanks.

[ghost]

I sent the PR (and of course messed up the target branch, sigh), but here's a comparison similar to the one you made with the different boundary handling applied:

[mbostock]

Nice. This looks great!

I noticed an edge case that needs testing. If two adjacent points have the same x-value, it has different behavior than if the two points are separated by a small ε. Here’s x₀ = x₁:

And here’s x₁ - x₀ = 1e-6:

I think this is just an issue with the first and last segment, though. The rest of the code seems to handle duplicate x-values okay. Though, it doesn’t appear to gracefully handle data that is not monotonic in x. But that’s probably fine to ignore for this curve, and document it as an assumption.

[mbostock]

Okay, pushed a fix in c1a9743.

[ghost]

Great, thank you!