Precisione dei calcoli

In breve

L’API AstroWay utilizza Swiss Ephemeris (il codice C ufficiale di Astrodienst, i creatori di astro.com) - lo stesso motore su cui gli astrologi professionisti lavorano da oltre 30 anni in Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mese) e Janus. Lo eseguiamo sui nostri server e lo forniamo tramite uno strato API REST, senza margini di intermediazione. Ciascuno degli endpoint di calcolo di base è coperto da test di regressione snapshot; la precisione del motore è verificata tramite triangolazione con tre fonti indipendenti + contro il NASA 5-Millennium Eclipse Catalog:

Posizioni planetarie: mediana 0.0013", massimo 0.561" vs CGI swetest ufficiale di Astrodienst (misurato il 2026-07-29 su 130 misurazioni). Dettaglio per corpo celeste di seguito
Esecuzione indipendente con benchmark esterno (RoxyAPI, contro NASA JPL Horizons DE441): 210 su 210 entro la tolleranza, mediana 0.11", massimo 0.60"
Cuspidi delle case Placidus: 0.000" exact match
Eclissi: < 1 minuto vs NASA Eclipse Catalog
Linee ACG: < 1.5 km all’equatore vs swetest
Alba/tramonto: < 10 secondi vs timeanddate.com
Luna VOC, ingressi, congiunzioni planetarie: precisione al frazione di secondo

Metodologia: come sono state misurate

Questi numeri non sono una stima, ma il risultato di un’esecuzione. Lo script prende 10 carte, distribuite dal 1900 al 2050, richiede gli stessi momenti al CGI swetest live di Astrodienst e confronta tutti i 13 corpi celesti che forniamo. In totale 130 misurazioni.

Corpo celeste	Deriva massima
Sole, Venere, Saturno	`0.001"`
Mercurio	`0.002"`
true Node	`0.004"`
Marte	`0.007"`
Giove	`0.009"`
Luna	`0.022"`
Urano	`0.083"`
Plutone	`0.097"`
Nettuno	`0.223"`
Chirone	`0.561"`
mean Apogee (Lilith)	`0.000"`

Mediana su tutte le 130 misurazioni: 0.0013".

In precedenza, su questa pagina c’era una promessa generale di ”< 0.1 arcsec”. Le misurazioni del 2026-07-29 hanno mostrato che Nettuno, Plutone e Chirone non la mantengono, quindi la promessa è stata sostituita con i numeri effettivi. Chirone e i pianeti esterni hanno una deriva maggiore perché le loro posizioni sono prese da un set compresso di effemeridi utilizzato dalla nostra build.

Puoi riprodurre autonomamente: api-calc/scripts/accuracy-vs-swetest.mjs esegue esattamente queste richieste e stampa la stessa tabella.

Verifica tu stesso. Lo script con cui sono stati misurati i numeri sopra si trova in un repository pubblico sotto licenza MIT: astroway/astrology-accuracy-benchmark. Funziona non solo con noi: un adattatore per qualsiasi altra API è di trenta righe, quindi le stesse 130 misurazioni possono essere eseguite contro un concorrente e confrontate. Una chiave sandbox è sufficiente.

Motore

Componente	Valore
Libreria	Swiss Ephemeris C code (aloistr/swisseph)
Versione	upstream Astrodienst C code
Ephemeris	DE431 JPL ephemeris (tramite file .se1)
Fallback	Moshier analytical (per date fuori 1800-2399)
Code sharing	Condiviso `@/core` con app.astroway.info - un motore, due trasporti

Metodologia

La precisione è verificata tramite triangolazione - confronto con tre fonti indipendenti:

1. swetest CGI (riferimento)

Implementazione di riferimento ufficiale di Swiss Ephemeris da Astrodienst stessi - il team che ha creato Astro.com e serve milioni di astrologi in tutto il mondo. La fonte pubblica più autorevole. Il nostro motore è identico (0.00–0.07 secondi d’arco di deriva).

2. Kerykeion (Python)

Una libreria Python indipendente utilizza i pyswisseph-bindings, indipendenti dalla nostra build. Conferma che il nostro strato di wrapper non distorce i dati.

3. Prokerala API

API Swiss Ephemeris remota (sidereo Lahiri). La deriva sistemica di 8–17 secondi d’arco è legata a diverse versioni della formula Lahiri ayanamsa, e non alla precisione del motore.

Risultati della triangolazione

Carta	vs swetest (Astrodienst)	vs Kerykeion (Python)	vs Prokerala API
Monroe 1926	0.00”	0.19”	16.95” (sistemico)
Diana 1961	0.00”	0.69”	8.18” (sistemico)
Einstein 1879	0.07”	Artefatto LMT di Kerykeion	14.96” (sistemico)

Verifica indipendente con strumento esterno

RoxyAPI pubblica il proprio benchmark contro NASA JPL Horizons DE441: licenza MIT, solo libreria standard, 21 carte e 210 posizioni, e il flag --base-url per puntarlo a qualsiasi altra API. Nel loro README è esplicitamente dichiarato che le tolleranze non sono state intenzionalmente adattate al loro motore, perché un benchmark che propone di verificare un concorrente deve essere onesto.

Lo abbiamo puntato su noi stessi, senza modificare alcun numero nel loro codice. L’adattatore rinomina un campo di richiesta e rimuove un wrapper di risposta.

	AstroWay	RoxyAPI, loro esecuzione 2026-09-29
Entro la tolleranza	210 su 210	210 su 210
Mediana della deviazione	`0.11"`	`0.05"`
Massimo	`0.60"`	`0.78"`

La nostra misurazione del 2026-09-09, costo 21 richieste API. RoxyAPI a settembre è passato alla lettura diretta di DE440, e la loro mediana è ora inferiore alla nostra; il nostro massimo è inferiore al loro. Output sequenziale di tutte le 210 righe: CSV.

Suite di regressione a livello di endpoint

Ciascuno degli endpoint di calcolo di base è coperto da test snapshot congelati su 3 carte di riferimento (Monroe / Diana / Einstein) = 873 snapshot.

La suite di snapshot rileva:

Bug di mappatura dei dati di input: ID pianeta errato, UT, sistema di case
Post-elaborazione: arrotondamento, conversione di unità, perdita di segno
Discrepanza dei default: mean vs true node, geocentric vs topocentric
Schema drift: la validazione ha saltato una forma errata
Deploy obsoleto: la distribuzione di produzione non corrisponde al codice

Tolleranza: 5e-5° (≈0.18 secondi d’arco) per impostazione predefinita per tutti i campi numerici.

Benchmark dettagliati

Posizioni planetarie (tropico, vs swetest)

Carta	Data	Deriva massima
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Cuspidi delle case Placidus (vs swetest)

Carta	deriva ASC	deriva MC	Deriva massima cuspide
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Eclissi (vs NASA 5-Millennium Catalog)

Evento	Massimo NASA	Nostro massimo	Deriva
2025-03-14 Totale Lunare	06:58 UT	06:58 UT	0.8 min
2025-03-29 Parziale Solare	10:47 UT	10:47 UT	0.5 min
2025-09-07 Totale Lunare	18:11 UT	18:11 UT	0.8 min
2025-09-21 Parziale Solare	19:41 UT	19:42 UT	1.0 min

Astrocartografia (vs formula RA da swetest)

Le linee MC e IC sono costruite secondo la formula longitude = RA − GMST (standard Kenneth Bowser). Deriva dal riferimento: < 1.5 km all’equatore per tutti i pianeti.

Le linee orizzontali ASC e DSC sono calcolate dall’equazione dell’orizzonte nelle stesse coordinate equatoriali: cos H = -tan φ · tan δ, dove H = (GMST + lng) − RA. Le due metà differiscono per il segno dell’angolo orario: con H < 0 il corpo è a est del meridiano, cioè sorge. La verifica che eseguiamo ad ogni esecuzione: si prende ogni punto di ogni curva orizzontale e si calcola l’altezza del corpo sopra l’orizzonte in quel punto. Su 8419 punti, la deviazione massima è 0.0 km, il che significa che il corpo si trova effettivamente sull’orizzonte ovunque abbiamo tracciato la linea.

Fino al 2026-08-12 le curve orizzontali risolvevano un’altra equazione (“questa longitudine eclittica sull’ascendente”), e le due metà differivano per un test invertito, quindi ASC si trovava dove il corpo tramonta. MC e IC non sono mai stati interessati.

La seconda metà, meno evidente, dello stesso errore: la vecchia equazione ignorava la latitudine eclittica del corpo, quindi la linea deviava proporzionalmente ad essa, circa 103 km per ogni grado di latitudine. Sulla carta di Marilyn Monroe, questo significa 0 km per il Sole e i nodi, 22 km per Mercurio, 161 per Plutone, 285 per la Luna, 345 per Lilith. Su carte dove il corpo si trova molto al di sopra dell’eclittica, la deviazione raggiungeva oltre 1500 km.

Cosa significa questo per il tuo codice. Se hai aggirato l’errore precedente, scambiando ASC e DSC nel tuo codice, rimuovi questo workaround. Se leggevi il campo knownDefect, non è più presente nelle risposte. Le coordinate delle linee orizzontali per i corpi con una latitudine eclittica significativa sono cambiate, quindi le carte cache dovrebbero essere ricostruite.

Alba / Tramonto (vs timeanddate.com)

Località	Data	Parametro	Deriva
London	2026-04-15	Sunrise	0.6 s
London	2026-04-15	Sunset	9 s

Località polari (|lat| > 66.5°) restituiscono automaticamente polarState + un avviso che le ore planetarie normali non sono definite.

Orb di aspetto

AstroWay utilizza orb variabili per pianeta (regola MIN dei due pianeti), come in ZET9 e astro.com. Orb predefiniti (per la carta natale):

Aspetto	Sole	Luna	Interno	Giove	Esterno
Congiunzione	12°	10°	5°	8°	5°
Sestile	6.5°	6°	5°	5°	5°
Quadratura	10°	8°	5°	7°	5°
Trigono	12°	8°	5°	5°	5°
Opposizione	12°	10°	5°	8°	5°

Gli aspetti minori (36°, 40°, 45°, 72°, 108°, 135°, 144°) sono disattivati per impostazione predefinita. Si attivano esplicitamente tramite ALL_ASPECTS.

Latitudini polari

Per |lat| > 66.5° i sistemi Placidus / Koch / Regiomontanus non sono matematicamente definiti. In questi casi, Swiss Ephemeris restituisce automaticamente Porphyry, e la nostra API aggiunge un avviso:

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

Verifica continua

La regressione è verificata ad ogni PR tramite CI:

api-calc/tests/endpoints/: 873 snapshot contro carte di riferimento (Monroe / Diana / Einstein) + sinastria / composita / davison
.github/workflows/api-accuracy.yml: esecuzione automatica su PR
Triangolazione contro swetest CGI + Kerykeion: settimanale
Monitoraggio di Swiss Ephemeris upstream tramite Dependabot

Affidabilità MCP: output tipizzato

La precisione del motore è metà della fiducia. L’altra metà è il contratto di output, che un agente (Claude, ChatGPT, Cursor) può validare. Il nostro server MCP non restituisce “testo grezzo, arrangiatevi”:

structuredContent tipizzato. Oltre 600 strumenti MCP, e la stragrande maggioranza di essi pubblica uno outputSchema rigoroso - il client MCP riceve una struttura validata, non una stringa da parsare a caso.
Protezione dallo schema drift. Il test CI openapi-example-drift valida ogni regression-snapshot contro lo schema derivato dal suo stesso esempio: se l’output effettivo dell’endpoint diverge dallo schema pubblicato, la build fallisce. È proprio questa classe di discrepanze che causa l’errore MCP -32602 Output validation error.
Errori: sono errori. Un fallimento dello strumento viene sempre restituito con il flag isError e un codice tipizzato (UPPER_SNAKE). Non forniamo mai al modello uno stack trace grezzo o percorsi interni del server come “dati”.

Ciò significa che l’integrazione tramite MCP è prevedibile quanto una chiamata REST diretta: ciò che è descritto in /openapi.json è ciò che lo strumento restituisce.

Limitazioni note

Date fuori intervallo (prima del 1800 e dopo il 2399): viene utilizzato Moshier analytical, precisione ~0.1” (vs < 0.01” per SWIEPH con file DE431)
True Lilith (id=13) vs Mean Lilith (id=12): differenza fino a 12° - per default Mean Lilith (comportamento stabile), True Lilith è disponibile tramite planetIds: [13]
Topocentrico vs geocentrico: per default geocentrico