Silnik B: /houses + nocny przemiał wyroczni; ε prawdziwe zamiast średniego #65

Merged

gitea merged 1 commits from feat/oracle-etap4 into master 2026-08-06 11:38:36 +00:00

Conversation 0 Commits 1 Files Changed 7

+245 -8

gitea commented 2026-08-06 10:22:49 +00:00

Owner

Copy Link

Copy Source

Etap 4 — z jedną zmianą planu i jednym błędem znalezionym po drodze.

/houses w silniku B

Domyka kontrakt parzystości (LOG-28) po stronie domów. Dotąd obejmował tylko pozycje obiektów, więc błąd w podziale na domy przechodził przez porównanie silników niezauważony — a błąd w domach jest cichy: wykres wygląda poprawnie, tylko planety siedzą gdzie indziej.

Nazwy systemów są nasze (te same co houses.SYSTEMS), więc wołający nie musi znać liter swissepha. Poza dziedziną → 422 z powodem, nigdy ciche podstawienie innego systemu.

Przemiał: nocne CI zamiast CronJoba w klastrze

Plan zakładał Job w k3s, bo „duży przemiał jest kosztowny". Zmierzyłem — nie jest:

przypadków	porównań	czas
20 000	2,8 mln	2,8 s
100 000	14 mln	12,3 s
500 000	70 mln	64 s

Skalowanie liniowe. Osobny obraz w rejestrze (który już raz zapchał dysk hosta), manifest, CronJob i kopia harnessu poza repo byłyby infrastrukturą do problemu, którego nie ma — a każda kopia harnessu poza repo to ryzyko cichego rozjazdu z kodem, który ma testować.

Zamiast tego workflow z harmonogramem: co noc inne ziarno, więc dziedzina przeczesuje się z czasem gęściej niż pojedynczym przebiegiem. Zestaw brzegowy nadal blokuje każdy build.

Jeśli wolisz mimo to Job w klastrze — powiedz, dorobię; chciałem tylko, żeby decyzja zapadła na pomiarze, a nie na założeniu.

ε prawdziwe — błąd znaleziony przy okazji

Silnik liczył RAMC z GAST (czas gwiazdowy pozorny, od równonocy prawdziwej), ale parował go z ε średnim, bez nutacji. To nie wybór konwencji, tylko pomieszanie dwóch układów odniesienia.

• do 3,2″ przesunięcia na cuspach domów
• niespójne ε dla deklinacji i antyscji, liczonych z pozycji pozornych

ε pochodzi teraz z serii IAU 2000A — z tego samego źródła, którego Skyfield używa do GAST, więc oba są spójne z definicji. Zweryfikowane: nasze ε = 23,44232957°, swisseph podaje 23,4423295.

Framework wyroczni nie mógł tego wykryć. Z założenia podaje to samo ε obu stronom, żeby izolować samą funkcję domów — więc błąd w danych wejściowych świecił na zielono przez cały czas. Wejście ma teraz własny sprawdzian ze Skyfieldem jako niezależnym autorytetem (bez swissepha, działa wszędzie), a luka jest opisana wprost w tests/oracle/README.md: poprzedni tekst twierdził, że ε jest testowane. Nie było.

Czego NIE zmieniam

Porównanie „cały horoskop nasz vs swissepha" zostawia resztę ~3″ nawet po naprawie ε. To UT1 kontra UTC: Skyfield konwertuje z tablic IERS, swisseph przyjmuje podany JD jako UT1. Dla 1984-04-30 różnica to 0,181 s, a UT1−UTC tego dnia wynosiło 0,1810 s — zgadza się co do trzeciego miejsca. Podanie swissephowi JD w UT1 kasuje rozjazd do 0,00065″. Nasza strona jest dokładniejsza, więc zostaje jak jest.

Weryfikacja

• wyrocznia, zestaw brzegowy: 13 systemów OK
• suity: logika 327, prezentacja 256, render 41, dane 13 — zielone
• /houses: wszystkie 13 systemów liczy, oba przypadki poza dziedziną dają 422 (w smoke teście CI, wewnątrz obrazu)

🤖 Generated with Claude Code

Etap 4 — z jedną zmianą planu i jednym błędem znalezionym po drodze. ## `/houses` w silniku B Domyka kontrakt parzystości (LOG-28) po stronie **domów**. Dotąd obejmował tylko pozycje obiektów, więc błąd w podziale na domy przechodził przez porównanie silników niezauważony — a błąd w domach jest cichy: wykres wygląda poprawnie, tylko planety siedzą gdzie indziej. Nazwy systemów są **nasze** (te same co `houses.SYSTEMS`), więc wołający nie musi znać liter swissepha. Poza dziedziną → **422 z powodem**, nigdy ciche podstawienie innego systemu. ## Przemiał: nocne CI zamiast CronJoba w klastrze Plan zakładał Job w k3s, bo „duży przemiał jest kosztowny". **Zmierzyłem — nie jest:** | przypadków | porównań | czas | |---|---|---| | 20 000 | 2,8 mln | 2,8 s | | 100 000 | 14 mln | 12,3 s | | 500 000 | 70 mln | 64 s | Skalowanie liniowe. Osobny obraz w rejestrze (który już raz zapchał dysk hosta), manifest, CronJob i kopia harnessu poza repo byłyby infrastrukturą do problemu, którego nie ma — a każda kopia harnessu poza repo to ryzyko cichego rozjazdu z kodem, który ma testować. Zamiast tego workflow z harmonogramem: co noc **inne ziarno**, więc dziedzina przeczesuje się z czasem gęściej niż pojedynczym przebiegiem. Zestaw brzegowy nadal blokuje każdy build. Jeśli wolisz mimo to Job w klastrze — powiedz, dorobię; chciałem tylko, żeby decyzja zapadła na pomiarze, a nie na założeniu. ## ε prawdziwe — błąd znaleziony przy okazji Silnik liczył RAMC z **GAST** (czas gwiazdowy pozorny, od równonocy **prawdziwej**), ale parował go z ε **średnim**, bez nutacji. To nie wybór konwencji, tylko pomieszanie dwóch układów odniesienia. - do **3,2″** przesunięcia na cuspach domów - niespójne ε dla deklinacji i antyscji, liczonych z pozycji **pozornych** ε pochodzi teraz z serii IAU 2000A — z tego samego źródła, którego Skyfield używa do GAST, więc oba są spójne z definicji. Zweryfikowane: nasze ε = 23,44232957°, swisseph podaje 23,4423295. **Framework wyroczni nie mógł tego wykryć.** Z założenia podaje to samo ε obu stronom, żeby izolować samą funkcję domów — więc błąd w danych *wejściowych* świecił na zielono przez cały czas. Wejście ma teraz własny sprawdzian ze Skyfieldem jako niezależnym autorytetem (bez swissepha, działa wszędzie), a luka jest opisana wprost w `tests/oracle/README.md`: poprzedni tekst twierdził, że ε jest testowane. Nie było. ### Czego NIE zmieniam Porównanie „cały horoskop nasz vs swissepha" zostawia resztę ~3″ nawet po naprawie ε. To **UT1 kontra UTC**: Skyfield konwertuje z tablic IERS, swisseph przyjmuje podany JD jako UT1. Dla 1984-04-30 różnica to 0,181 s, a UT1−UTC tego dnia wynosiło 0,1810 s — zgadza się co do trzeciego miejsca. Podanie swissephowi JD w UT1 kasuje rozjazd do 0,00065″. **Nasza strona jest dokładniejsza**, więc zostaje jak jest. ## Weryfikacja - wyrocznia, zestaw brzegowy: 13 systemów OK - suity: logika 327, prezentacja 256, render 41, dane 13 — zielone - `/houses`: wszystkie 13 systemów liczy, oba przypadki poza dziedziną dają 422 (w smoke teście CI, wewnątrz obrazu) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea added 1 commit 2026-08-06 10:22:49 +00:00

feat(silnik B): endpoint /houses + nocny przemiał; ε PRAWDZIWE zamiast średniego ... 21a00b0000

Etap 4, z jedną istotną zmianą planu i jednym znalezionym błędem.

/houses W SILNIKU B
Domyka kontrakt parzystości (LOG-28) po stronie domów — dotąd obejmował tylko
pozycje obiektów, więc błąd w podziale na domy przechodził przez porównanie
silników niezauważony. Nazwy systemów są NASZE (te same, co houses.SYSTEMS),
więc wołający nie musi znać liter swissepha; rozjazd tych dwóch list oznaczałby,
że parzystość przestała obejmować część systemów.

Poza dziedziną (Placidus/Koch za kołem podbiegunowym) zwracamy 422 z powodem,
a NIE podstawiamy po cichu innego systemu — cicha podmiana jest po stronie
wołającego niewykrywalna, a to on ma zdecydować, co z tym zrobić.

PRZEMIAŁ: NOCNE CI ZAMIAST CRONJOBA W KLASTRZE
Plan zakładał Job w k3s, bo „duży przemiał jest kosztowny". Pomiar tego nie
potwierdził: 500 000 przypadków × 13 systemów = 70 mln porównań w 64 sekundy,
skalowanie liniowe (20k→2,8 s, 100k→12,3 s, 500k→64 s). Osobny obraz w rejestrze,
manifest, CronJob i kopia harnessu poza repo byłyby infrastrukturą do problemu,
którego nie ma — a kopia harnessu poza repo to ryzyko cichego rozjazdu z kodem,
który ma testować. Workflow z harmonogramem daje to samo: co noc inne ziarno,
więc dziedzina przeczesuje się z czasem gęściej niż pojedynczym przebiegiem.

ε PRAWDZIWE — BŁĄD ZNALEZIONY PRZY OKAZJI
Silnik liczył RAMC z GAST (czas gwiazdowy POZORNY, mierzony od równonocy
PRAWDZIWEJ), ale parował go z ε ŚREDNIM, czyli bez nutacji. To nie wybór
konwencji, tylko pomieszanie dwóch układów odniesienia. Skutek: do 3,2″ na
cuspach domów oraz niespójne ε dla deklinacji i antyscji, liczonych z pozycji
POZORNYCH. Teraz ε pochodzi z serii IAU 2000A — z tego samego źródła, którego
Skyfield używa do GAST, więc oba są spójne z definicji.

Framework wyroczni tego NIE MÓGŁ wykryć: z założenia podaje to samo ε obu
stronom, żeby izolować samą funkcję domów. Błąd siedział w danych WEJŚCIOWYCH,
nie w testowanej funkcji — i cały czas świecił na zielono. Wejście ma więc teraz
własny sprawdzian, ze Skyfieldem jako niezależnym autorytetem (bez swissepha,
więc działa w każdym środowisku). Luka opisana wprost w tests/oracle/README.md,
bo poprzedni tekst twierdził, że ε jest testowane — nie było.

Reszta ~3″ przy porównaniu „cały horoskop nasz vs swissepha" to UT1 kontra UTC:
Skyfield konwertuje z tablic IERS, swisseph przyjmuje podany JD jako UT1 (dla
1984-04-30 różnica 0,181 s = 2,7″ RAMC — zgadza się co do trzeciego miejsca).
Podanie swissephowi JD w UT1 kasuje ją do 0,00065″. Nasza strona jest dokładniejsza;
niczego tu nie zmieniam.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

gitea merged commit 21a00b0000 into master 2026-08-06 11:38:36 +00:00

gitea deleted branch feat/oracle-etap4 2026-08-06 11:38:36 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

gitea

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/astrololo#65