Számítások pontossága

TL;DR

Az AstroWay API a Swiss Ephemeris-t (az Astrodienst, az astro.com alkotóinak hivatalos C-kódja) használja – ugyanazt a motort, amellyel a professzionális asztrológusok több mint 30 éve dolgoznak a Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/hó) és Janus programokban. Saját szervereinken üzemeltetjük, és REST API rétegen keresztül szolgáltatjuk, közvetítői felár nélkül. Minden alapvető számítási végpont regression snapshot-tesztekkel van lefedve; a motor pontosságát triangulációval ellenőriztük három független forrással szemben, valamint a NASA 5-Millennium Eclipse Catalog ellen:

Bolygópozíciók: medián 0.0013", maximum 0.561" vs hivatalos swetest CGI Astrodienst (2026-07-29-én 130 mérés alapján). A testek szerinti bontás alább található
Független futtatás külső benchmarkkal (RoxyAPI, NASA JPL Horizons DE441 ellen): 210-ből 210 a tűréshatáron belül, medián 0.11", maximum 0.60"
Placidus házcsúcsok: 0.000" pontos egyezés
Fogyatkozások: < 1 perc vs NASA Eclipse Catalog
ACG vonalak: < 1.5 km az Egyenlítőn vs swetest
Napkelte/napnyugta: < 10 másodperc vs timeanddate.com
Hold VOC, ingresses, bolygó konjunkciók: másodperc törtrészének pontosságával

Metodológia: hogyan mértük

Ezek a számok nem becslések, hanem futtatási eredmények. A szkript 10, 1900 és 2050 között elosztott térképet vesz alapul, lekérdezi ugyanazokat a pillanatokat az élő swetest CGI Astrodiensttől, és összehasonlítja mind a 13 testet, amit visszaadunk. Összesen 130 mérés.

Test	Maximális eltérés
Nap, Vénusz, Szaturnusz	`0.001"`
Merkúr	`0.002"`
true Node	`0.004"`
Mars	`0.007"`
Jupiter	`0.009"`
Hold	`0.022"`
Uránusz	`0.083"`
Plútó	`0.097"`
Neptunusz	`0.223"`
Chiron	`0.561"`
átlagos Apogeum (Lilith)	`0.000"`

Medián az összes 130 mérésre: 0.0013".

Korábban ezen az oldalon egy általános ígéret szerepelt ”< 0.1 ívmásodperc”. A 2026-07-29-i mérések kimutatták, hogy a Neptunusz, Plútó és Chiron nem tartja ezt, ezért az ígéretet tényleges számokra cseréltük. Chiron és a külső bolygók nagyobb eltérést mutatnak, mivel pozícióikat egy tömörített efemerida-készletből veszi a buildünk.

Reprodukálható önállóan: az api-calc/scripts/accuracy-vs-swetest.mjs pontosan ezeket a lekérdezéseket hajtja végre és ugyanazt a táblázatot nyomtatja.

Ellenőrizd magad. A szkript, amellyel a fenti számokat mértük, nyilvános MIT licencű tárolóban található: astroway/astrology-accuracy-benchmark. Nem csak velünk működik: egy adapter bármely más API-hoz harminc sor, így ugyanazt a 130 mérést futtathatod egy versenytárs ellen és összehasonlíthatod. Egy sandbox kulcs elegendő.

Motor

Komponens	Érték
Könyvtár	Swiss Ephemeris C kód (aloistr/swisseph)
Verzió	upstream Astrodienst C kód
Efemerida	DE431 JPL efemerida (.se1 fájlokon keresztül)
Tartalék	Moshier analytical (1800-2399 közötti dátumokra)
Kódmegosztás	Megosztott `@/core` az app.astroway.info-val - egy motor, két transzport

Metodika

A pontosságot triangulációval ellenőrizzük – három független forrással való összehasonlítással:

1. swetest CGI (referencia)

A Swiss Ephemeris hivatalos referencia-implementációja magától az Astrodiensttől – az Astro.com-ot létrehozó és világszerte több millió asztrológust kiszolgáló csapattól. A legtekintélyesebb nyilvános forrás. Motorunk azonos (0.00–0.07 ívmásodperc eltérés).

2. Kerykeion (Python)

Független Python-könyvtár, amely pyswisseph-bindingeket használ, függetlenül a buildünktől. Megerősíti, hogy a burkolórétegünk nem torzítja az adatokat.

3. Prokerala API

Távoli Swiss Ephemeris API (sziderikus Lahiri). A 8–17 ívmásodperces szisztematikus eltérés a Lahiri ayanamsa formula különböző verzióival függ össze, és nem a motor pontosságával.

Trianguláció eredményei

Térkép	swetest (Astrodienst) ellen	Kerykeion (Python) ellen	Prokerala API ellen
Monroe 1926	0.00”	0.19”	16.95” (szisztematikus)
Diana 1961	0.00”	0.69”	8.18” (szisztematikus)
Einstein 1879	0.07”	Kerykeion LMT-artefakt	14.96” (szisztematikus)

Független ellenőrzés külső eszközzel

A RoxyAPI saját benchmarkot publikál a NASA JPL Horizons DE441 ellen: MIT-licenc, csak standard könyvtár, 21 térkép és 210 pozíció, és egy --base-url flag, hogy bármely más API-ra célozhassuk. README-jükben egyenesen kijelentik, hogy a tűréshatárokat szándékosan nem igazították a saját motorjukhoz, mert egy benchmarknak, amely egy versenytárs ellenőrzését kínálja, tisztességesnek kell lennie.

Mi magunkra céloztuk, anélkül, hogy egyetlen számot is megváltoztattunk volna a kódjukban. Az adapter átnevez egy lekérdezési mezőt és eltávolít egy válaszburkolót.

	AstroWay	RoxyAPI, a 2026-09-29-i futtatásuk
Tűréshatáron belül	210-ből 210	210-ből 210
Eltérés mediánja	`0.11"`	`0.05"`
Maximum	`0.60"`	`0.78"`

A mi mérésünk 2026-09-09-én, ami 21 API lekérdezésből áll. A RoxyAPI szeptemberben áttért a DE440 közvetlen olvasására, és a mediánjuk most alacsonyabb a miénknél; a mi maximumunk alacsonyabb az övékénél. Az összes 210 sor sorrendi kimenete: CSV.

Regression-készlet a végpontok szintjén

Minden alapvető számítási végpont fagyasztott snapshot-tesztekkel van lefedve 3 referencia térképen (Monroe / Diana / Einstein) = 873 snapshot.

A Snapshot-suite a következőket fogja el:

Bemeneti adatleképezési hibák: helytelen bolygó azonosító, UT, házrendszer
Utófeldolgozás: kerekítés, egységkonverzió, előjelvesztés
Alapértelmezett eltérések: átlagos vs valódi csomópont, geocentrikus vs topocentrikus
Séma eltérés: a validáció kihagyta a helytelen formát
Elavult telepítés: a prod dist nem felel meg a kódnak

Tűréshatár: 5e-5° (≈0.18 ívmásodperc) alapértelmezés szerint minden numerikus mezőre.

Részletes benchmarkok

Bolygópozíciók (tropikus, swetest ellen)

Térkép	Dátum	Maximális eltérés
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Placidus házcsúcsok (swetest ellen)

Térkép	eltérés ASC	eltérés MC	Maximális házcsúcs eltérés
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Fogyatkozások (NASA 5-Millennium Catalog ellen)

Esemény	NASA maximum	A mi maximumunk	Eltérés
2025-03-14 Teljes Holdfogyatkozás	06:58 UT	06:58 UT	0.8 perc
2025-03-29 Részleges Napfogyatkozás	10:47 UT	10:47 UT	0.5 perc
2025-09-07 Teljes Holdfogyatkozás	18:11 UT	18:11 UT	0.8 perc
2025-09-21 Részleges Napfogyatkozás	19:41 UT	19:42 UT	1.0 perc

Asztrokartográfia (RA formula ellen swetestből)

Az MC és IC vonalak a longitude = RA − GMST képlet szerint épülnek fel (Kenneth Bowser szabvány). Eltérés a referenciától: < 1.5 km az Egyenlítőn minden bolygó számára.

Az ASC és DSC horizontális vonalak ugyanazokban az ekvatoriális koordinátákban a horizont egyenletéből számítódnak: cos H = -tan φ · tan δ, ahol H = (GMST + lng) − RA. A felek az óraszög előjelében különböznek: ha H < 0, a test keletre van a meridiántól, azaz felkel. Az ellenőrzés, amit minden futtatáskor végrehajtunk: minden horizontális görbe minden pontját vesszük, és kiszámítjuk a test horizont feletti magasságát abban a pontban. 8419 ponton a maximális eltérés 0.0 km, azaz a test valóban a horizonton áll mindenhol, ahol a vonalat húztuk.

2026-08-12 előtt a horizontális görbék egy másik egyenletet oldottak meg (“ez az ekliptikai hosszúság az aszcendensen”), és a két fél egy invertált tesztben különbözött, ezért az ASC ott állt, ahol a test lenyugszik. Az MC és IC soha nem volt érintett.

Ugyanazon hiba második, kevésbé észrevehető fele: a régi egyenlet figyelmen kívül hagyta a test ekliptikai szélességét, ezért a vonal arányosan eltért tőle, körülbelül 103 km-rel minden szélességi fokonként. Marilyn Monroe térképén ez 0 km a Nap és a csomópontok számára, 22 km a Merkúrnak, 161 a Plútónak, 285 a Holdnak, 345 a Lilithnek. Azokon a térképeken, ahol a test magasan áll az ekliptika felett, az eltérés több mint 1500 km-t is elérte.

Mit jelent ez a kódod számára. Ha megkerülted az előző hibát az ASC és DSC felcserélésével, távolítsd el ezt a megkerülést. Ha olvastad a knownDefect mezőt, az már nincs a válaszokban. A horizontális vonalak koordinátái a jelentős ekliptikai szélességű testek esetében megváltoztak, ezért a gyorsítótárazott térképeket érdemes újraépíteni.

Napkelte / Napnyugta (timeanddate.com ellen)

Helyszín	Dátum	Paraméter	Eltérés
London	2026-04-15	Napkelte	0.6 mp
London	2026-04-15	Napnyugta	9 mp

Sarki helyszínek (|lat| > 66.5°) automatikusan polarState + figyelmeztetést adnak vissza, hogy a szokásos planetáris órák nincsenek meghatározva.

Aspektus orbiszok

Az AstroWay változó orbiszokat használ bolygónként (a két bolygó MIN szabálya), akárcsak a ZET9 és az astro.com. Alapértelmezett orbiszok (születési horoszkóphoz):

Aspektus	Nap	Hold	Belső	Jupiter	Külső
Konjunkció	12°	10°	5°	8°	5°
Sextil	6.5°	6°	5°	5°	5°
Kvadrát	10°	8°	5°	7°	5°
Trigon	12°	8°	5°	5°	5°
Oppozíció	12°	10°	5°	8°	5°

Minor aspektusok (36°, 40°, 45°, 72°, 108°, 135°, 144°) alapértelmezés szerint kikapcsolva. Explicit módon ALL_ASPECTS segítségével kapcsolhatók be.

Sarki szélességek

A |lat| > 66.5° esetén a Placidus / Koch / Regiomontanus rendszerek matematikailag nincsenek meghatározva. Ilyen esetekben a Swiss Ephemeris automatikusan Porphyry-t ad vissza, és az API-nk figyelmeztetést ad hozzá:

{
  "system": "P",
  "warning": "Placidus system is undefined for lat=68.96° (> 66.5°). Swiss Ephemeris fell back to Porphyry..."
}

Folyamatos ellenőrzés

A regressziót minden PR-nél ellenőrizzük CI-n keresztül:

api-calc/tests/endpoints/: 873 snapshot referencia térképek ellen (Monroe / Diana / Einstein) + szinasztria / kompozit / davison
.github/workflows/api-accuracy.yml: automatikus futtatás PR-en
Trianguláció swetest CGI + Kerykeion ellen: hetente
Az upstream Swiss Ephemeris monitorozása Dependabot-on keresztül

MCP megbízhatóság: tipizált kimenet

A motor pontossága a bizalom fele. A másik fele a kimeneti szerződés, amelyet egy ügynök (Claude, ChatGPT, Cursor) validálhat. MCP-szerverünk nem ad vissza “nyers szöveget, oldd meg magad”:

Tipizált structuredContent. Több mint 600 MCP-eszköz létezik, és túlnyomó többségük szigorú outputSchema-t publikál – az MCP-kliens validált struktúrát kap, nem pedig egy véletlenszerűen parse-olandó stringet.
Védelem a séma eltérés ellen. A openapi-example-drift CI-teszt minden regression-snapshotot validál a saját példájából származó séma ellen: ha egy végpont tényleges kimenete eltér a publikált sémától, a build elbukik. Pontosan ez az eltérés okozza az MCP -32602 Output validation error hibát.
Hibák: ezek hibák. Az eszközhiba mindig isError flaggel és tipizált kóddal (UPPER_SNAKE) tér vissza. Soha nem adunk vissza a modellnek nyers stack trace-t vagy belső szerverútvonalakat “adatként”.

Ez azt jelenti, hogy az MCP-n keresztüli integráció ugyanolyan kiszámítható, mint egy közvetlen REST-hívás: ami az /openapi.json-ban le van írva, az az, amit az eszköz visszaad.

Ismert korlátok

Dátumok a tartományon kívül (1800 előtt és 2399 után): Moshier analyticalt használ, pontossága ~0.1” (szemben a < 0.01”-gyel SWIEPH-hez DE431 fájlokkal)
True Lilith (id=13) vs Mean Lilith (id=12): különbség akár 12° – alapértelmezés szerint Mean Lilith (stabil viselkedés), True Lilith elérhető planetIds: [13]-on keresztül
Topocentrikus vs geocentrikus: alapértelmezés szerint geocentrikus