アカウント名:
パスワード:
天保暦まで実装したら公開すればいい
その場合天保15年(1844年)以降のみ対応で公開するの? 先発天保暦にするの?太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
親コメントの「天保暦まで実装」は「元嘉暦から天保暦までを実装」という意味だと思う。
また、「新しい暦法ほど複雑な計算なので、それが出来たらそれ以前の暦法の実装は容易」とは一概に言えない。
寛政暦や天保暦だと三角関数を用いて計算していて、暦法に書いているとおりに式を組み立てれば実装出来るところを、それ以前の暦だと三角関数を用いていない代わりに数表からの表引きを使っていて、この数表がどうやって出来上がったものなのかがわからないので、ひたすら暦法に書いてあるとおりにテーブルを作っていかなければいけないのだが、
・ 暦法が、宋書・唐書などの
「天保暦が一番楽」は言い過ぎかな。平朔平気の元嘉暦はマジで簡単。カレンダーを作れればいいレベルであれば、数行で計算方法を説明できる。
そうなんだよな、カレンダーを作れればいいレベルまでなら簡単。そのレベルを越えて、実際に使われた暦の再現は、結局、実際の暦に当たらないといけないからやっかい。(計算結果の縁起が悪かったら朔を1日ずらすとかしてるから、実際の暦は計算結果からズレてるんだよな、あちこち。たとえば、朔旦冬至をでっちあげるとか。)
実際に使われた暦にずれがある可能性があるのはどの暦も一緒で天保暦以外が特に不利な理由はないのでは?
ていうか例外処理の実装なんて例外テーブルを用意するしかないから、実装する観点からはむしろ一番簡単(表データの用意を除けば)。結局基本の計算式の複雑さが実装の難易度を左右すると思うんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
とりあえず (スコア:0)
天保暦まで実装したら公開すればいい
Re: (スコア:0)
その場合天保15年(1844年)以降のみ対応で公開するの? 先発天保暦にするの?
太陰太陽暦は新しい暦法ほど正確な代わりに複雑な計算が必要になっているから、天保暦が実装できたらそれ以前の暦法の実装は容易だと思うけど
Re: (スコア:4, 興味深い)
親コメントの「天保暦まで実装」は「元嘉暦から天保暦までを実装」という意味だと思う。
また、「新しい暦法ほど複雑な計算なので、それが出来たらそれ以前の暦法の実装は容易」とは一概に言えない。
寛政暦や天保暦だと三角関数を用いて計算していて、暦法に書いているとおりに式を組み立てれば実装出来るところを、
それ以前の暦だと三角関数を用いていない代わりに数表からの表引きを使っていて、この数表がどうやって出来上がったものなのかがわからないので、ひたすら暦法に書いてあるとおりにテーブルを作っていかなければいけないのだが、
・ 暦法が、宋書・唐書などの
Re: (スコア:0)
「天保暦が一番楽」は言い過ぎかな。
平朔平気の元嘉暦はマジで簡単。カレンダーを作れればいいレベルであれば、数行で計算方法を説明できる。
Re: (スコア:1)
そうなんだよな、カレンダーを作れればいいレベルまでなら簡単。
そのレベルを越えて、実際に使われた暦の再現は、結局、実際の暦に当たらないといけないからやっかい。
(計算結果の縁起が悪かったら朔を1日ずらすとかしてるから、実際の暦は計算結果からズレてるんだよな、あちこち。
たとえば、朔旦冬至をでっちあげるとか。)
Re: (スコア:0)
実際に使われた暦にずれがある可能性があるのはどの暦も一緒で天保暦以外が特に不利な理由はないのでは?
Re:とりあえず (スコア:0)
ていうか例外処理の実装なんて例外テーブルを用意するしかないから、実装する観点からはむしろ一番簡単(表データの用意を除けば)。結局基本の計算式の複雑さが実装の難易度を左右すると思うんだけど。