Pular para o conteúdo
AstroWay/api v2.158.7 · pt
todos os sistemas normais

Precisão dos cálculos

A API AstroWay utiliza Swiss Ephemeris (código C oficial da Astrodienst, criadores de astro.com) - o mesmo motor que astrólogos profissionais usam há mais de 30 anos em Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mês) e Janus. Compilámo-lo em WebAssembly e expusemo-lo como uma camada de API REST, sem margem de lucro intermediária. Cada um dos endpoints de cálculo básicos é coberto por testes de snapshot de regressão; a precisão do motor é verificada através de triangulação com três fontes independentes + contra o Catálogo de Eclipses de 5 Milénios da NASA:

  • Posições planetárias: mediana 0.0013", máximo 0.561" vs swetest CGI oficial da Astrodienst (medido a 29-07-2026 em 130 medições). Detalhes por corpo abaixo
  • Cúspides das casas Placidus: 0.000" correspondência exata
  • Eclipses: < 1 minuto vs Catálogo de Eclipses da NASA
  • Linhas ACG: < 1.5 km no equador vs swetest
  • Nascer/pôr do sol: < 10 segundos vs timeanddate.com
  • VOC da Lua, ingressos, conjunções planetárias: precisão até uma fração de segundo

Estes números não são uma estimativa, mas o resultado de uma execução. O script pega em 10 mapas, distribuídos de 1900 a 2050, consulta os mesmos momentos no swetest CGI Astrodienst em tempo real e compara todos os 13 corpos que fornecemos. Total de 130 medições.

CorpoDesvio máximo
Sol, Vénus, Saturno0.001"
Mercúrio0.002"
Nodo verdadeiro0.004"
Marte0.007"
Júpiter0.009"
Lua0.022"
Urano0.083"
Plutão0.097"
Neptuno0.223"
Quíron0.561"
Apogeu médio (Lilith)0.000"

Mediana em todas as 130 medições: 0.0013".

Anteriormente, esta página continha uma promessa geral de «< 0.1 arcsec». As medições de 29-07-2026 mostraram que Neptuno, Plutão e Quíron não a mantêm, por isso a promessa foi substituída por números reais. Quíron e os planetas exteriores têm um desvio maior porque as suas posições são retiradas de um conjunto comprimido de efemérides na compilação WASM.

Podes reproduzir isto por ti mesmo: api-calc/scripts/accuracy-vs-swetest.mjs faz exatamente estas consultas e imprime a mesma tabela.

Verifica por ti mesmo. O script que mediu os números acima está num repositório público sob licença MIT: astroway/astrology-accuracy-benchmark. Não funciona apenas connosco: um adaptador para qualquer outra API são trinta linhas, então as mesmas 130 medições podem ser executadas contra um concorrente e comparadas. Uma chave de sandbox é suficiente.

ComponenteValor
BibliotecaSwiss Ephemeris C code (aloistr/swisseph)
Versãoupstream Astrodienst C code
Bindingsswisseph-wasm (WebAssembly em Node.js)
EfeméridesDE431 JPL ephemeris (via ficheiros .se1)
AlternativaMoshier analytical (para datas fora de 1800-2399)
Partilha de códigoPartilhado @/core com app.astroway.info - um motor, dois transportes

A precisão é verificada através de triangulação - comparação com três fontes independentes:

A implementação de referência oficial do Swiss Ephemeris da própria Astrodienst - a equipa que criou Astro.com e serve milhões de astrólogos em todo o mundo. A fonte pública mais autoritária. O nosso motor é idêntico (0.00–0.07 segundos de arco de desvio).

Uma biblioteca Python independente que utiliza pyswisseph-bindings em vez do nosso WASM. Confirma que a nossa camada WASM não distorce os dados.

API Swiss Ephemeris remoto (sidéreo Lahiri). O desvio sistémico de 8–17 segundos de arco está relacionado com diferentes versões da fórmula Lahiri ayanamsa, e não com a precisão do motor.

Mapavs swetest (Astrodienst)vs Kerykeion (Python)vs API Prokerala
Monroe 19260.00”0.19”16.95” (sistémico)
Diana 19610.00”0.69”8.18” (sistémico)
Einstein 18790.07”artefacto LMT Kerykeion14.96” (sistémico)

Cada um dos endpoints de cálculo básicos é coberto por testes de snapshot congelados em 3 mapas de referência (Monroe / Diana / Einstein) = 873 snapshots.

A suite de snapshots deteta:

  • Erros de mapeamento de dados de entrada - ID de planeta incorreto, UT, sistema de casas
  • Pós-processamento - arredondamento, conversão de unidades, perda de sinal
  • Divergência de predefinições - nodo médio vs verdadeiro, geocêntrico vs topocêntrico
  • Desvio de esquema - a validação ignorou um formato incorreto
  • Deploy desatualizado - a distribuição de produção não corresponde ao código

Tolerância: 5e-5° (≈0.18 segundos de arco) por predefinição para todos os campos numéricos.

MapaDataDesvio máximo
Marilyn Monroe1926-06-010.00”
Princess Diana1961-07-010.00”
Albert Einstein1879-03-140.07”
Mapadesvio ASCdesvio MCDesvio máximo da cúspide
Monroe0.000”0.000”0.000”
Diana0.000”0.000”0.000”
EventoMáximo NASANosso máximoDesvio
2025-03-14 Lunar Total06:58 UT06:58 UT0.8 min
2025-03-29 Solar Partial10:47 UT10:47 UT0.5 min
2025-09-07 Lunar Total18:11 UT18:11 UT0.8 min
2025-09-21 Solar Partial19:41 UT19:42 UT1.0 min

Todas as linhas MC/IC/ASC/DSC utilizam a fórmula correta longitude = RA − GMST (padrão Kenneth Bowser). Desvio da referência: < 1.5 km no equador para todos os planetas.

LocalizaçãoDataParâmetroDesvio
London2026-04-15Nascer do Sol0.6 s
London2026-04-15Pôr do Sol9 s

Localizações polares (|lat| > 66.5°) retornam automaticamente polarState + aviso de que as horas planetárias normais não estão definidas.

AstroWay utiliza orbes variáveis por planeta (regra MIN dos dois planetas), como em ZET9 e astro.com. Orbes predefinidos (para o mapa natal):

AspetoSolLuaInterioresJúpiterExteriores
Conjunção12°10°
Sextil6.5°
Quadratura10°
Trígono12°
Oposição12°10°

Aspetos menores (36°, 40°, 45°, 72°, 108°, 135°, 144°) estão desativados por predefinição. São ativados explicitamente através de ALL_ASPECTS.

Para |lat| > 66.5°, os sistemas Placidus / Koch / Regiomontanus não estão matematicamente definidos. Nesses casos, o Swiss Ephemeris retorna automaticamente Porphyry, e a nossa API adiciona um aviso:

{
"system": "P",
"warning": "Система Placidus не визначена для lat=68.96° (> 66.5°). Swiss Ephemeris підставив Porphyry..."
}

A regressão é verificada em cada PR via CI:

  • api-calc/tests/endpoints/ - 873 snapshots contra mapas de referência (Monroe / Diana / Einstein) + sinastria / composto / davison
  • .github/workflows/api-accuracy.yml - execução automática em PR
  • Triangulação contra swetest CGI + Kerykeion - semanalmente
  • Monitorização do Swiss Ephemeris upstream via Dependabot

A precisão do motor - metade da confiança. A outra metade - o contrato de saída, que um agente (Claude, ChatGPT, Cursor) pode validar. O nosso servidor MCP não retorna «texto bruto, resolvam vocês»:

  • structuredContent tipado. Mais de 600 ferramentas MCP, e a grande maioria delas publica um outputSchema rigoroso - o cliente MCP recebe uma estrutura validada, e não uma string que precisa de ser analisada aleatoriamente.
  • Proteção contra desvio de esquema. O teste CI openapi-example-drift valida cada snapshot de regressão contra o esquema derivado do seu próprio exemplo: se a saída real do endpoint divergir do esquema publicado, a compilação falha. É esta classe de divergências que causa o erro MCP -32602 Output validation error.
  • Erros são erros. Uma falha da ferramenta é sempre retornada com a flag isError e um código tipado (UPPER_SNAKE). Nunca fornecemos ao modelo um stack trace bruto ou caminhos internos do servidor como «dados».

Ou seja, a integração via MCP é tão previsível quanto uma chamada REST direta: o que é descrito em /openapi.json é o que a ferramenta retorna.

  • Datas fora do intervalo (antes de 1800 e depois de 2399): é utilizado o Moshier analytical, precisão ~0.1” (vs < 0.01” para SWIEPH com ficheiros DE431)
  • Lilith Verdadeira (id=13) vs Lilith Média (id=12): diferença até 12° - por predefinição Lilith Média (comportamento estável), Lilith Verdadeira disponível via planetIds: [13]
  • Topocêntrico vs geocêntrico: por predefinição geocêntrico

Para questões de precisão: escreve para support@astroway.info com os dados do mapa e a referência esperada (astro.com ou outra fonte autoritária).

Útil?
Запропонувати правку

Última atualização: