title: Cubic spline implementation in Octave
body: <p>My bold claim is that the Octave implementation of the cubic spline, as implemented in <code>interp1(..., "spline")</code> differs from the "natural cubic spline" algorithm outlined in, e.g., <a href="http://mathworld.wolfram.com/CubicSpline.html" rel="nofollow">Wolfram's Mathworld</a>. I have written my own implementation of the latter and compared it to the output of the <code>interp1(..., "spline")</code> function, with the following results:</p>
  
  <p><a href="https://i.stack.imgur.com/goJ5n.png" rel="nofollow"><img src="https://i.stack.imgur.com/goJ5n.png" alt="Spline comparison"></a></p>
  
  <p>I discovered that when I try the same comparison with 4 points, the solutions also differ, and, moreover, the Octave solution is identical to fitting a single cubic polynomial to all four points (and not actually producing a piecewise spline for the three intervals).</p>
  
  <p>I also tried to look under the hood at Octave's implementation of splines, and found it was too obtuse to read and understand in 5 minutes.</p>
  
  <p>I know that there are a few options for boundary conditions one can choose ("natural" vs "clamped") when implementing a cubic spline. My implementation uses "natural" boundary conditions (in which the second derivative of the two exterior points is set to zero).</p>
  
  <p><em>If</em> Octave's cubic spline is indeed different to the standard cubic spline, then what actually is it?</p>
  
  <p>EDIT:</p>
  
  <p>The second order differences of the two solutions shown in the Comparison plot above are plotted here:</p>
  
  <p><a href="https://i.stack.imgur.com/rFOpC.png" rel="nofollow"><img src="https://i.stack.imgur.com/rFOpC.png" alt="2nd order finite differences"></a></p>
  
  <p>Firstly, there appear to be only two cubic polynomials in Octave's case: one that is fit over the first two intervals, and one that is fit over the last two intervals. Secondly, they are clearly not using "natural" splines, since the second derivatives at the extremes do not tend to zero.</p>
  
  <p>Also, I <em>think</em> the fact that the second order difference for my implementation at the middle (i.e. 3rd) point is zero is just a coincidence, and not demanded by the algorithm. Repeating this test for a different set of points will confirm/refute this.</p>