Přesnost výpočtů

TL;DR

AstroWay API používá Swiss Ephemeris (oficiální C‑kód od Astrodienst, tvůrců astro.com) – stejný engine, na kterém profesionální astrologové 30+ let pracují v Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/měs) a Janus. Spouštíme ho na vlastních serverech a poskytujeme jako REST API vrstvu, bez zprostředkovatelské přirážky. Každý ze základních výpočetních endpointů je pokryt regression snapshot testy; přesnost engine je ověřena pomocí triangulation se třemi nezávislými zdroji + proti NASA 5-Millennium Eclipse Catalog:

Planetární pozice: medián 0.0013", maximum 0.561" vs oficiálního swetest CGI Astrodienst (měřeno 2026-07-29 na 130 měřeních). Rozpis podle těles níže
Nezávislý běh cizím benchmarkem (RoxyAPI, proti NASA JPL Horizons DE441): 210 z 210 v mezích tolerance, medián 0.11", maximum 0.60"
Kuspy domů Placidus: 0.000" exact match
Zatmění: < 1 minuta vs NASA Eclipse Catalog
ACG linie: < 1.5 km na rovníku vs swetest
Sunrise/sunset: < 10 sekund vs timeanddate.com
Moon VOC, ingresses, planet conjunctions: přesnost do zlomku sekundy

Metodologie: jak bylo měřeno

Tyto čísla nejsou odhad, ale výsledek běhu. Skript vezme 10 map, rozprostřených od 1900 do 2050, požádá o stejné okamžiky živý swetest CGI Astrodienst a porovná všech 13 těles, která poskytujeme. Celkem 130 měření.

Těleso	Maximální drift
Slunce, Venuše, Saturn	`0.001"`
Merkur	`0.002"`
true Node	`0.004"`
Mars	`0.007"`
Jupiter	`0.009"`
Měsíc	`0.022"`
Uran	`0.083"`
Pluto	`0.097"`
Neptun	`0.223"`
Chiron	`0.561"`
mean Apogee (Lilith)	`0.000"`

Medián ze všech 130 měření: 0.0013".

Dříve na této stránce byla obecná slib ”< 0.1 arcsec”. Měření 2026-07-29 ukázala, že Neptun, Pluto a Chiron ji nedodržují, takže slib byl nahrazen konkrétními čísly. Chiron a vnější planety mají větší drift kvůli tomu, že jejich pozice jsou brány z komprimované sady efemerid, kterou používá naše sestava.

Můžeš to reprodukovat sám: api-calc/scripts/accuracy-vs-swetest.mjs provede právě tyto požadavky a vytiskne stejnou tabulku.

Ověřte si to sami. Skript, který měřil výše uvedená čísla, leží v veřejném repozitáři pod MIT: astroway/astrology-accuracy-benchmark. Funguje nejen s námi: adaptér na jakékoli jiné API je třicet řádků, takže stejných 130 měření lze spustit proti konkurenci a porovnat. Klíč sandboxu stačí.

Engine

Komponent	Hodnota
Knihovna	Swiss Ephemeris C code (aloistr/swisseph)
Verze	upstream Astrodienst C code
Efemeridy	DE431 JPL ephemeris (prostřednictvím .se1 souborů)
Fallback	Moshier analytical (pro data mimo 1800-2399)
Sdílení kódu	Shared `@/core` z app.astroway.info – jeden engine, dva transporty

Metodika

Přesnost se ověřuje pomocí triangulation – porovnání se třemi nezávislými zdroji:

1. swetest CGI (referenční)

Oficiální reference-implementation Swiss Ephemeris od samotných Astrodienst – týmu, který vytvořil Astro.com a obsluhuje miliony astrologů po celém světě. Nejautoritativnější veřejný zdroj. Náš engine identický (0.00–0.07 úhlové sekundy driftu).

2. Kerykeion (Python)

Nezávislá Python knihovna používá pyswisseph-bindings, nezávislé na naší sestavě. Potvrzuje, že naše vrstva obálky nezkresluje data.

3. Prokerala API

Vzdálené Swiss Ephemeris API (sidereal Lahiri). Systematický drift 8–17 úhlových sekund souvisí s různými verzemi vzorce Lahiri ayanamsa, a ne s přesností engine.

Výsledky triangulation

Mapa	proti swetest (Astrodienst)	proti Kerykeion (Python)	proti Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (systemic)
Diana 1961	0.00”	0.69”	8.18” (systemic)
Einstein 1879	0.07”	LMT-artefakt Kerykeion	14.96” (systemic)

Nezávislé ověření cizím nástrojem

RoxyAPI zveřejňuje vlastní benchmark proti NASA JPL Horizons DE441: MIT licence, pouze standardní knihovna, 21 map a 210 pozic, a přepínač --base-url, aby ho nasměroval na jakékoli jiné API. V jejich README je přímo řečeno, že tolerance byly úmyslně nenastavovány na jejich vlastní engine, protože benchmark, který navrhuje ověřit konkurenta, musí být férový.

Nasmerovali jsme ho na sebe, aniž bychom v jejich kódu změnili jakékoli číslo. Adaptér přejmenuje jedno pole požadavku a odstraní jednu obálku odpovědi.

	AstroWay	RoxyAPI, jejich běh 2026-09-29
V mezích tolerance	210 z 210	210 z 210
Medián odchylky	`0.11"`	`0.05"`
Maximum	`0.60"`	`0.78"`

Naše měření 2026-09-09, cena 21 požadavků na API. RoxyAPI v září přešli na přímé čtení DE440, a jejich medián je nyní nižší než náš; náš maximum je nižší než jejich. Pořadový výpis všech 210 řádků: CSV.

Regression sada na úrovni endpointů

Každý ze základních výpočetních endpointů je pokryt zmraženými snapshot testy na 3 referenčních mapách (Monroe / Diana / Einstein) = 873 snapshotů.

Snapshot-suite chytá:

Chyby mapování vstupních dat: nesprávné id planety, UT, systém domů
Post-processing: zaokrouhlování, konverze jednotek, ztráta znaménka
Rozdíly výchozích hodnot: mean vs true node, geocentric vs topocentric
Schema drift: validace prošla nesprávnou formou
Zastaralý deployment: prod dist neodpovídá kódu

Tolerance: 5e-5° (≈0.18 úhlové sekundy) ve výchozím nastavení pro všechna číselná pole.

Detailní benchmarky

Pozice planet (tropické, proti swetest)

Mapa	Datum	Maximum drift
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Kuspy domů Placidus (proti swetest)

Mapa	drift ASC	drift MC	Maximum drift kuspy
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Zatmění (proti NASA 5-Millennium Catalog)

Událost	Maximum NASA	Náš maximum	Drift
2025-03-14 Lunar Total	06:58 UT	06:58 UT	0.8 min
2025-03-29 Solar Partial	10:47 UT	10:47 UT	0.5 min
2025-09-07 Lunar Total	18:11 UT	18:11 UT	0.8 min
2025-09-21 Solar Partial	19:41 UT	19:42 UT	1.0 min

Astrokartografie (proti vzorci RA ze swetest)

Linie MC a IC jsou konstruovány podle vzorce longitude = RA − GMST (standard Kenneth Bowser). Drift od referenčního: < 1.5 km na rovníku pro všechny planety.

Horizontální linie ASC a DSC se počítají z rovnice horizontu ve stejných ekvatoriálních souřadnicích: cos H = -tan φ · tan δ, kde H = (GMST + lng) − RA. Polovinám se liší znaménko hodinového úhlu: při H < 0 je těleso východnější než meridián, tedy vychází. Kontrola, kterou provádíme při každém běhu: vezme se každý bod každé horizontální křivky a spočítá se výška tělesa nad horizontem v ní. Na 8419 bodech je maximální odchylka 0.0 km, tedy těleso skutečně stojí na horizontu všude, kde jsme linii provedli.

Do 2026-08-12 horizontální křivky řešily jinou rovnici (“toto ekliptické délka na ascendentu”), a dvě poloviny se lišily invertovaným testem, takže ASC byl tam, kde těleso zapadá. MC a IC nebyly nikdy zasaženy.

Druhá, méně nápadná polovina téže chyby: stará rovnice ignorovala ekliptickou šířku tělesa, takže linie se odchylovala úměrně, přibližně 103 km za každý stupeň šířky. Na mapě Marilyn Monroe to je 0 km pro Slunce a uzly, 22 km pro Merkuru, 161 km pro Pluto, 285 km pro Měsíc, 345 km pro Lilith. Na mapách, kde těleso stojí vysoko nad ekliptikou, odchylka dosahovala více než 1500 km.

Co to znamená pro tvůj kód. Pokud jsi obcházel předchozí chybu, měněním ASC a DSC místy u sebe, odstraň tento obcházek. Pokud jsi četl pole knownDefect, už v odpovědích není. Souřadnice horizontálních liní pro tělesa s výraznou ekliptickou šířkou se změnily, takže cachované mapy je potřeba přestavět.

Východ / Západ Slunce (proti timeanddate.com)

Lokace	Datum	Parametr	Drift
London	2026-04-15	Sunrise	0.6 s
London	2026-04-15	Sunset	9 s

Polární lokality (|lat| > 66.5°) automaticky vrací polarState + warning, že běžné planetary hours nejsou definovány.

Orbity aspektů

AstroWay používá proměnné orbity per-planet (pravidlo MIN dvou planet), jako v ZET9 a astro.com. Orbity ve výchozím nastavení (pro natal chart):

Aspekt	Sun	Moon	Inner	Jupiter	Outer
Conjunction	12°	10°	5°	8°	5°
Sextile	6.5°	6°	5°	5°	5°
Square	10°	8°	5°	7°	5°
Trine	12°	8°	5°	5°	5°
Opposition	12°	10°	5°	8°	5°

Minorní aspekty (36°, 40°, 45°, 72°, 108°, 135°, 144°) ve výchozím nastavení vypnuté. Zapínají se explicitně přes ALL_ASPECTS.

Polární šířky

Pro |lat| > 66.5° jsou systémy Placidus / Koch / Regiomontanus matematicky nedeterminovatelné. V takových případech Swiss Ephemeris automaticky vrací Porphyry, a naše API přidává warning:

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

Kontinuální kontrola

Regression je kontrolována na každý PR přes CI:

api-calc/tests/endpoints/: 873 snapshotů proti referenčním mapám (Monroe / Diana / Einstein) + synastry / composite / davison
.github/workflows/api-accuracy.yml: automatické spuštění na PR
Triangulation proti swetest CGI + Kerykeion: týdně
Monitoring upstream Swiss Ephemeris přes Dependabot

Spolehlivost MCP: typizovaný výstup

Přesnost engine - polovina důvěry. Druhá polovina - kontrakt výstupu, který agent (Claude, ChatGPT, Cursor) může validovat. Náš MCP server nevrací “raw text, rozbalte si to sami”:

Typizovaný structuredContent. Více než 600 MCP nástrojů, a většina z nich publikuje přísný outputSchema – MCP-klient získá validovanou strukturu, ne řetězec, který je potřeba parsovat náhodně.
Ochrana před schema drift. CI-test openapi-example-drift validuje každý regression-snapshot proti schématu, odvozenému z jeho vlastního příkladu: pokud skutečný výstup endpointu se liší od publikovaného schématu, sestavení selže. Právě tato třída nesouladů způsobuje chybu MCP -32602 Output validation error.
Chyby: to jsou chyby. Selhání nástroje vždy vrací s příznakem isError a typizovaným kódem (UPPER_SNAKE). My nikdy nevracíme modelu raw stack trace nebo interní cesty serveru jako “data”.

Takže integrace přes MCP je stejně předvídatelná jako přímé REST volání: to, co je popsáno v /openapi.json, – je to, co nástroj vrací.

Známá omezení

Data mimo rozsah (do 1800 a po 2399): používá se Moshier analytical, přesnost ~0.1” (proti < 0.01” pro SWIEPH s soubory DE431)
True Lilith (id=13) vs Mean Lilith (id=12): rozdíl až 12° – ve výchozím nastavení Mean Lilith (stabilní chování), True Lilith dostupný přes planetIds: [13]
Topocentric vs geocentric: ve výchozím nastavení geocentric