Precyzja obliczeń
AstroWay API używa Swiss Ephemeris (oficjalny kod C od Astrodienst, twórców astro.com) - tego samego silnika, na którym profesjonalni astrolodzy od ponad 30 lat pracują w Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mies) i Janus. Zbudowaliśmy go w WebAssembly i udostępniliśmy jako warstwę REST API, bez pośredniej marży. Każdy z podstawowych endpointów obliczeniowych jest pokryty testami regression snapshot; dokładność silnika jest zweryfikowana poprzez triangulację z trzema niezależnymi źródłami + w porównaniu z NASA 5-Millennium Eclipse Catalog:
- Pozycje planet: mediana
0.0013", maksimum0.561"vs oficjalnego swetest CGI Astrodienst (zmierzono 2026-07-29 na 130 pomiarach). Rozkład dla ciał poniżej - Kuspisy domów Placidus:
0.000"dokładne dopasowanie - Zaćmienia:
< 1 minutavs NASA Eclipse Catalog - Linie ACG:
< 1.5 kmna równiku vs swetest - Wschód/zachód słońca:
< 10 sekundvs timeanddate.com - Moon VOC, ingresy, koniunkcje planet: dokładność do ułamka sekundy
Metodologia: jak dokładnie zmierzono
Dział zatytułowany „Metodologia: jak dokładnie zmierzono”Te liczby to nie szacunki, lecz wynik uruchomienia. Skrypt bierze 10 map, rozłożonych od 1900 do 2050 roku, wysyła zapytania o te same momenty do działającego swetest CGI Astrodienst i porównuje wszystkie 13 ciał, które zwracamy. Łącznie 130 pomiarów.
| Ciało | Maksymalny dryf |
|---|---|
| Słońce, Wenus, Saturn | 0.001" |
| Merkury | 0.002" |
| true Node | 0.004" |
| Mars | 0.007" |
| Jowisz | 0.009" |
| Księżyc | 0.022" |
| Uran | 0.083" |
| Pluton | 0.097" |
| Neptun | 0.223" |
| Chiron | 0.561" |
| mean Apogee (Lilith) | 0.000" |
Mediana dla wszystkich 130 pomiarów: 0.0013".
Wcześniej na tej stronie widniała ogólna obietnica „< 0.1 arcsec”. Pomiary z 2026-07-29 wykazały, że Neptun, Pluton i Chiron jej nie utrzymują, dlatego obietnicę zastąpiono faktycznymi liczbami. Chiron i planety zewnętrzne mają większy dryf, ponieważ ich pozycje są pobierane ze skompresowanego zestawu efemeryd w kompilacji WASM.
Możesz to odtworzyć samodzielnie: api-calc/scripts/accuracy-vs-swetest.mjs wykonuje
dokładnie te zapytania i drukuje tę samą tabelę.
Sprawdź sam. Skrypt, którym zmierzono powyższe liczby, znajduje się w publicznym repozytorium na licencji MIT: astroway/astrology-accuracy-benchmark. Działa nie tylko z nami: adapter do dowolnego innego API to trzydzieści linii kodu, więc te same 130 pomiarów można uruchomić przeciwko konkurentowi i porównać. Klucz piaskownicy wystarczy.
| Komponent | Wartość |
|---|---|
| Biblioteka | Swiss Ephemeris C code (aloistr/swisseph) |
| Wersja | upstream Astrodienst C code |
| Bindings | swisseph-wasm (WebAssembly w Node.js) |
| Efemerydy | DE431 JPL ephemeris (przez pliki .se1) |
| Fallback | Moshier analytical (dla dat poza 1800-2399) |
| Code sharing | Shared @/core z app.astroway.info - jeden silnik, dwa transporty |
Metodyka
Dział zatytułowany „Metodyka”Dokładność jest sprawdzana poprzez triangulację - porównanie z trzema niezależnymi źródłami:
1. swetest CGI (referencja)
Dział zatytułowany „1. swetest CGI (referencja)”Oficjalna referencyjna implementacja Swiss Ephemeris od samego Astrodienst - zespołu, który stworzył Astro.com i obsługuje miliony astrologów na całym świecie. Najbardziej autorytatywne publiczne źródło. Nasz silnik jest identyczny (0.00–0.07 sekundy kątowej dryfu).
2. Kerykeion (Python)
Dział zatytułowany „2. Kerykeion (Python)”Niezależna biblioteka Python używająca pyswisseph-bindings zamiast naszego
WASM. Potwierdza, że nasza warstwa WASM nie zniekształca danych.
3. Prokerala API
Dział zatytułowany „3. Prokerala API”Zdalny Swiss Ephemeris API (syderyczny Lahiri). Systemowy dryf 8–17 sekund kątowych jest związany z różnymi wersjami formuły Lahiri ayanamsa, a nie z dokładnością silnika.
Wyniki triangulacji
Dział zatytułowany „Wyniki triangulacji”| Mapa | vs swetest (Astrodienst) | vs Kerykeion (Python) | vs Prokerala API |
|---|---|---|---|
| Monroe 1926 | 0.00” | 0.19” | 16.95” (systemowy) |
| Diana 1961 | 0.00” | 0.69” | 8.18” (systemowy) |
| Einstein 1879 | 0.07” | artefakt LMT Kerykeion | 14.96” (systemowy) |
Zestaw regresyjny na poziomie endpointów
Dział zatytułowany „Zestaw regresyjny na poziomie endpointów”Każdy z podstawowych endpointów obliczeniowych jest pokryty zamrożonymi testami snapshot na 3 referencyjnych mapach (Monroe / Diana / Einstein) = 873 snapshotów.
Zestaw snapshotów wyłapuje:
- Błędy mapowania danych wejściowych - nieprawidłowe id planety, UT, system domów
- Post-processing - zaokrąglanie, konwersja jednostek, utrata znaku
- Rozbieżność domyślnych wartości - mean vs true node, geocentric vs topocentric
- Schema drift - walidacja przepuściła nieprawidłową formę
- Przestarzały deploy - prod dist nie odpowiada kodowi
Tolerancja: 5e-5° (≈0.18 sekundy kątowej) domyślnie dla wszystkich pól numerycznych.
Szczegółowe benchmarki
Dział zatytułowany „Szczegółowe benchmarki”Pozycje planet (tropikalne, vs swetest)
Dział zatytułowany „Pozycje planet (tropikalne, vs swetest)”| Mapa | Data | Maksymalny dryf |
|---|---|---|
| Marilyn Monroe | 1926-06-01 | 0.00” |
| Princess Diana | 1961-07-01 | 0.00” |
| Albert Einstein | 1879-03-14 | 0.07” |
Kuspisy domów Placidus (vs swetest)
Dział zatytułowany „Kuspisy domów Placidus (vs swetest)”| Mapa | dryf ASC | dryf MC | Maksymalny dryf kuspisu |
|---|---|---|---|
| Monroe | 0.000” | 0.000” | 0.000” |
| Diana | 0.000” | 0.000” | 0.000” |
Zaćmienia (vs NASA 5-Millennium Catalog)
Dział zatytułowany „Zaćmienia (vs NASA 5-Millennium Catalog)”| Wydarzenie | Maksimum NASA | Nasze maksimum | Dryf |
|---|---|---|---|
| 2025-03-14 Całkowite Księżycowe | 06:58 UT | 06:58 UT | 0.8 min |
| 2025-03-29 Częściowe Słoneczne | 10:47 UT | 10:47 UT | 0.5 min |
| 2025-09-07 Całkowite Księżycowe | 18:11 UT | 18:11 UT | 0.8 min |
| 2025-09-21 Częściowe Słoneczne | 19:41 UT | 19:42 UT | 1.0 min |
Astrokartografia (vs formuła RA z swetest)
Dział zatytułowany „Astrokartografia (vs formuła RA z swetest)”Wszystkie linie MC/IC/ASC/DSC używają prawidłowej formuły longitude = RA − GMST
(standard Kennetha Bowsera). Dryf od referencji: < 1.5 km na równiku dla
wszystkich planet.
Wschód / Zachód Słońca (vs timeanddate.com)
Dział zatytułowany „Wschód / Zachód Słońca (vs timeanddate.com)”| Lokalizacja | Data | Parametr | Dryf |
|---|---|---|---|
| Londyn | 2026-04-15 | Wschód Słońca | 0.6 s |
| Londyn | 2026-04-15 | Zachód Słońca | 9 s |
Lokalizacje polarne (|lat| > 66.5°) automatycznie zwracają polarState +
ostrzeżenie, że zwykłe godziny planetarne nie są zdefiniowane.
Orbisy aspektów
Dział zatytułowany „Orbisy aspektów”AstroWay używa zmiennych orbisów per-planet (zasada MIN dwóch planet), jak w ZET9 i astro.com. Domyślne orbisy (dla mapy natalnej):
| Aspekt | Słońce | Księżyc | Wewnętrzne | Jowisz | Zewnętrzne |
|---|---|---|---|---|---|
| Koniunkcja | 12° | 10° | 5° | 8° | 5° |
| Sekstyl | 6.5° | 6° | 5° | 5° | 5° |
| Kwadrat | 10° | 8° | 5° | 7° | 5° |
| Trygon | 12° | 8° | 5° | 5° | 5° |
| Opozycja | 12° | 10° | 5° | 8° | 5° |
Aspekty minorowe (36°, 40°, 45°, 72°, 108°, 135°, 144°) są domyślnie
wyłączone. Włączane są jawnie poprzez ALL_ASPECTS.
Szerokości geograficzne polarne
Dział zatytułowany „Szerokości geograficzne polarne”Dla |lat| > 66.5° systemy Placidus / Koch / Regiomontanus są matematycznie nie zdefiniowane. W takich przypadkach Swiss Ephemeris automatycznie zwraca Porphyry, a nasze API dodaje ostrzeżenie:
{ "system": "P", "warning": "Система Placidus не визначена для lat=68.96° (> 66.5°). Swiss Ephemeris підставив Porphyry..."}Ciągła weryfikacja
Dział zatytułowany „Ciągła weryfikacja”Regresja jest sprawdzana przy każdym PR poprzez CI:
api-calc/tests/endpoints/- 873 snapshotów dla referencyjnych map (Monroe / Diana / Einstein) + synastry / composite / davison.github/workflows/api-accuracy.yml- automatyczne uruchamianie przy PR- Triangulacja vs swetest CGI + Kerykeion - co tydzień
- Monitorowanie upstream Swiss Ephemeris poprzez Dependabot
Niezawodność MCP - typowany wynik
Dział zatytułowany „Niezawodność MCP - typowany wynik”Dokładność silnika to połowa zaufania. Druga połowa to kontrakt wyjściowy, który agent (Claude, ChatGPT, Cursor) może walidować. Nasz serwer MCP nie zwraca „surowego tekstu, radź sobie sam”:
- Typowany
structuredContent. Ponad 600 narzędzi MCP, a zdecydowana większość z nich publikuje ścisłeoutputSchema- klient MCP otrzymuje zweryfikowaną strukturę, a nie ciąg znaków, który trzeba parsować na chybił trafił. - Ochrona przed schema drift. Test CI
openapi-example-driftwaliduje każdy regression-snapshot względem schematu, wygenerowanego z jego własnego przykładu: jeśli rzeczywisty wynik endpointu rozejdzie się z opublikowanym schematem, kompilacja zawodzi. To właśnie ta klasa rozbieżności powoduje błąd MCP-32602 Output validation error. - Błędy to błędy. Awaria narzędzia zawsze jest zwracana z flagą
isErrori typowanym kodem (UPPER_SNAKE). Nigdy nie przekazujemy modelowi surowego stack trace’u ani wewnętrznych ścieżek serwera jako „danych”.
Oznacza to, że integracja poprzez MCP jest tak samo przewidywalna, jak bezpośrednie wywołanie REST: to,
co jest opisane w /openapi.json, to właśnie to, co zwraca narzędzie.
Znane ograniczenia
Dział zatytułowany „Znane ograniczenia”- Daty poza zakresem (przed 1800 i po 2399): używany jest Moshier analytical, dokładność ~0.1” (vs < 0.01” dla SWIEPH z plikami DE431)
- True Lilith (id=13) vs Mean Lilith (id=12): różnica do 12° - domyślnie
Mean Lilith (stabilne zachowanie), True Lilith dostępna poprzez
planetIds: [13] - Topocentric vs geocentric: domyślnie geocentric
- Swiss Ephemeris: https://www.astro.com/swisseph/
- swetest CGI: https://www.astro.com/swisseph/swetest.htm
- Katalog zaćmień NASA: https://eclipse.gsfc.nasa.gov/
- Kerykeion: https://github.com/g-battaglia/kerykeion
- Astrodienst: https://www.astro.com/
Kontakt
Dział zatytułowany „Kontakt”W sprawie pytań dotyczących dokładności: napisz na support@astroway.info z danymi mapy i oczekiwaną referencją (astro.com lub inne autorytatywne źródło).