(57)【要約】ユリウス日の番号及び旧暦の日付の１組以上の参照のほか、月の長さと（もしあれば）どの月がうるう月であるかとを含んだ、計算機のメモリ内に記憶されたテーブルを用いて、任意の特定の日付の範囲内で旧暦の日付とユリウス日の番号の範囲との間で変換を行うための方法及び計算機が提供される。
2008537189.tif 000002
【特許請求の範囲】
【請求項１】
旧暦の日付とユリウス日の番号とをある範囲で変換するための計算機の演算方法であって、
ｄ．前記範囲内に含まれる旧暦の各年の月の長さと、
ｅ．もしあれば、前記範囲内に含まれる旧暦の各年のどの月がうるう月であるかと、
ｆ．前記範囲内の共通の日に対するユリウス日の番号と旧暦の日付データの少なくとも１組と、
を示す前記計算機の情報をメモリに記憶させる工程と、
前記計算機の中央演算処理装置（ＣＰＵ）が前記記憶された情報を用いて前記旧暦の日付と前記ユリウス日の番号との間で変換を行うようにする工程と、
を含むことを特徴とする方法。
【請求項２】
前記範囲内に含まれる旧暦の各年の月の長さを特定するために、ビットマップ配列を備えるテーブルが提供されることを特徴とする請求項１に記載の方法。
【請求項３】
各ビットマップ配列は、１６ビットバイナリ配列を含み、
前記配列のビットタイプの１つ及び前記配列内の前記１つのビットタイプの内容が、それぞれの旧暦の年の３０日間の月を特定するために用いられ、
前記配列のビットタイプのもう１つ及び前記配列内の前記もう１つのビットタイプの内容が、前記旧暦の年の２９日間の月を特定するために用いられることを特徴とする請求項２に記載の方法。
【請求項４】
バイナリ１ビットタイプが、３０日間の月を特定するために用いられ、
バイナリ０ビットタイプが、２９日間の月を特定するために用いられることを特徴とする請求項３に記載の方法。
【請求項５】
前記範囲内の前記旧暦の各年において任意のうるう月の数を示すために、単数数字で構成されたテーブルが提供され、前記テーブルは、旧暦の年にはうるう月がないことを示すために用いられるゼロを有することを特徴とする請求項１乃至請求項４の何れか１項に記載の方法。
【請求項６】
前記単数数字はまた、前記範囲内の年における前記ユリウス日の番号をそれぞれ特定するために用いられることを特徴とする請求項５に記載の方法。
【請求項７】
各単数数字は、３２ビットバイナリ配列の形で提供され、
各配列の最下位２８ビットは、前記ユリウス日の番号を特定するために用いられ、
各配列の最上位４ビットは、もしあれば、旧暦の年のどの月がうるう月であるかを特定するために用いられることを特徴とする請求項６に記載の方法。
【請求項８】
２組以上の旧暦の日付とユリウス日とが前記範囲内の年に提供されるが、前記範囲内で１年に１組の旧暦の日付とユリウス日とが提供されるよりは少ないことを特徴とする請求項１乃至請求項７の何れか１項に記載の方法。
【請求項９】
１年に２組以上の旧暦の日付とユリウス日とが前記範囲内の年に提供されることを特徴とする請求項１乃至請求項８の何れか１項に記載の方法。
【請求項１０】
請求項１乃至請求項９の何れか１項に記載の方法に従って演算するように構成されていることを特徴とする計算機。
【請求項１１】
請求項１乃至請求項９の何れか１項に記載の方法に従って計算機に演算させるためのオペレーティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユリウス日（Julian Calendar）の番号と旧暦（Chinese Calendar）の日付との間で変換を行う方法及びそのような変換を実行するための計算機に関する。
【背景技術】
【０００２】
ここで使用される計算機という用語は、任意の形式の電子計算機（electrical computing device）を包含するように拡張して解釈され、データ記録装置、携帯情報端末（ＰＤＡ）等の携帯用パーソナルコンピュータを含む任意のタイプ又は形式のコンピュータ、携帯電話、スマートフォン、単一装置内に通信、画像記憶及び／又は再生、計算機能を兼ね備えた発信機（communicators）を含む任意の形式要素（form factor）を持つ通信装置、及びデジタルカメラ、ＭＰ３、他の音楽プレーヤー及びデジタルラジオを含む他の形式の無線及び有線の情報装置を包含する。
【０００３】
旧暦は、非常に複雑である。旧暦は、標準の世俗的な（secular）グレゴリオ暦などの純粋な太陽暦ではない。太陽暦は、太陽の１年の周期（cycle）に基づいており、季節が毎年ほぼ同じ日付に現れることを保証する。純粋な太陽暦の欠点は、１ヶ月を通じて月の相が変わり、１ヶ月における特定の日付と関連していないことである。
【０００４】
旧暦（Chinese Calendar）でもムスリム暦（Muslim calendar）などの純粋な陰暦（lunar calendar）でもない。陰暦は、月の１ヶ月の周期を基づいて、その相が各月の同じ日に一致することを保証する。純粋な陰暦の欠点は、１年を通じて季節が変わってしまい、どの月とも関連していないことである。
【０００５】
旧暦は、太陰太陽暦（lunisolar calendar）である。これらは、その月が月の周期に基づいているという点において、陰暦と同様であるので、その相は各月の同じ日に一致する。しかしながら、これらはまた、各年のほぼ同じ月に年に毎年の季節ごとの出来事が起こることを必要とする点において、太陽と関連している。この条件は、２年ごと又は３年ごとにうるう月を挿入することによって満足され、月と太陽の要素（components）は実質的に同期することが保証される。
【０００６】
旧暦は、このタイプの唯一のカレンダーでなく、イスラエルで使用され、伝統的な目的でユダヤ人によって使用されているヘブライカレンダー（Hebrew calendar）も月と太陽の（lunisolar）タイプである。しかしながら、複雑な旧暦と異なり、ヘブライカレンダーは、計算機の処理が比較的易しい。これは、1000年をはるかに超える独立した規則に基づくカレンダーであり、任意の外部の天文学的データを確認する必要がないからである。例えば、１ヶ月の長さは固定されている、そして、うるう月が必要な場合には、その年の最初の月の前に常に現れる。その結果、ある期間の経過後の日付を知ること、又はユダヤ暦の日付とグレゴリオ暦の日付との間で変換を行うことは、簡単な処理である。
【０００７】
旧暦は、非常に異なっている。IBMは、「うるう年が非常に簡単に計算でき、１年の同じ時期に常にうるう月（intercalary month）が常に現れるヘブライカレンダーと異なり、天体観測と非常に複雑な計算に基づいて、旧暦のうるう年とうるう月が計算される」と指摘している（http://www-306.ibm.com/software/globalization/topics/locales/calendar_chinese.jsp）。
【０００８】
旧暦を扱う際に直面する根本的な問題は、その規則が独立していないということであり、任意の単純な近似よりも、実際の天文学データが重要であり（supreme）、規則が行うすべてのことは、特定の天文学の出来事が起こるときに何が起こるかを表すことである。問題とされている重要な天文学の出来事は、太陽と月（新月（dark moon）として知られている）の合（conjunction）の正確な時刻と、太陽の経線が春分点（zhongqiとして知られている）から測定して正確に３０度の倍数を横切る日である。
【０００９】
これは比較的容易であるように思えるが、実際の天文学の出来事がカレンダー演算にもたらす困難は過小評価されやすい。データは、実際には非常に複雑であり、ほとんどの人々は、太陽と月の動きは実際にはかなり不規則であり、１日の長さと１ヶ月の長さとが１年間（ある年から次の年までも）で変化することを知らない。カレンダー計算を実行するときに、旧暦は、（西洋のグレゴリオ暦で使用される１日２４時間などの平均値、又はヘブライカレンダーで大部分の年に使用される交互に起こる２９日間の月と３０日間の月よりもむしろ）このような区間に対する真の値を常に使用する。
【００１０】
真の太陽と真の月を用いることによって、カレンダーを計算するために予め必要な計算が非常に複雑となる。これは、どの月も決まった長さを持たず、うるう月が１年のどの時点でも起こりうることを意味する。現在の月の長さ又は翌月の名前の何れかを知る簡単な方法がないため、現在から６週間後の日付を知ることなど、西洋のグレゴリオ暦の使用者にとって当然の演算が、予め計算されたカレンダーテーブルへのアクセスと参照なしでは非常に困難となる。旧暦の日付と他の日付（特に、グレゴリオ暦）と間の変換を扱う場合も同様である。
【００１１】
更に、2万5800年ごとの一連の分点（equinoxes）、11万年ごとの地球の軌道の回転、及び１日2ミリ秒の地球の回転の減速は、この天文学データが常に１つしか存在せず、旧暦が他の非天文学なカレンダーと関連して繰り返し現れるものではないことを意味する。
【００１２】
要するに、任意の旧暦の日付を扱うときに、複雑な計算の使用を避ける方法はない。
【００１３】
1949年以来、南京の紫金山天文台（Purple Mountain Observatory）は、旧暦における日付を決定する責任を担っている。しかしながら、旧暦を利用することを望む計算機は、Edward M. ReingoldとNachum Dershowitzによって開発された、事実上の正準方程式（de-facto canonical equations）を利用できる。このような計算機は、彼らの著書「Calendrical Calculations」（Millenium版、ケンブリッジ大学出版局、2001年8月発行、ISBN：0521777526）の様々な版に見られる。
【００１４】
旧暦の日付でカレンダー計算を行う標準的な方法は、対応するユリウス日を中間状態として用いることによる。ユリウス日は、グレゴリオ暦以前のユリウス暦と混同しないように、紀元前（西暦紀元前）４７１３年１月１日から起算する日付の連番であり、特に、天文学者により広く用いられる。ユリウス日は、グレゴリオ暦が1582年に導入された直後に、フランスのJ.J.Scaligerによって発明され、負の数を使用する必要がなく、カレンダーとは無関係に任意の歴史的上の日を一意に参照する方法を提供する。
【００１５】
ReingoldとDershowitzの方程式は、ユリウス日の番号から任意のカレンダーの任意の日付、及び、任意のカレンダーの任意の日付からユリウス日の番号への変換を可能にする。旧暦に適用すると、これらの方程式は、任意の他のカレンダーシステムから、及び、任意の他のカレンダーへの変換を可能とする。これらの方程式によって、更に、旧暦の日付で算術演算を実行することができ、例えば、２つの任意の旧暦の日付間の日数を求めるために必要なすべてのことは、それらをユリウス日に変換し、算術比較を行うことだけである。
【００１６】
旧暦の複雑さに関する詳しい情報は、シンガポール国立大学数学科のHelmer Aslaksenの論文に紹介されており、「The Methematics of the Chinese Calendar」というタイトルで紹介されており、同著者の多数の他の論文とともに、http://www.math.nus.edu.sg/aslaksen/calendar/chinese.shtmlに見つけられる。
【００１７】
現代の計算機は、カレンダーの情報とデータを含むことが知られている。これは、予定表（Agenda）やスケジューリングソフトなどの個人情報管理（PIM）タイプのソフトウェアに最も顕著である。このような計算機の多くの使用者は、異なるカレンダーシステム間で変換を行う必要はないが、これは、多文化環境（multi-cultural environments）で演算を行う使用者には当てはまらない。IBMによれば、「世界的な使用を目的とした成功したソフトウェアを作成するためには、日付や時間から数の形式までに及ぶ現地の詳細な事項に注意する必要がある」。
【００１８】
本発明は、特に、その所有者が下記のタスクを実行する必要がある計算機の一般的な場合に関する。
・どの日が３０日の時点にあるかを求めることなど、旧暦の日付に算術演算を実行すること。
・旧暦とグレゴリオ暦の両方のフォーマットで一貫性があるカレンダーデータを保持すること。
・旧暦と任意の他のカレンダーとで一貫性があるカレンダーデータを保持すること。
【００１９】
このような計算機の種類は、近年増加しており、現在では、デスクトップコンピュータに加え、携帯電話や携帯情報端末（ＰＤＡとして知られている）などの装置を含む。更に、技術が一体化されるにつれて、ゲーム機や音楽プレーヤーなどの装置もPIM機能を含むようになりつつある。旧暦が主要なカレンダーであるか、又は広く用いられているところにおいて、これらの装置を使用者が操作を行う場合、旧暦の日付における算術演算と、西洋のグレゴリオ暦の日付への又は該日付からの変換とが、PIM機能を十分に利用するために必要とされる。
【００２０】
しかしながら、上述したReingoldとDershowitzの方程式は、地球、月及び太陽の相対位置をモデル化する必要があり、計算効率が悪いことが知られている。また、完了までの時間が長いだけではなく、天文学データの大きなテーブルを常に参照する必要がある。旧暦の日付と他のカレンダーとの間の変換アルゴリズムを実行する任意の計算機は、ＣＰＵ負荷と必要メモリによって制約される。これは、携帯電話やＰＤＡと比べて、比較的大きな計算リソースが必要であるため、デスクトップシステムのソフトウェアにさえ、問題を引き起こすことも知られている。例えば、http://homepage.mac.com/rabbel/.cv/rabbel/Public/PDF's%20and%20Doc＜1＞s/C alendar%20System%20Facts%20V2.pdf-link.pdfに見つけられるDenis A. Elliottの「Calendar System Facts」という論文を参照されたい。Elliotは、多数の異なるカレンダーシステム間で日付の変換を計算する「Intercal」と呼ばれるアップルマッキントッシュプログラムの作者であり、「膨大な数の浮動小数点計算が必要となる」ことを非常に明確に示している。Elliotは、特に、デザイン制約の１つとして、方程式の大きなＣＰＵ負荷について言及している。
【００２１】
スマートフォン（smartphones）やＰＤＡなどの携帯機器は、制限された動作メモリ、限定された記憶容量、より低速なプロセッサ及び限られた量のバッテリーパワーという点において、デスクトップPCやラップトップPCなどの大きな「固定」計算機と比べて、一般にリソースが制約される。しかしながら、これらの所有者と使用者は、大部分の演算に対し、リソース制約のないデスクトップPCから期待されるものと同程度の、高速なサブセカンド（sub-second）応答を期待する。
【００２２】
旧暦の日付に関する演算に対し、ReingoldとDershowitzの方程式などの標準的な方法を使用すると、それらが固定装置に対して行うよりも、これらのリソースが制約された携帯機器に対し、より多くの重大な問題が生じるであろう。遅い動作につながる集中的な計算及び多量のテーブルデータに必要な条件はともに、結果として、使いやすいことと、このようなリソースが制約された装置上でデュアルカレンダー（dual-calendar）が可能なPIMシステムを広く採用することに対し、大きな障害となる。
【００２３】
そのため、ＣＰＵへの負担が少ない、旧暦データに関する計算演算の処理方法が求められている。
【００２４】
従って、本発明の目的は、ＣＰＵ負荷が少なく、浮動小数点演算を伴わず、大量のメモリを必要としない、旧暦データに関するコンピュータ演算を扱う改良された方法を提供することである。従って、本発明は、リソース制約のある携帯機器に理想的かつ特に適しており、そのような装置で使用されたときに大きな技術上の利益を提供する。しかしながら、以下の詳細な説明から明らかなように、本発明は、リソース制約のより少ない「固定された」計算機に対しても、技術上の利益を提供するものである。これらの「固定された」計算機には何れも、任意の計算機におけるＣＰＵ負荷が少ない方法が、適度な少量の電力を使用し、動作が速く、結果として、環境に優しいという事実はなかった。
【００２５】
本発明の第１の側面は、旧暦の日付とユリウス日の番号とをある範囲で変換するための計算機の演算方法に係り、ａ．前記範囲内に含まれる旧暦の各年の月の長さと、ｂ．もしあれば、前記範囲内に含まれる旧暦の各年のどの月がうるう月であるかと、ｃ．前記範囲内の共通の日に対するユリウス日の番号と旧暦の日付データの少なくとも１組と、を示す前記計算機の情報をメモリに記憶させる工程と、前記計算機の中央演算処理装置（ＣＰＵ）が前記記憶された情報を用いて前記旧暦の日付と前記ユリウス日の番号との間で変換を行うようにする工程と、を含むことを特徴とする。
【００２６】
本発明の第２の側面は、計算機に係り、前記第１の側面に係る方法に従って演算するように構成されていることを特徴とする。
【００２７】
本発明の第３の側面は、オペレーティングシステムに係り、前記第１の側面に係る方法に従って計算機に演算させることを特徴とする。
【発明を実施するための最良の形態】
【００２８】
本発明の実施形態は、添付図面を例示的なものとして参照して以下に説明される。
【００２９】
図１は、任意の旧暦の年に発生する２９日間の月と３０日間の月とを決定する処理を示す図であり、図２は、本発明に係るユリウス日の番号と旧暦の日付との間の変換処理を示す図である。
【００３０】
まず、本発明を理解するために、上述の問題を解決するために、なぜルックアップテーブル（lookup tables）が広く使われていないかについて説明する必要がある。装置に関する時間周期（a period of time）が合理的に決定されうる技術において、当業者が考えうることは、ReingoldとDershowitzの方程式により急いで計算を行うことに代えて、予め計算を実行し、その結果である毎日の旧暦データを、装置内に保持された順序リスト内に配置することである。これにより、単純なルックアップテーブルを用いて、旧暦の日付に関する任意のカレンダー演算に対する答えを探し出すことができる。
【００３１】
このタイプのルックアップテーブルが、問題の実行可能な解決策ではないのは、データ量が大きすぎるからである。
【００３２】
旧暦の日付は、最低でも、以下の５つの独立した日付要素からなる。
【００３３】
・周期（各周期は、６０年）
・その周期の年
・その年の月
・月がうるう月か否か
・その月の日付
従来のデータ構造でこれを記憶するためには、５つの整数が必要であり、計算機の多くが３２ビットの整数を利用するため、標準的なルックアップテーブルは、１日２０バイト（５×３２＝１６０整数）又は１年で７Ｋバイトを超えることが必要となるであろう。そのオーバーヘッドは、急激に増大する。例えば、装置が、最低限、１９８０年から２１００年（グレゴリオ暦）の範囲の年で日付を扱うことができることが要求されていると仮定する。この１２０年の範囲は、43,830日にわたり、約856Kバイトのデータの変換オーバーヘッドを生じさせる。スマートフォン又はＰＤＡ装置内のＲＯＭ（リードオンリーメモリ）の共通サイズは、８メガバイトであり、明らかに、単一のカレンダーテーブルによって、この貴重かつ重要なリソースの10%以上を占めるのは、実用的ではなく、許容されない。
【００３４】
このテーブルデータの多少の最適化が可能であることは確かである。データ構造を圧縮し、余分な情報を取り除くことができる（例えば、１２０年の期間内に最大で３つあるときに、全サイクルを保存するなど）。これは、単一の３２ビット整数で旧暦の日付の全てを記憶することができ（データを参照するときに非効率なコストで（at an inefficiency cost））、その結果、80%だけオーバーヘッドが減少するであろう。これは、上述の１２０年の期間のサンプルに対し、ＲＯＭオーバーヘッドが非常に小さい約171Kバイトのデータを与える。
【００３５】
これは大きな改良であるが、実際は、携帯機器のリードオンリーメモリ（ＲＯＭ）内のスペースは、非常にコストがかかる。旧暦ではない固定型のカレンダー（non-Chinese fixed calendars）と同程度のオーバーヘッドが事実上ゼロであれば、テーブル主導型のアプローチを採用することは、旧暦の機能を使用可能な装置のバージョンが、より大きなＲＯＭ（NANDフラッシュ技術を用いた装置の生産コストとブート時間の増加につながる）或いは機能の縮小（ユーザが質の低下を感じる）持つ必要があることを、必然的に意味するであろう。
【００３６】
これらの理由により、テーブル主導型の効率的なアプローチは、リソース制約のある携帯機器ではこれまで実施されていない。
【００３７】
しかしながら、本発明は、予めコンパイルされた旧暦情報のオーバーヘッドが、１日20バイトのオリジナルの実質的に「最適化された」オーバーヘッドから、１年でわずか６バイトのわずかなオーバーヘッドまで抑えられることを可能にし、大きな技術上の利益を提供する。従って、上述の１２０年の期間の場合、856Kバイトのオリジナルの必要メモリからちょうど0.7Ｋバイトの必要メモリまで減少される。
【００３８】
テーブルオーバーヘッドの99.9%を超えるこの減少は、データオーバーヘッドを80%ほど減少させるだけである先の最適化されたデータ圧縮方法よりも明らかにはるかに優れており、装置内の大きくて扱いにくいデータテーブルを含む必要なしに、ReingoldとDershowitzの方程式に基いた計算コスト（computationally expensive）のかかるオンザフライの計算を省くことができるという付加的な技術上の利益を与える。従って、装置の技術的な性能は大幅に向上する。
【００３９】
本発明の背景にある主な考え方は、旧暦に関して何が確かであり、何が不確実であるかを理解することにある。或いは、別の言い方をすると、答えるべき質問は、出発点が特定のユリウス日に対応する固定された旧暦の日付である場合に、それぞれの次の日に対し、その日に対応する旧暦の日付は何日か、どの時点で計算結果が不確かとなるか、順番が確実に続くにはどの情報が必要であるか、を計算するよう試みることである。
【００４０】
その順番が任意の周知のユリウス日及びそれに対応する旧暦の日付（すなわち、その日付に対する上述した５つの独立したデータ要素は周知である）から始まるとすれば、その旧暦の日付を含む旧暦の月の終わりが初めて近づくときに、最初の問題に直面することが分かる。
【００４１】
この点で、２つの情報が必要である。第１に、１ヶ月に何日あるかであり（２９日又は３０日の何れかでなければならない）、第２に、翌月がうるう月であるか否かである（いずれにしても）。この情報がいったん利用可能になれば、進行は維持され、現在の月がいつ終わるかが分かり、翌月の日数も分かる。
【００４２】
これは、旧暦の年の終わりにも当てはまることは注目に値する。任意の１２の月の終わりに到達すると、その翌月がうるう月でなければ、旧暦の新年に至る。従って、翌月（新しい月）は１にリセットされ、うるう月の指標（indicator）はリセットされ、年が増加され、最後に、その年が６０（周期の継続期間）を超えたかどうかを判断する判定がなされ、超えた場合には、周期が増加され、年は１にリセットされる。図１は、その範囲に含まれる旧暦の各年の月の長さ、そして、もしあれば、その範囲に含まれる旧暦の各年のどの月がうるう月であるかを示す図である。この情報は、テーブルとして計算機内に記憶される。
【００４３】
計算機上に効率的なテーブルの形式で、この情報をエンコードする多数の可能な方法がある。しかしながら、本実施形態で開示された好適な実施は、Symbian Software Ltd.によって作成された携帯電話用のSymbian OS（登録商標）基本ソフトに対して設計されている。本発明を実施するためのサンプルコードの一例は、以下に示される。Symbian OS（登録商標）基本ソフトをプログラミングする当業者であれば、これから示す本発明の記載と併せて、その目的と意図を容易に理解できるであろう。
【００４４】
しかしながら、以下に示す実施とその例は、例示的なものとして提供されたに過ぎないものと理解されるべきである。本発明は、Symbian OS（登録商標）基本ソフト又は以下に記載された特定の実施のみに限定されることを意図したものではない、という点を強調しておく。本発明は、その発明の範囲を逸脱しない限り、他のタイプの計算機を含む多くの異なるオペレーティングシステム及び装置で、様々な方法により実行されうる。
【００４５】
以下に示す本発明の実施形態は、その年のどの月が２９日間あり、どの月が３０日間あるかという情報を、各年に対して、単純なビットマップ１６ビット整数（bit-mapped 16-bit integer）で、エンコードするものである。通常の年の１２ヶ月であるか、うるう年の１３ヶ月であるか（１太陽年あたり１うるう月だけが可能である）の何れかがあることに注意されたい。本実施形態は、グレゴリオ暦の年における計算機の範囲を特定するものであり、上述のリソースを大量に消費する従来技術の解決策に容易に関連するため、１９８０年〜２１００年に対する実施を示す。サンプルコードは、TCalconData::iCalConDataMonthと呼ばれるCALCONDATA.CPPファイル内のこれらの整数の配列を示す。この配列から、検討中である日付範囲における１２０年の各年に対し、それぞれ１６ビットの整数が存在することが分かる。グレゴリオ暦１９８０年の開始は、この１２０年の期間における旧暦の最初の周期の５５年の間に位置する。これは、配列内の最初の整数に付けられた０−５５のコメントを説明し、進行が容易に理解できるようにしている。グレゴリオ暦１９８０年の開始は、旧暦５５年の最後であり、旧暦５５年は、グレゴリオ暦１９８０年の開始直後から始まる年ではない。旧暦の新年は、常に１月（January）か２月（February）であるため、グレゴリオ暦１９８０年の開始は、旧暦５５年の最後の月又は最後から２番目の月の何れかとなる。また、旧暦５５年がうるう年であるか否か、現在の月がうるう月であるか否か、そして、その年の残りの月が２９日間又は３０日間あるか否かを知る必要がある。従って、グレゴリオ暦１９８０年に付けれた情報は、グレゴリオ暦1979年に始まった旧暦の年も参照する必要がある。
【００４６】
TCalconData::iCalConDataMonthにおける１番目の整数は、38608であり（１６ビットバイナリ配列1001011011010000に対応する）、これは旧暦５５年の情報を保有する。本発明のこの例では、この数列（sequence）におけるバイナリ「１」ビットは、３０日間の月を示し、バイナリ「０」ビットは、２９日間の月を示す。従って、このバイナリ配列、従って整数は、旧暦５５年の始めは３０日間あるので、１番目、４番目、６番目、７番目、９番目、１０番目及び１２番目が新しい月であり、この年の残りの月は２９日間あることを示している。TCalconData::iCalConDataMonthにおける２番目の整数は、38320であり、これは、グレゴリオ暦１９８０年が始まる旧暦５６年の情報を保有し、この整数は、バイナリ配列1001010110110000に対応する。従って、この整数は、旧暦５６年の始めから、１番目、４番目、６番目、８番目、９番目、１１番目及び１２番目の月が３０日間あり、この年の残りの月が２９日間あることを示している。
【００４７】
CALCONDATA.CPPファイルにおける２番目の配列は、TCalconData::iCalConDataYearと呼ばれ、３２ビットの整数の配列からなる。一方、各年にはそれぞれ整数が存在し、配列内に示したコメントは、これらが前の配列に対するデータと適合することを明確にしている。各整数は、それぞれの年のより詳細な情報を提供する。各整数はまた、それぞれの年がいつ始まり、その年にうるう月があるか否か、もしあれば、どの月にあるかを知らせる。
【００４８】
この配列における第１の整数は、1881492094であり、現在のグレゴリオ暦１９８０年の始めである旧暦５５年に対する情報を与える。この３２ビット整数の最下位ビット28は、旧暦５５年の始めに対応するユリウス日を保持する。
【００４９】
1881492094は、バイナリ配列01110000001001010100101001111110に対応し、バイナリ数字000001001010100101001111110がこの情報を提供する。これらの最下位ビット27は、ユリウス日2443902に対応している。ユリウス日からグレゴリオ暦の日付への変換は、非常に簡単であり、計算コストがかからない。そのような変換は、ユリウス日2443902が旧暦５５年の新年の日付であるグレゴリオ暦１９７９年１月２８日に対応することを示している。
【００５０】
1881492094に対応する３２ビット整数の最上位の４ビットは0111であり、７に対応する。この情報は、このエンコードが１９７９年１月２８日に始まる旧暦の新年のどの月（もしあれば）がうるう月であるかを示している。旧暦の年には、そもそもうるう月が１つしかない。従って、この場合、旧暦５５年はうるう年であり、その年の７番目の月はうるう月であることが分かる。これは、その年の７番目の月は、実際にはうるう月６であり、うるう月ではない７の月は、実際にはその年の８番目の月になることに注意されたい。配列における２番目の整数は、2444286であり、これはバイナリ数列00000000001001010100101111111110に対応している。この数列では、最上位４ビットは0000であり、これはゼロに対応する。これは、旧暦５６年がうるう月を含まず、従って、うるう年でないことを意味する。最下位ビット28は、１９８０年２月２９日に対応するユリウス日2444286、従って、旧暦５６年の新年であったことを意味する。
【００５１】
CALCONDATA.Hファイルは、問題となっている期間に対する旧暦データを解釈するために必要な全ての他のデータを提供し、関係したデータ範囲の境界を与え（ユリウス日2444240である1980年１月１日から、ユリウス日2488434である2100年１２月３１日まで）、また、考慮中である１２０年の期間の最初の旧暦の新年が旧暦５６年であり、この１２０年の期間の最後の旧暦の新年が旧暦５７年であり、この１２０年の期間が周期７９で始まり、データが全体で旧暦の１２２年の範囲にわたることを伝える。
【００５２】
CALCONDATA.CPP及びCALCONDATA.Hに与えられたデータは、予め作成され、携帯型計算機のリードオンリーメモリ（ＲＯＭ）を構築するために使用されうる。これらのデータがどのように作成されるかは、本発明には重要ではない。これらは、ReingoldとDershowitzの方程式から計算されうる。また、南京の紫金山天文台又は他の公表された暦からのデータでも十分であろう。
【００５３】
上述の開示は、その動作を提供する背後のデータや理論の構成に関して、計算機用のPIMタイプのアプリケーションにおいて、これらのファイルが如何にして有効に使用されうるを十分に説明していると考えられる。従って、当業者であれば、ReingoldとDershowitzの方程式に代わって、技術的に優れたものを提供するために、本発明を容易に実施することができ、それによって、計算機リソース及び変換時間の点において、ユリウス日と旧暦の日付との間で、高速かつ高性能な変換を行うことができる。
【００５４】
テーブルで表される日付の範囲の任意の旧暦の日付に対し、正確な旧暦の年に対するファイルテーブルの入力に直接移ることができ、全ての月の日の長さと任意の該当するうるう月のデータとともに、旧暦の年に対する新年のユリウス日を直接確かめることができる。従って、任意の旧暦の日付に対応した、ユリウス日、従ってグレゴリオ暦の日付を決定するためには、計算機で簡単かつ高速に実行可能な比較的小さい数の比較的簡単な四則演算を必要とする。
【００５５】
その日付の範囲の任意のユリウス日に対し、そのユリウス日の直前の旧暦の新年を含むテーブルの入力に直接移ることができ、月の長さと任意の該当するうるう月の情報が一旦調べられると、正確な旧暦の日付を求めることも、特別の困難がなく、素早く実施することができる比較的簡単な四則演算である。
【００５６】
また、完全のために、下記に示す本発明の例も、サンプルプログラムファイルの一部を提供する。CHINESEUSINGTABLE.CPPは、どのように使用することができるかを示すためのサンプルとして提供されたテーブル内のデータを扱う手順を含んだ、Symbian OS（登録商標）基本ソフト用に書かれた作業プログラムから取得したコードの一部を含む。
【００５７】
当業者であれば、他の実施や更なる最適化が可能であることに容易に気づくであろう。特に、旧暦の新年ごとにユリウス日を一致させるという条件は、必ずしも必要ではなく、実際は、旧暦の日付とユリウス日が知られている１つの同日の日付だけで与えられる月の長さ及びうるう月データから算術的にこれらを求めることができる。
【００５８】
更なる配列の圧縮と共に、この任意の最適化によって、日付の範囲内の各々の付加的な旧暦の年に対するオーバーヘッドが、上述の実施形態で用いられているように、１年当たり６バイト（又は４８ビット）から、最低でも１年当たり１７ビットまで減少されることができ、メモリの観点から更なるリソースの節約が可能となる。しかしながら、このタイプのビット配列を解凍するときに、何らかの付加的な計算コストがかかり、このタイプの実施はまた、与えられた同日の時点から離れた日付での演算をもたらし、同日の時点により近い日付でその演算を完了するのに時間がかかることになるだろう。
【００５９】
毎年ほどは頻繁に現れない、複数の同時時点を持つハイブリッドも、明らかに可能である。本発明によって製造された、任意の装置に対するトレードオフの選択は、設計者に委ねられてもよいが、添付の特許請求の範囲に定められた本発明は、全てのこのような実施に適用されることを意図しており、上述の好適な実施の形態のみに限定されない。以下の例は、グレゴリオ暦１９８０年〜２１００年までのメイン参照テーブルを提供する。このテーブルは、任意のうるう月と旧暦の新年のユリウス日とを表した、ビットマップ配列がその後に続く月の長さを示すビットマップ配列を含む。
2008537189.tif 000003
2008537189.tif 000004
2008537189.tif 000005
2008537189.tif 000006
2008537189.tif 000007
2008537189.tif 000008
以下のテーブルは、グレゴリオ暦１９８０年〜２１００年に対する付加的なカレンダー情報を示している。
2008537189.tif 000009
これらは、一連の有用なカレンダー分類を作り上げるためにテーブルがどのように使用されるかを示すコードの断片である。
2008537189.tif 000010
2008537189.tif 000011
2008537189.tif 000012
2008537189.tif 000013
2008537189.tif 000014
2008537189.tif 000015
2008537189.tif 000016
2008537189.tif 000017
図２は、ユリウス日の番号と旧暦の日付との間で変換を行うために用いられる処理をまとめたフローチャートを示す図である。
【００６０】
本発明は、旧暦の機能を提供する現在の処理よりも、大きな技術上の利益を提供するということが、上述の説明と特定の例から分かるであろう。本発明は、以下のものを含む。
・特定の年の番号の全体にわたって、制約されたリソースを備える計算機上であっても、高速に動作する、十分な旧暦の機能を利用する方法
・メモリやＣＰＵ使用などの計算リソースの高効率な使用
・コストがかかり、非常に長い浮動小数点番号演算は含まない
・縮小されたメモリ使用：同程度の現在のテーブルルックアップ方法の０．０１％未満
・十分なPIM機能を備える計算機が、旧暦が広範囲に使用される国で働く人に、更に容易に供給される
・実施される装置の電力が、大幅に低下し、これによって自然資源の点で環境上の利点があり、これを実施する装置のバッテリーの寿命が更に長くなる
本発明は、特定の実施形態を参照して説明しているが、添付の特許請求の範囲により定められた本発明の範囲を逸脱しない限り、修正がなされうることが分かるであろう。
【図面の簡単な説明】
【００６１】
【図１】任意の旧暦の年に発生する２９日間の月と３０日間の月とを決定する処理を示す図である。
【図２】本発明に係るユリウス日の番号と旧暦の日付との間の変換処理を示す図である。
【図１】
2008537189.tif 000018
【図２】
2008537189.tif 000019
【国際調査報告】
2008537189.tif 000020