Linear Interpolation Between Known Points

The 2026 nautical almanac lists the sun’s declination every hour. At 14:00 MDT on May 25th, it’s 20° 53.2’ N. At 15:00, it’s 20° 53.8’ N. My sight was at 14:37:42. What was the declination then?

This is linear interpolation: you have two known points, you want a value between them. Assume the change is uniform (it isn’t, but close enough for navigation), calculate the proportion of the interval, scale the difference.

In Scheme, where navigation calculations lived in 1970s Lisp machines:

(define (interpolate x0 y0 x1 y1 x)
  (+ y0 (* (- x x0) (/ (- y1 y0) (- x1 x0)))))

(interpolate 14.0 20.886667 15.0 20.896667 14.628333)
; => 20.89295 degrees (20° 53.6')

In Java, where GPS receivers implemented sight reduction algorithms:

public class Interpolate {
    public static double lerp(double x0, double y0, 
                               double x1, double y1, double x) {
        return y0 + (x - x0) * (y1 - y0) / (x1 - x0);
    }
    
    public static void main(String[] args) {
        double dec = lerp(14.0, 20.886667, 15.0, 20.896667, 14.628333);
        System.out.printf("Declination: %.5f°%n", dec);
    }
}

Before computers, navigators used pre-computed tables because spherical trigonometry by hand took twenty minutes per sight. The almanac was itself a massive interpolation tool—data points sparse enough to print in a book, dense enough to be useful. Early navigation computers automated this: read the table, interpolate to the exact second, pass the result to the sight reduction.

The formula appears in every numerical methods text because it’s the simplest model of continuous change from discrete samples. You’re asserting that between two measurements, the world behaves linearly. For celestial declination changing 0.6 arcminutes per hour, that’s accurate to within a few hundredths of an arcminute—far better than sextant reading precision. Sometimes the simplest assumption is good enough.