要旨(Abstract) 日本語 Swiss Ephemeris は公式ドキュメントにおいて自らを “a compression of JPL DE431” と記述し ているが、「圧縮」の具体的な手法・精度損失量は公開されていない。本論文は、Swiss Ephemeris の .se1 バイナリファイルの構造を直接解析し、四段階の数値実験によって「圧 縮」の実態を初めて定量的に明らかにしたものである。 .se1 バイナリ構造の解析により、Swiss Ephemeris は JPL DE431 のチェビシェフ多項式の係 数をそのまま格納しているのではなく、DE431 の出力値を教師データとして異なるパラ メータ(区間幅・次数)で高次チェビシェフ再近似していることが確定した。DE431 が短 い区間(太陽: 16日)× 低次多項式(10次)で構成されているのに対し、Swiss Ephemeris は長い区間(太陽: 365日)× 高次多項式(25次)を用い、セグメント数を劇的に削減する ことでファイルサイズを原本の 0.45% に圧縮している。この再近似による精度損失を、Swiss Ephemeris vs DE431 vs DE440s の三角比較で定量化し た結果、月の最大誤差は 47.72 秒角(0.013°)、DE431 と DE440s のバージョン間差 (0.004 秒角)の 11,930 倍に達することが判明した。物理的距離に換算すると、月の軌道 上で約 89 km(東京〜名古屋間に相当)のズレであり、約 87 秒の時間誤差に相当する。 さらに、Swiss Ephemeris と同一のパラメータ(区間幅・次数)で著者が独自に DE431 を 再近似したところ、誤差は 0.01 秒角以下となり、実際の Swiss Ephemeris ファイルとの間 に 約 7,000 倍のギャップ が存在することが発見された。Swiss Ephemeris のパラメータ設 計自体は十分な精度を出せる構成であるにもかかわらず、実際のファイルではそれが実現 されていない。このギャップの原因は Swiss Ephemeris の非公開フィッティング・パイプラ インに存在すると推定されるが、データ生成ツールが公開されていないため、完全な解明 には至っていない。 この透明性の欠如は、下流の開発者に深刻な実害をもたらす。占星術ソフトウェアの出力 にズレが生じた場合、開発者はそれが Swiss Ephemeris の再近似誤差(最大 47″)に起因す るのか、自身の実装バグなのかを区別できない。Swiss Ephemeris が精度特性を開示してい れば「47″ 以内は Swiss Ephemeris の仕様」と切り分けられるが、現状では全てのズレにつ いて自分のコードを疑わざるを得ず、デバッグコストが際限なく膨張する。 本論文は Swiss Ephemeris の技術を否定するものではない。3.3 GB を 15 MB に圧縮した設 計判断は合理的な trade-off であり、30年間にわたる業界標準としての貢献は疑いない。本 論文が問題視するのは、再近似のパラメータ・精度損失量・品質保証情報が一切開示され ていないという透明性の欠如であり、これが下流の全開発者に検証不能なデバッグコスト を転嫁する構造を生んでいる点にある。 English Swiss Ephemeris officially describes itself as “a compression of JPL DE431,” yet the specific compression methodology and resulting precision loss have never been publicly documented. This paper presents the first quantitative analysis of this “compression” through direct binary analysis of .se1 files and four-stage numerical experiments. Binary structure analysis of .se1 files revealed that Swiss Ephemeris does not store JPL DE431’s Chebyshev coefficients directly. Instead, it uses DE431’s output values as training data to perform a re-approximation with different parameters (interval width and polynomial degree). While DE431 uses short intervals (Sun: 16 days) with low-degree polynomials (degree 10), Swiss Ephemeris employs long intervals (Sun: 365 days) with high-degree polynomials (degree 25), drastically reducing the number of segments and compressing file size to 0.45% of the original. Triangular comparison of Swiss Ephemeris vs DE431 vs DE440s quantified the precision loss from this re-approximation: the Moon’s maximum error reaches 47.72 arcseconds (0.013°), which is 11,930 times larger than the DE431-to-DE440s version difference (0.004 arcseconds). In physical distance, this corresponds to approximately 89 km displacement on the lunar orbit (comparable to Tokyo-to-Nagoya distance), or roughly 87 seconds of timing error. Furthermore, when the author independently re-approximated DE431 using Swiss Ephemeris’s identical parameters (interval width and degree), the resulting error was below 0.01 arcseconds — revealing a ~7,000-fold gap between what Swiss Ephemeris’s parameter design can achieve and what the actual .se1 files deliver. The cause of this gap is attributed to Swiss Ephemeris’s unpublished fitting pipeline, but full resolution is not possible as the data generation tools remain proprietary.This lack of transparency inflicts tangible harm on downstream developers. When an astrological software application produces discrepant output, the developer cannot determine whether the discrepancy originates from Swiss Ephemeris’s re-approximation error (up to 47″) or from their own implementation bug. If Swiss Ephemeris disclosed its precision characteristics, developers could triage: “within 47″ is Swiss Ephemeris’s specification; beyond that is my bug.” In the absence of such disclosure, every discrepancy must be investigated as a potential self-inflicted defect, causing debugging costs to escalate without bound. This paper does not aim to discredit Swiss Ephemeris. The engineering decision to compress 3.3 GB into 15 MB represents a rational trade-off, and Swiss Ephemeris’s three-decade contribution as an industry standard is beyond question. What this paper critiques is the lack of transparency — the re-approximation parameters, precision loss figures, and quality assurance information have never been disclosed, creating a structure where every downstream developer bears unverifiable debugging costs.
高史 志賀 (Thu,) studied this question.