Commit Graph
3 Commits
Author SHA1 Message Date
SenrokaiandClaude Opus 5.5 18faa6d0b2 Classify a star for the rows that list it, not every star each time the index is built
The search index and the route index gave every one of the 455 571 stars a subtitle up front
through spectralClassification, which filtered the dwarf table afresh on each call; the star
field's tints read the same table once per BP−RP star. Both indices now carry the star itself
and classify it only for the rows shown (entrySubtitle): eight search results, a few route
options. The two filtered columns of the table are built once.

Node, over the shipped catalogue, five runs: classifying every star 121-167 ms before, 56-62
after hoisting the table alone; reading the sequence at every BP−RP colour 187-216 ms, now
111-127. In the app on :4302, two cold loads each, the long task when the Search tab opens was
264-380 ms (median 280) before and 164-276 ms (median 171) after; the longest boot task 863 and
875 ms before, 654 and 741 after.

Tests: the search spec checks its index holds no classification and the row still reads
"Star · ~M8"; the scene spec now reads the route options, and checks its index holds none either.
Controls: classifying every star in the search index, doing so in the route index, and route
options printing the index's subtitle each fail the named test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:30:53 +02:00
SenrokaiandClaude Opus 5.5 f8af0ecf6e List stars in search and routes by the type their colour gives them, and say where archive positions come from
5333be6 gave the star card an estimated type for the 383 695 stars the ETL files as "Unknown",
but search rows, the route search index and the current-star route option still printed that
literal: TRAPPIST-1 read "STAR · UNKNOWN" in search beside "Spectral type ~M8, from colour" on its
card, audit #17's own symptom. spectralClassification (spectral.ts) now gives the catalogue's type,
else the colour's marked "~", else nothing, and all three and the card's subtitle use it; a search
row with nothing to add prints its kind alone rather than a trailing " · ".

The neighbourhood note still read "Positions from measured parallaxes" after 4c8e4a0 placed 3 277
stars at the Exoplanet Archive's sy_dist, 343 of them without a usable parallax and 281 of those
past 1 kpc — microlensing hosts such as OGLE-2005-BLG-390L at 6.6 kpc, from a lensing model.
positionsNote now says so, with the count. Neither the note nor the census subtitle (audit #16) had
a test: putting back "Hipparcos · Yale Bright Star · Gliese" passed all 775.

In the app on :4302: the note reads "Positions from measured parallaxes, and for the 3,277 planet
hosts only the NASA Exoplanet Archive places, from its distances. Grid marks the galactic plane
through the Sun."; search reads "TRAPPIST-1 STAR · ~M8", "OGLE-2005-BLG-390L STAR", "Sirius STAR ·
A0M"; TRAPPIST-1's route option has subtitle "~M8".

The scene spec gains an archive-placed fixture star. Controls, each failing its named test: the
search row printing the raw type, keeping the separator with nothing after it, the route index
and the current-star option printing the raw type, the note back to parallaxes only, the subtitle
back to the old catalogue list (1 of 797 each), the note never counting the archive (2 of 797),
and the classification without its estimate (3 of 797).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:42:03 +02:00
Claude dad4b93e8a Rank search results instead of taking the first eight
Search scanned the index in construction order — 8750 stars, then 18 bodies,
then 6319 exoplanets — collected substring matches, and stopped at eight. With
no scoring, position in the index decided everything.

Typing "Io" returned eight stars named "Iot Cas", "Iot Eri" and so on, and never
reached the moon Io — despite Io being an *exact* match, because the scan had
already filled up 8750 entries before the bodies begin. "Kepler" returned
Kepler-939 b, Kepler-1292 b, Kepler-223 d and five more in whatever order the
archive happened to list them.

Everything is now scored before anything is taken, so where an entry sits in the
index cannot hide a better match. Exact beats prefix beats word-start beats
substring, with the gaps wide enough that a worse kind of match can never
outrank a better one. Ties break on kind — the eighteen solar-system bodies
first, then stars, then exoplanets, so "Proxima" offers the star before its own
planets — then on name length, then alphabetically, so the order is fully
determined rather than inherited from the input. Matching is punctuation
insensitive as well as case insensitive, so "gl357" finds "Gl 357".

"Io" now returns the moon first. "Kepler" returns Kepler-4 b through Kepler-9 d.

The index is pre-normalised once on load rather than per keystroke. Lowercasing,
stripping punctuation and splitting 15,000 names on every character typed costs
about 11 ms, which is most of a frame, and search shares a thread with the render
loop — so it stuttered the scene while typing. Precomputing takes a broad query
down to 2.5 ms and a narrow one to 0.5 ms, for one 15 ms build during the
existing data load.

Adds the first tests this component has had, alongside the ranking's own.

Tests: 237 passing, up from 206. Verified in a real browser.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G
2026-08-04 11:55:34 +00:00