Точність розрахунків

Оновлено 7 лист. 2026 р. Відкрити як Markdown Налаштування агента

TL;DR

Еталон для позицій AstroWay це NASA JPL Horizons, ефемеридний сервіс Лабораторії реактивного руху NASA. Кожен розрахунок виконується на наших власних серверах, без чужого API між вашим запитом і відповіддю. Кожен із базових розрахункових ендпоінтів також покритий нашими regression snapshot-тестами, а числа звірені з незалежними джерелами і з NASA 5-Millennium Eclipse Catalog:

Проти NASA JPL Horizons, чужим бенчмарком (RoxyAPI): 231 з 231 у межах допуску, медіана 0.052", максимум 1.1" (Хірон у 1900 році; 0.47" для Сонця, Місяця і планет)
Regression-набір: 888 заморожених snapshot-ів на кожен pull request; одна регресія блокує реліз
Планетні позиції проти референсного виводу swetest від Astrodienst: медіана 0.0013", максимум 0.561" (заміряно 2026-07-29 на 130 замірах). Розбивка по тілах нижче
Куспиди домів Placidus: 0.000" exact match
Затемнення: < 1 хвилина vs NASA Eclipse Catalog
ACG лінії: < 1.5 км на екваторі vs swetest
Sunrise/sunset: < 10 секунд vs timeanddate.com
Moon VOC, ingresses, planet conjunctions: точність до частки секунди

Перевірка проти NASA JPL Horizons чужим інструментом

RoxyAPI публікують власний бенчмарк проти NASA JPL Horizons DE441: MIT-ліцензія, тільки стандартна бібліотека, 17 доменів і 2 701 значення з 2026-11-01, з них у теці західних планет 21 карта і 231 позиція, і прапорець --base-url, щоб націлити його на будь-який інший API. У їхньому README прямо сказано, що допуски навмисно не підганяли під їхній власний двигун, бо бенчмарк, який пропонує перевірити конкурента, має бути чесним.

Ми націлили його на себе, не змінивши в їхньому коді жодного числа. Адаптер перейменовує одне поле запиту і знімає одну обгортку відповіді.

	AstroWay, 2026-10-19	RoxyAPI, їхній прогін 2026-11-01
У межах допуску	231 з 231	231 з 231
Медіана відхилення	`0.052"`	`0.048"`
Максимум	`1.1"`	`0.32"`

Наш замір зроблено на поточній версії їхнього бенчмарку, де додали Хірон і два випадки з переходом на літній час, а значення Horizons беруться до семи знаків; ціна 21 запит до API. Медіани відрізняються на 0.004”. Найбільше відхилення в нас у Хірона 1900 року: наша ефемерида астероїдів і інтеграція малих тіл Horizons розходяться на 1.1”; для Сонця, Місяця і планет наш максимум 0.47”. Порядковий вивід усіх 231 рядка: CSV. Прогін 2026-09-09 на старій версії бенчмарку: CSV.

Проти референсного виводу swetest: як саме заміряно

Ці числа не оцінка, а результат прогону. Скрипт бере 10 карт, рознесених від 1900 до 2050 року, запитує ті самі моменти в живого swetest CGI Astrodienst і порівнює всі 13 тіл, які ми віддаємо. Разом 130 замірів.

Тіло	Максимальний дрейф
Сонце, Венера, Сатурн	`0.001"`
Меркурій	`0.002"`
true Node	`0.004"`
Марс	`0.007"`
Юпітер	`0.009"`
Місяць	`0.022"`
Уран	`0.083"`
Плутон	`0.097"`
Нептун	`0.223"`
Хірон	`0.561"`
mean Apogee (Ліліт)	`0.000"`

Медіана по всіх 130 замірах: 0.0013".

Раніше на цій сторінці стояла загальна обіцянка ”< 0.1 arcsec”. Заміри 2026-07-29 показали, що Нептун, Плутон і Хірон її не тримають, тому обіцянку замінено на фактичні числа. Хірон і зовнішні планети мають більший дрейф через те, що їхні позиції беруться зі стисненого набору ефемерид, який використовує наша збірка.

Відтворити можна самостійно: api-calc/scripts/accuracy-vs-swetest.mjs робить рівно ці запити й друкує ту саму таблицю.

Перевірте самі. Скрипт, яким заміряні числа вище, лежить у публічному репозиторії під MIT: astroway/astrology-accuracy-benchmark. Він працює не лише з нами: адаптер до будь-якого іншого API це тридцять рядків, тож ті самі 130 замірів можна прогнати проти конкурента й порівняти. Ключа пісочниці досить.

Звірка з іншими джерелами

Окрім JPL Horizons і наших snapshot-ів, числа порівнюються ще з трьома публічними джерелами:

1. swetest CGI

Референсний вивід, який публікують Astrodienst, команда Astro.com. Дрейф від нього на референсних картах 0.00-0.07 кутової секунди.

2. Kerykeion (Python)

Незалежна open-source Python-бібліотека, прогнана на тих самих картах.

3. Prokerala API

Віддалений астрологічний API (sidereal Lahiri). Systemic drift 8-17 кутових секунд пов’язаний з різними версіями формули Lahiri ayanamsa, а не з точністю позицій.

Результати звірки

Карта	проти swetest (Astrodienst)	проти Kerykeion (Python)	проти 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-артефакт Kerykeion	14.96” (systemic)

Regression-набір на рівні ендпоінтів

Кожен із базових обчислювальних ендпоінтів покритий замороженими snapshot-тестами на 3 референсних картах (Monroe / Diana / Einstein) = 888 snapshot-ів.

Snapshot-suite ловить:

Баги мапінгу вхідних даних: неправильний id планети, UT, система будинків
Пост-обробку: округлення, конвертація одиниць, втрата знаку
Розбіжність дефолтів: mean vs true node, geocentric vs topocentric
Schema drift: валідація пропустила неправильну форму
Застарілий деплой: prod dist не відповідає коду

Tolerance: 5e-5° (≈0.18 кутової секунди) за замовчуванням для всіх числових полів.

Детальні бенчмарки

Позиції планет (тропік, проти swetest)

Карта	Дата	Максимум drift
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

Куспіди домів Placidus (проти swetest)

Карта	drift ASC	drift MC	Максимум drift куспіда
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

Затемнення (проти NASA 5-Millennium Catalog)

Подія	Максимум NASA	Наш максимум	Drift
2025-03-14 Lunar Total	06:58 UT	06:58 UT	0.8 хв
2025-03-29 Solar Partial	10:47 UT	10:47 UT	0.5 хв
2025-09-07 Lunar Total	18:11 UT	18:11 UT	0.8 хв
2025-09-21 Solar Partial	19:41 UT	19:42 UT	1.0 хв

Астрокартографія (проти формули RA з swetest)

Лінії MC та IC будуються за формулою longitude = RA − GMST (стандарт Kenneth Bowser). Drift від еталона: < 1.5 км на екваторі для всіх планет.

Горизонтні лінії ASC і DSC рахуються з рівняння горизонту в тих самих екваторіальних координатах: cos H = -tan φ · tan δ, де H = (GMST + lng) − RA. Половини різняться знаком часового кута: при H < 0 тіло східніше меридіана, тобто сходить. Перевірка, яку ми ганяємо на кожному прогоні: береться кожна точка кожної горизонтної кривої і рахується висота тіла над горизонтом у ній. На 8419 точках максимальне відхилення 0.0 км, тобто тіло справді стоїть на горизонті скрізь, де ми провели лінію.

До 2026-08-12 горизонтні криві розв’язували інше рівняння (“ця екліптична довгота на асценденті”), а дві половини різнились інвертованим тестом, тому ASC стояв там, де тіло заходить. MC та IC не були зачеплені ніколи.

Друга, менш помітна половина тієї ж помилки: старе рівняння ігнорувало екліптичну широту тіла, тому лінія відхилялась пропорційно їй, приблизно на 103 км за кожен градус широти. На карті Мерилін Монро це 0 км для Сонця і вузлів, 22 км для Меркурія, 161 для Плутона, 285 для Місяця, 345 для Ліліт. На картах, де тіло стоїть високо над екліптикою, відхилення сягало понад 1500 км.

Що це означає для вашого коду. Якщо ви обходили попередню помилку, міняючи ASC і DSC місцями у себе, приберіть цей обхід. Якщо ви читали поле knownDefect, його більше немає у відповідях. Координати горизонтних ліній для тіл з помітною екліптичною широтою змінились, тому кешовані карти варто перебудувати.

Схід / Захід Сонця (проти timeanddate.com)

Локація	Дата	Параметр	Drift
London	2026-04-15	Sunrise	0.6 с
London	2026-04-15	Sunset	9 с

Полярні локації (|lat| > 66.5°) автоматично повертають polarState + warning, що звичайні planetary hours не визначені.

Орбіси аспектів

AstroWay використовує змінні орбіси per-planet (правило MIN двох планет), як у ZET9 та astro.com. Орбіси за замовчуванням (для натальної карти):

Аспект	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°

Мінорні аспекти (36°, 40°, 45°, 72°, 108°, 135°, 144°) за замовчуванням вимкнені. Вмикаються явно через ALL_ASPECTS.

Полярні широти

Для |lat| > 66.5° системи Placidus / Koch / Regiomontanus математично не визначені. У таких випадках куспіди рахуються як Porphyry, і відповідь каже про це в полі warning поруч із "system": "P", називаючи підставлену систему й широту.

Безперервна перевірка

Regression перевіряється на кожен PR через CI:

api-calc/tests/endpoints/: 888 snapshot-ів проти референсних карт (Monroe / Diana / Einstein) + synastry / composite / davison
.github/workflows/api-accuracy.yml: автозапуск на PR
Звірка зі swetest CGI + Kerykeion: щотижня

Надійність MCP: типізований вивід

Точність двигуна - половина довіри. Друга половина - контракт виводу, який агент (Claude, ChatGPT, Cursor) може валідувати. Наш MCP-сервер не повертає “сирий текст, розберіться самі”:

Типізований structuredContent. Понад 600 MCP-інструментів, і переважна більшість із них публікують строгий outputSchema - MCP-клієнт отримує валідовану структуру, а не рядок, який треба парсити навмання.
Захист від schema drift. CI-тест openapi-example-drift валідує кожен regression-snapshot проти схеми, виведеної з його ж прикладу: якщо реальний вивід ендпоінта розійдеться з опублікованою схемою, збірка падає. Саме цей клас розбіжностей спричиняє помилку MCP -32602 Output validation error.
Помилки: це помилки. Збій інструмента завжди повертається з прапором isError і типізованим кодом (UPPER_SNAKE). Ми ніколи не віддаємо моделі сирий stack trace або внутрішні шляхи сервера як “дані”.

Тобто інтеграція через MCP так само передбачувана, як і прямий REST-виклик: те, що описано в /openapi.json, - це те, що повертає інструмент.

Відомі обмеження

Дати поза діапазоном (до 1800 і після 2399): використовується аналітична ефемерида, точність ~0.1” (проти < 0.01” у межах 1800-2399)
True Lilith (id=13) vs Mean Lilith (id=12): різниця до 12° - за дефолтом Mean Lilith (стабільна поведінка), True Lilith доступний через planetIds: [13]
Topocentric vs geocentric: за замовчуванням geocentric