دقة الحسابات

ملخص سريع

AstroWay API يستخدم Swiss Ephemeris (الكود C الرسمي من Astrodienst، صانعي astro.com) - نفس المحرك الذي يستخدمه علماء الفلك المحترفون منذ أكثر من 30 سنة في Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/شهر) و Janus. نحن نشغله على خوادمنا الخاصة ونقدمه كطبقة REST API، بدون أي هامش وساطة. كل نقطة نهاية حسابية أساسية مغطاة باختبارات regression snapshot؛ تم التحقق من دقة المحرك عبر triangulation مع ثلاث مصادر مستقلة + مقابل NASA 5-Millennium Eclipse Catalog:

• مواقع الكواكب: الوسيط 0.0013", الحد الأقصى 0.561" مقابل swetest CGI الرسمي من Astrodienst (تم القياس 2026-07-29 على 130 قياسًا). التفصيل حسب الأجرام أدناه
• تشغيل مستقل بمرجع خارجي (RoxyAPI، مقابل NASA JPL Horizons DE441): 210 من 210 ضمن الحدود المسموح بها، الوسيط 0.11", الحد الأقصى 0.60"
• كواكب بيوت Placidus: 0.000" تطابق تام
• الكسوف: < 1 دقيقة مقابل NASA Eclipse Catalog
• خطوط ACG: < 1.5 كم على خط الاستواء مقابل swetest
• Sunrise/sunset: < 10 ثوانٍ مقابل timeanddate.com
• Moon VOC, ingresses, planet conjunctions: الدقة إلى جزء من الثانية

المنهجية: كيف تم القياس

هذه الأرقام ليست تقديرًا، بل نتيجة تشغيل. السكريبت يأخذ 10 خرائط موزعة من 1900 إلى 2050، يطلب نفس اللحظات من swetest CGI الحي من Astrodienst ويقارن جميع الـ13 جرمًا التي نقدمها. المجموع 130 قياسًا.

المكوّن	القيمة
Бібліотека	Swiss Ephemeris C code (aloistr/swisseph)
Версія	upstream Astrodienst C code
Ephemeris	DE431 JPL ephemeris (через .se1 файли)
Fallback	Moshier analytical (для дат поза 1800-2399)
Code sharing	Shared @/core із app.astroway.info - один двигун, два транспорти

الوسيط لجميع الـ130 قياسًا: 0.0013".

سابقًا على هذه الصفحة كان هناك وعد عام ”< 0.1 arcsec”. قياسات 2026-07-29 أظهرت أن نبتون، بلوتو وشيرون لا يلتزمون به، لذا تم استبدال الوعد بأرقام فعلية. شيرون والكواكب الخارجية لديها انجراف أكبر بسبب أخذ مواقعها من مجموعة إيفيميريد مضغوطة تستخدمها مجموعتنا.

يمكنك إعادة إنتاج ذلك بنفسك: api-calc/scripts/accuracy-vs-swetest.mjs يقوم بتنفيذ هذه الطلبات بالضبط ويطبع نفس الجدول.

تحقق بنفسك. السكريبت الذي تم قياس الأرقام به موجود في المستودع العام تحت رخصة MIT: astroway/astrology-accuracy-benchmark. هو لا يعمل فقط معنا: محول لأي API آخر هو ثلاثون سطرًا، لذا يمكن تشغيل نفس الـ130 قياسًا ضد منافس ومقارنة. مفتاح sandbox كافٍ.

المحرك

المكوّن	القيمة
Бібліотека	Swiss Ephemeris C code (aloistr/swisseph)
Версія	upstream Astrodienst C code
Ephemeris	DE431 JPL ephemeris (через .se1 файли)
Fallback	Moshier analytical (для дат поза 1800-2399)
Code sharing	Shared @/core із app.astroway.info - один двигун, два транспорти

المنهجية

يتم التحقق من الدقة عبر triangulation - مقارنة مع ثلاث مصادر مستقلة:

1. swetest CGI (المعيار)

التنفيذ المرجعي الرسمي لـ Swiss Ephemeris من Astrodienst أنفسهم - الفريق الذي أنشأ Astro.com ويخدم ملايين من علماء الفلك حول العالم. المصدر العام الأكثر سلطة. محركنا متطابق (0.00–0.07 ثانية زاوية انجراف).

2. Kerykeion (Python)

مكتبة Python مستقلة تستخدم ربطات pyswisseph، مستقلة عن مجموعتنا. تؤكد أن طبقة التغليف الخاصة بنا لا تشوه البيانات.

3. Prokerala API

API Swiss Ephemeris عن بُعد (sidereal Lahiri). الانجراف النظامي 8–17 ثانية زاوية مرتبط بإصدارات مختلفة من صيغة Lahiri ayanamsa، ليس بدقة المحرك.

نتائج triangulation

الخريطة	مقابل 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)

تحقق مستقل بأداة خارجية

RoxyAPI تنشر benchmark خاص بها مقابل NASA JPL Horizons DE441: رخصة MIT، مكتبة قياسية فقط، 21 خريطة و210 مواضع، وعلم --base-url لتوجيهه إلى أي API آخر. في README الخاص بهم مذكور صراحة أن الحدود لم تُضبط عمدًا لتتناسب مع محركهم الخاص، لأن benchmark الذي يتيح فحص المنافس يجب أن يكون صادقًا.

قمنا بتوجيهه إلى أنفسنا دون تعديل أي رقم في شفرتهم. المحول يعيد تسمية حقل طلب واحد ويزيل غلاف استجابة واحد.

	AstroWay	RoxyAPI, تشغيلهم 2026-09-29
ضمن الحدود المسموح بها	210 з 210	210 з 210
الوسيط الانحراف	0.11"	0.05"
الحد الأقصى	0.60"	0.78"

قياسنا 2026-09-09، تكلفة 21 طلبًا إلى API. RoxyAPI في سبتمبر انتقلوا إلى القراءة المباشرة لـ DE440، والوسيط الآن أقل من وسيطنا؛ الحد الأقصى الآن أقل من حدهم. إخراج مرتب لجميع الـ210 صفوف: CSV.

مجموعة Regression على مستوى النقاط النهاية

كل نقطة نهاية حسابية أساسية مغطاة باختبارات snapshot مجمدة على 3 خرائط مرجعية (Monroe / Diana / Einstein) = 873 snapshot-ات.

Snapshot-suite يلتقط:

• أخطاء ربط البيانات المدخلة: معرف كوكب غير صحيح، UT، نظام البيوت
• معالجة ما بعد: التقريب، تحويل الوحدات، فقدان الإشارة
• اختلاف الافتراضات: mean vs true node، geocentric vs topocentric
• انجراف المخطط: الفاليدايشن تخطى شكل غير صحيح
• نشر قديم: توزيع الإنتاج لا يتطابق مع الكود

التحمل: 5e-5° (≈0.18 ثانية زاوية) بشكل افتراضي لجميع الحقول العددية.

معايير تفصيلية

مواقع الكواكب (تروبيك، مقابل swetest)

الخريطة	التاريخ	الحد الأقصى للانجراف
Marilyn Monroe	1926-06-01	0.00”
Princess Diana	1961-07-01	0.00”
Albert Einstein	1879-03-14	0.07”

كواكب بيوت Placidus (مقابل swetest)

الخريطة	انجراف ASC	انجراف MC	الحد الأقصى لانجراف الكاسبة
Monroe	0.000”	0.000”	0.000”
Diana	0.000”	0.000”	0.000”

كسوف (مقابل NASA 5-Millennium Catalog)

الحدث	الحد الأقصى NASA	حدنا الأقصى	الانجراف
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). الانجراف عن المعيار: < 1.5 كم على خط الاستواء لجميع الكواكب.

خطوط الأفق ASC و DSC تُحسب من معادلة الأفق في نفس الإحداثيات الاستوائية: cos H = -tan φ · tan δ، حيث H = (GMST + lng) − RA. النصفان يختلفان بإشارة الزاوية الزمنية: عندما H < 0 يكون الجرم أقرب إلى خط الطول، أي يشرق. الفحص الذي نجريه في كل تشغيل: نأخذ كل نقطة من كل منحنى أفقي ونحسب ارتفاع الجرم فوق الأفق عندها. على 8419 نقطة الحد الأقصى للانجراف 0.0 كم، أي أن الجرم فعليًا يقع على الأفق في كل مكان رسمنا فيه الخط.

تم التصحيح 2026-08-12: قبل هذا التاريخ كان ASC و DSC مُعَلَّمان عكسياً

حتى 2026-08-12 كانت المنحنيات الأفقية تحل معادلة مختلفة (“هذا الطول القمري على الصعود”)، وكان النصفان يختلفان باختبار مقلوب، لذا كان ASC موجودًا حيث يذهب الجرم إلى الأسفل. لم يتأثر MC و IC أبدًا.

النصف الثاني، الأقل وضوحًا من نفس الخطأ: المعادلة القديمة تجاهلت عرض القطر القمري، لذا انحرفت الخطوط بنسبة تقريبًا 103 كم لكل درجة عرض. على خريطة ميريلين مونرو هذا يعني 0 كم للشمس والعقد، 22 كم لعطارد، 161 كم لبلوتو، 285 كم للقمر، 345 كم للليلت. على الخرائط التي يكون فيها الجرم مرتفعًا فوق القمرية، وصل الانجراف إلى أكثر من 1500 كم.

ماذا يعني هذا لكودك. إذا كنت قد تجاوزت الخطأ السابق بتبديل ASC و DSC في تطبيقك، أزل هذا التجاوز. إذا كنت تقرأ الحقل knownDefect، فهو لم يعد موجودًا في الردود. إحداثيات الخطوط الأفقية للأجرام ذات العرض القمري الملحوظ تغيرت، لذا يجب إعادة بناء الخرائط المخزنة مؤقتًا.

شروق / غروب الشمس (مقابل timeanddate.com)

الموقع	التاريخ	المعامل	الانجراف
London	2026-04-15	Sunrise	0.6 с
London	2026-04-15	Sunset	9 с

المواقع القطبية (|lat| > 66.5°) تُعيد تلقائيًا polarState + تحذير، حيث أن ساعات الكواكب العادية غير معرفة.

مدارات الجوانب

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 غير معرفة رياضيًا. في هذه الحالات، Swiss Ephemeris تُعيد تلقائيًا Porphyry، وAPI الخاص بنا يضيف تحذير:

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

التحقق المستمر

يتم التحقق من Regression لكل PR عبر CI:

• api-calc/tests/endpoints/: 873 snapshot-ات مقابل خرائط مرجعية (Monroe / Diana / Einstein) + synastry / composite / davison
• .github/workflows/api-accuracy.yml: تشغيل تلقائي على PR
• Triangulation مقابل swetest CGI + Kerykeion: أسبوعيًا
• مراقبة upstream Swiss Ephemeris عبر Dependabot

موثوقية MCP: إخراج مُصنَّف

دقة المحرك - نصف الثقة. النصف الآخر - عقد الإخراج، الذي يمكن للوكيل (Claude, ChatGPT, Cursor) التحقق منه. خادم MCP الخاص بنا لا يُعيد “نصًا خامًا، احلّ المشكلة بنفسك”:

• structuredContent مُصنَّف. أكثر من 600 أداة MCP، ومعظمها ينشر outputSchema صارم - عميل MCP يحصل على بنية مُصادقة، وليس سلسلة تحتاج إلى تحليل عشوائي.
• حماية من انجراف المخطط. اختبار CI openapi-example-drift يتحقق من كل regression-snapshot مقابل المخطط المستخرج من مثاله نفسه: إذا اختلف الإخراج الفعلي للنقطة النهاية عن المخطط المنشور، فإن البناء يفشل. هذا النوع من الاختلافات يسبب خطأ MCP -32602 Output validation error.
• الأخطاء: هي أخطاء. فشل الأداة يُرجع دائمًا علم isError ورمز مُصنَّف (UPPER_SNAKE). نحن أبدًا لا نُعيد للنموذج stack trace خام أو مسارات خادم داخلية كـ “بيانات”.

بالتالي، التكامل عبر MCP متوقع بنفس قدر استدعاء REST المباشر: ما هو موصوف في /openapi.json هو ما يُعيده الأداة.

القيود المعروفة

• تواريخ خارج النطاق (قبل 1800 وبعد 2399): يُستخدم Moshier analytical، الدقة ~0.1” (مقابل < 0.01” لـ SWIEPH مع ملفات DE431)
• True Lilith (id=13) vs Mean Lilith (id=12): الفرق حتى 12° - بشكل افتراضي Mean Lilith (سلوك ثابت)، True Lilith متاح عبر planetIds: [13]
• Topocentric vs geocentric: بشكل افتراضي geocentric

روابط

• Swiss Ephemeris: https://www.astro.com/swisseph/
• swetest CGI: https://www.astro.com/swisseph/swetest.htm
• دليل كسوف NASA: https://eclipse.gsfc.nasa.gov/
• Kerykeion: https://github.com/g-battaglia/kerykeion
• Astrodienst: https://www.astro.com/

اتصالات

لأسئلة الدقة: راسل support@astroway.info مع بيانات الخريطة والمرجع المتوقع (astro.com أو أي مصدر موثوق آخر).