Draw a trend line through the food bars

The daily grams bars bounce around enough to hide a steady climb, so they
cannot answer the question you actually have about a growing puppy: is he
eating more than he was? A least-squares fit through them can.

Two kinds of day stay out of the fit. Today is half-eaten, and including it
would pull the line down every morning and let it drift back up as meals go in
— a line that tracks the clock rather than the dog. A day marked "not counted"
has a hatch rather than a figure, and fitting a zero there would invent a dip.
The line is drawn only across the days it was fitted on, so it never implies it
knows about the ones it skipped.

The caption is the part that needed the care. A straight line through seven
noisy points will always have a slope, and announcing it as a fact is the same
mistake the walking goal made. So a direction is named only when the fitted
climb is larger than the scatter of the days around it, and only when it clears
5 g a week and a twentieth of a typical day; otherwise it says the variation is
larger than any trend, which over a short window is usually the truth.

It names its window too — "over the last 14 days" — because the 7/14/30 picker
already drove this (weeklyData builds the array the fit runs on) but nothing on
screen said so, and the line moves too little between windows to show it. When
there are fewer than four complete days it now says why there is no line rather
than leaving bars with nothing through them.

Meals can be logged without an amount, so the note counts them: a day can read
low because he ate little or because nobody typed the number, and the chart
should not let those look the same.

The checks cover the refusals rather than the arithmetic — a see-saw is not
reported as a trend, a slope under the scatter is not either, three days will
not fit, a marked day does not shift the line, and each window length reaches
the fit intact.

checks/food-trend.mjs

@@ -0,0 +1,89 @@
+// The fit through the Food (grams) bars. The arithmetic is easy to get subtly
+// wrong and the result is a sentence stating a fact about the puppy, so the
+// cases that matter are the ones where it should decline to say anything.
+import { load } from "./extract.mjs";
+import { suite, eq, ok, report } from "./assert.mjs";
+
+const app = load({ names: ["foodTrend"] });
+
+// The 7/14/30 picker reaches the trend by deciding how many days weeklyData
+// builds — there is no second mechanism, so this is the thing to hold still.
+let windowDays = 7;
+const weekly = load({
+  names: ["startOfDay", "endOfDay", "ymd", "weeklyData"],
+  stubs: {
+    chartDays: () => windowDays,
+    isExcluded: () => false,
+    eventsForDay: () => [],
+    sleepMsInRange: () => 0,
+    walkMsInRange: () => 0,
+  },
+});
+
+suite("the day picker is what sets the trend's window");
+for (const n of [7, 14, 30]) {
+  windowDays = n;
+  eq(weekly.weeklyData([]).length, n, `picking ${n}d gives the charts ${n} days to fit over`);
+}
+windowDays = 7;
+
+// weeklyData's shape, as far as foodTrend reads it. Today is last, as there.
+const days = (grams, { excluded = [] } = {}) =>
+  grams.map((g, i) => ({ grams: g, excluded: excluded.includes(i) }));
+
+suite("it declines to fit when there is nothing to fit");
+{
+  eq(app.foodTrend(days([300, 320, 310])), null,
+     "three days is too few — today is dropped, leaving two, and two always fit perfectly");
+  eq(app.foodTrend(days([300, 320, 310, 330, 340], { excluded: [0, 1] })), null,
+     "marked days don't count toward the four either");
+  eq(app.foodTrend(days([])), null, "an empty window fits nothing");
+}
+
+suite("today is left out, being half-eaten");
+{
+  // Four steady days then a partial today. Including today would tip the line
+  // down; the fit should not see it at all.
+  const t = app.foodTrend(days([400, 400, 400, 400, 50]));
+  ok(t, "four complete days are enough");
+  eq(Math.round(t.perWeek), 0, "a flat run stays flat despite today being low");
+  eq(t.last, 3, "the line stops at the last complete day, not at today");
+}
+
+suite("it reports a direction only when the climb beats the scatter");
+{
+  const rising = app.foodTrend(days([200, 250, 300, 350, 400, 450, 0]));
+  ok(rising.clear, "a clean climb is reported");
+  eq(Math.round(rising.perWeek), 350, "…at 50 g a day, which is 350 g a week");
+
+  const falling = app.foodTrend(days([450, 400, 350, 300, 250, 200, 0]));
+  ok(falling.clear, "a clean fall is reported");
+  ok(falling.perWeek < 0, "…with a negative weekly change");
+
+  // Same mean, no direction, plenty of noise: the honest answer is "steady".
+  const noisy = app.foodTrend(days([200, 500, 210, 480, 190, 520, 0]));
+  ok(!noisy.clear, "a see-saw is not a trend, however the slope comes out");
+
+  // A gentle real climb buried in large day-to-day swings: also not claimable.
+  const buried = app.foodTrend(days([300, 520, 180, 540, 200, 560, 0]));
+  ok(!buried.clear, "a slope smaller than the scatter is not reported as a trend");
+}
+
+suite("the fitted line passes through the data");
+{
+  const t = app.foodTrend(days([100, 200, 300, 400, 500, 0]));
+  eq(Math.round(t.at(0)), 100, "it starts where the first day sits");
+  eq(Math.round(t.at(4)), 500, "and ends where the last complete day sits");
+  eq(Math.round(t.mean), 300, "the mean is the mean of the days it fitted");
+}
+
+suite("marked days are skipped without shifting the line");
+{
+  // The middle day is marked; the rest describe a clean 50 g/day climb. The fit
+  // must ignore the hatch rather than reading it as a day of zero grams.
+  const t = app.foodTrend(days([200, 250, 0, 350, 400, 450, 0], { excluded: [2] }));
+  eq(Math.round(t.perWeek), 350, "the climb is unchanged by the marked day");
+  ok(t.clear, "…and it is still clear, not drowned by a false zero");
+}
+
+export default report("food-trend");