Skip to content

predict(): accept one obscode per time (mixed-observatory prediction) - #429

Merged
matthewholman merged 2 commits into
mainfrom
feat/predict-mixed-obscode
Jul 7, 2026
Merged

predict(): accept one obscode per time (mixed-observatory prediction)#429
matthewholman merged 2 commits into
mainfrom
feat/predict-mixed-obscode

Conversation

@matthewholman

Copy link
Copy Markdown
Collaborator

Summary

predict() predicted every object to a single observatory for all requested times. The rest of the chain is already per-time — obscodes_to_barycentric reads a per-row stn, _predict sets each Observation's observer position, and predict_sequence light-corrects per detection — so the single-observatory assumption lived in exactly one line (obs_data = [(obscode, t) for t in times_et]).

This lets obscode be either a single string (used for every time, as before) or a sequence of length len(times) giving one observatory per time — a mixed-observatory prediction in one call. Each time is light-corrected against its own station, while each orbit is integrated once across the whole sorted set (with the marching predict_sequence).

Backward compatibility (the important part)

A string obscode is broadcast to [obscode] * len(times), which produces the byte-for-byte identical obs_data and therefore identical output. The test asserts this directly:

predict(data, "X05", times) == predict(data, ["X05"] * len(times), times)   # exactly

Existing callers are unaffected — the predict CLI passes a single station, and interactive / broad-phase callers pass a string. A sequence whose length ≠ len(times) raises a clear ValueError.

Tests

test_predict_mixed_and_single_obscode:

  • string output is byte-identical to a same-code-per-time list (backward compat);
  • each time of a mixed-obscode call matches a single-obscode prediction at that station (to 1e-11 deg);
  • a length mismatch raises ValueError.

Why it matters

Combined with the marching predict_sequence (#428), predicting a catalog to a whole set of (observatory, time) targets — e.g. an ITF attribution sweep — can now integrate each orbit once across all observatories and interpolate at every target, instead of grouping by observatory and re-integrating per group. This PR is independent of #428 (it is correct on its own; #428 just makes the multi-time case fast).

🤖 Generated with Claude Code

predict() built its observer positions from a single obscode for all times. The
whole downstream chain is already per-time (obscodes_to_barycentric reads a per-row
stn, _predict sets each Observation's observer position, and predict_sequence
light-corrects per detection), so the single-observatory assumption lived in just
one line.

Let obscode be either a single string -- used for every time, exactly as before --
or a sequence of length len(times), giving one observatory per time. That predicts
a mixed-observatory sequence in one call: each time is light-corrected against its
own station while each orbit is integrated once across the whole sorted set (with
the marching predict_sequence). A length mismatch raises.

Fully backward compatible: a string obscode is broadcast to [obscode]*len(times),
which reproduces the previous obs_data byte-for-byte (test asserts str output ==
same-code-per-time list output exactly). Existing callers (the predict CLI passes
a single station; interactive/broad-phase callers pass a string) are unaffected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@matthewholman
matthewholman requested a review from kjnapier July 6, 2026 23:29

@kjnapier kjnapier left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

Resolve test_predict.py conflict with #428 (predict_sequence march):
keep both new tests (mixed/single obscode + marching equivalence) as
separate self-contained functions.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@matthewholman
matthewholman merged commit 8f8e3f8 into main Jul 7, 2026
7 checks passed
@matthewholman
matthewholman deleted the feat/predict-mixed-obscode branch July 7, 2026 21:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants