Define the event to find
A chart asks where the Sun is at a given time. An event search reverses that question: when does the fitted Sun longitude reach a chosen direction? Before calculating a time, we must specify where to begin, which way to search, and what the dataset permits us to ask.
Before this lesson
Read the position-evaluation lesson and the preceding chart-calculation path. These examples use invented longitudes and relative times to expose the search contract; they are not predictions of actual solar events.
What you will learn
You will distinguish invalid requests, admitted searches and missing results, convert day offsets to sampling times, and explain why admission does not guarantee a complete search.
Dotted-underlined terms open a definition beside the text. Select one to read more, then close it to continue.
Each step has its own check. Pass every step to complete the lesson. Your answers and checked steps are saved in this browser, so you can continue after leaving or reloading.
1. Make the question precise
Imagine starting at a recorded instant and asking for the next time the Sun reaches 30°. The request has three inputs: the starting epoch (an instant with a time scale), a target longitude in degrees, and a direction through time. Forward means later times; backward means earlier times. Direction does not describe whether longitude itself increases or decreases.
The public find_sun_crossing function accepts targets from 0° inclusive to 360° exclusive. Although 360° and 0° name the same direction geometrically, callers must supply 0°. The wrapper rejects 360°, negative numbers, infinity and NaN, the special floating-point value meaning “not a number.” The internal solver normalizes its target, but that does not relax the public validation rule.
Next comes a coverage check. For an invented published interval [0, 1000] days, a starting time of day 100 passes: subtracting the required 89 days gives day 11, still inside the interval. Day 88 fails because its lookback reaches day −1. This check applies even to a forward request. The upper endpoint is inclusive, so day 1000 passes admission, though future samples may be unavailable.
admit when start − 89 days ≥ lower bound AND start ≤ upper bound
Invalid target values return an InvalidInput error; a failed coverage check returns OutOfCoverage. These happen before the solver searches. The 89-day policy and public input range come from the current implementation. They are interface choices, rather than astronomical laws or historically attributed discoveries.
See the teaching TypeScript
const admitted = (start: number, lower: number, upper: number): boolean => start - 89 >= lower && start <= upper;
const validTarget = (target: number): boolean => target >= 0 && target < 360;Finite, correctly labeled inputs are assumed. This demonstrates the arithmetic; it does not fetch data or replace the engine.
Connect this step to the source
src/search.rs
find_sun_crossing
Paths refer to the astrology-engine repository. Examples use invented inputs; a successful exercise is not an astronomical-accuracy test.
Sources for this section
Apply this step
Answer every part, then check. You can retry as often as you like.
2. Turn relative times into Sun positions
The solver works with offsets from the starting instant. Offset zero means the start itself; +2 means two days later and −2 means two days earlier. The wrapper adds a time-library duration to the starting epoch, converts that new instant to ephemeris seconds, and evaluates the fitted Sun longitude. It does not construct a full chart or consult house cusps.
sample(d) = fitted Sun longitude at (starting epoch + Duration::from_days(d))
If the start is an invented reference instant and d = −0.25 day, the sample is six hours, or 21,600 seconds, earlier. Multiplying by 86,400 converts a duration from days to seconds. It does not convert an epoch between time scales; the runtime performs its epoch conversion separately before accessing the fitted series.
A failed longitude evaluation becomes NaN in this wrapper. The solver receives that nonfinite number rather than an Evaluation error. A missing crossing is represented by Ok(None); a found offset becomes Ok(Some(epoch)). This distinguishes admission errors from an admitted search that produced no time. None does not prove that the Sun never reaches the target: coverage gaps, the finite scan and sampling rules can prevent a result.
This sampling callback is a software boundary: it connects a solver expressed in relative days to a dataset expressed in ephemeris seconds. No historical inventor is claimed for the repository’s choice to translate failed samples to NaN.
Connect this step to the source
src/search.rs
find_sun_crossing
Paths refer to the astrology-engine repository. Examples use invented inputs; a successful exercise is not an astronomical-accuracy test.
Sources for this section
Apply this step
Answer every part, then check. You can retry as often as you like.
3. Separate admission from sampling reach
Passing the first check reserves a particular lookback interval; it does not reserve every time the search may sample. The fallback scan can take one-day steps as far as 730 days from the start. Its bound is much wider than 89 days and follows the requested direction.
Use the same invented published interval [0, 1000] days and start at day 100. Admission passes, but a backward scan at offset −101 asks for day −1. A forward scan at offset +730 asks for day 830, inside the published interval. Start at day 900 instead: admission still passes, but offset +101 reaches day 1001, beyond its upper edge. Published coverage and fitted support are distinct; evaluating longitude ultimately depends on the stored series support.
89 × 86,400 = 7,689,600 seconds; scan offsets reach ±730 days in the chosen direction
The backward Sun path first tries an estimated bracket, explained in the later acceleration lesson. Daily scanning is its fallback and the direct forward path. Thus 730 days is a coarse-scan bound, not a promise that every sample used by every branch is contained in an admitted interval. These constants document current policy without asserting a historical origin or universal search guarantee.
Connect this step to the source
src/coverage_window.rs
CoverageWindow::contains_with_lookback; DESIGN_LOOKBACK_S
Paths refer to the astrology-engine repository. Examples use invented inputs; a successful exercise is not an astronomical-accuracy test.
Sources for this section
Apply this step
Answer every part, then check. You can retry as often as you like.
Your lesson checks
0 of 3 steps passed.
Use the feedback beside each check to retry any unfinished step.