JP2020004132A - 検索装置、検索方法、プログラム、及び記録媒体 - Google Patents

Abstract

【課題】木構造で表現される辞書データを高速に検索する。【解決手段】辞書データを格納した記憶手段と、入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置において、前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記演算手段は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する。【選択図】図５

Description

本発明は、辞書データを入力文字列に基づいて検索することにより、単語の意味等を取得する検索技術に関連するものである。

一般に辞書データは、単語とその意味を格納したテーブルの形式で実現される。このようなテーブル形式の辞書データからある単語（入力文字列）を検索する場合、入力文字列と膨大な数の単語（例：１００万語）との文字列マッチングを行わなければならず、処理が遅くなる。

そこで、辞書データをＢ木、トライ、Ｐａｔｒｉｃｉａ木などの木構造を用いてインデックス化することで、高速に検索を行う技術が従来から存在する。

特開２０１７−０９１４３２号公報

しかし、従来技術では、木のデータ量が非常に大きくなるため、検索速度が低下する等の問題があった。

本発明は上記の点に鑑みてなされたものであり、木構造で表現される辞書データを高速に検索することを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、辞書データを格納した記憶手段と、
入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、
前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
前記演算手段は、
入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する
ことを特徴とする検索装置が提供される。

本発明の実施の形態によれば、木構造で表現される検索対象データを高速に検索することが可能となる。

マルチウェイ基数探索方法を説明するための図である。 本発明の実施の形態に係る検索装置１０の構成図である。 辞書の構成例を示す図である。 記憶部１２に格納される検索対象データの例を示す図である。 本実施の形態における検索対象データの構造及び検索処理の概要を説明するための図である。 内部ノードとリーフノードのより具体的な例を示す図である。 検索処理の手順を説明するためのフローチャートである。 リーフノードのデータの圧縮例を説明するための図である。 圧縮例におけるデータ構造の例を説明するための図である。 リーフノードのデータの圧縮例を説明するための図である。 圧縮例におけるデータ構造の例を説明するための図である。 内部ノードのデータの圧縮例を説明するための図である。 ｌｅａｆ ｍａｓｋを適用する場合における内部ノードのデータ構造を示す図である。 ｌｅａｆ ｍａｓｋを使用する場合において、リーフの値を取得する処理のフローチャートである。 ｌｅａｆ ｍａｓｋに関するデータ作成方法を説明するための図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（探索方法について）
本実施の形態では、検索装置に入力した文字列をキーとして辞書データを検索することにより、当該文字列の意味等を出力する処理を想定している。以下では、検索（探索）の対象とする辞書データを検索対象データと呼ぶ。また、検索のキーとなるデータ（入力文字列）をキーデータと呼ぶ。

本実施の形態では、検索対象データを検索する手法として、多進木で表現されるマルチウェイ基数探索法を用いているので、まず、マルチウェイ基数探索法の概要を図１を参照して説明する。

マルチウェイ基数探索法では、キーデータを先頭から所定数の複数ビット（以下、チャンクと呼ぶ）ずつに分け、当該複数ビット毎に木の遷移を行う。図１は、２ビットずつチャンクとする例である。これは、例えば１文字を８ビットで表わす場合において、２ビット毎に分岐を行う例に相当する。なお、非マルチウェイ探索では１ビットずつ分岐を行うが、マルチウェイ探索では、このように複数ビット毎に分岐を行うことが可能である。

各チャンクは４種類の値（図１に示すように００、０１、１０、１１の４種類の値）を取り得るから、木における各ノードは４方向に分岐する。分岐先は内部ノード（図１で丸で示すノード）もしくはリーフノード（図１で四角で示すノード）である。

キーデータにおける最初のチャンクから一段目のノードで探索を開始し、該当する値の子ノードに分岐し、キーを次のチャンクに進めることで、順次探索を行い、リーフノードに到達したら探索終了となる。

図１の例で、例えば、キーデータが１１である場合、５で示すリーフノードに到達する。また、キーデータが０１０１である場合、６で示すリーフノードに到達する。リーフノードには、例えば、文字列の意味を示す情報が格納され、リーフノードに到達した場合、キーデータに対応する意味の情報を取得できる。なお、「意味」は検索結果の一例である。

上記の例は、チャンク長を２ビットとする例であるが、例えば、６４ビットＣＰＵアーキテクチャを用いる場合、ビット幅を同一にして演算を効率的にするために、チャンク長を６ビットとして、各ノードで６４分岐する木のデータ構造を使用することができる。また、チャンク長を８ビットとして各ノードで２５６分岐する木のデータ構造を使用することもできる。

上記のようなマルチウェイ基数探索法においては、一般に、各ノードは、子ノードをポイントするためのポインタ（子ノードを格納するアドレス等）を分岐数分持つ。各ポインタが、例えば６４ビットあるいは２５６ビットで子ノードを指定すると、全体の木のデータ量が非常に大きくなるという問題がある。そのため、このようにポインタを用いる構成では、木のデータを汎用ＣＰＵのキャッシュ等に格納し切れず、ＣＰＵの外にあるメモリあるいはハードディスクに格納せざるを得ないため、検索速度が低下するという問題がある。

一方、本実施の形態に係る技術では、上記の技術に比べて、各内部ノードのデータ量を大幅に削減できるとともに、同じデータを持つノードを圧縮することもできるため、全体の木のデータ量を小さくすることができ、汎用ＣＰＵのキャッシュに木のデータを格納して処理を行うことが可能となり、高速な検索処理が可能となる。以下、本実施の形態に係る技術をより詳細に説明する。

（装置構成例）
まず、本実施の形態に係る検索処理を実行する検索装置の構成例を説明する。図２は、本実施の形態に係る検索装置１０の構成例を示す図である。

図２に示すように、検索装置１０は、演算部１１、記憶部１２、入力部１３、出力部１４を備える。演算部１１は、後述する方法でキーデータ（入力文字列）を用いた検索対象データ（辞書データ）に対する検索処理を実行する機能部である。記憶部１２は、検索対象データを格納する機能部である。入力部１３は、キーデータを入力する機能部である。出力部１４は検索結果を出力する機能部である。

例えば、検索装置１０は、汎用コンピュータであり、演算部１１と記憶部１２がＣＰＵを構成する。また、記憶部１２は、ＣＰＵ内のキャッシュでもよいし、ＣＰＵ外のメモリであってもよいし、ハードディスク等の記憶装置であってもよい。当該ＣＰＵは、本実施の形態に係る処理のロジックを持つプログラムに従って動作する。当該プログラムは記憶部１２に格納される。また、当該プログラムは記憶部１２以外の記憶装置に格納されてもよい。

当該プログラムは、可搬メモリ等の記録媒体に格納して、当該可搬メモリから汎用コンピュータにロードすることで、当該コンピュータを検索装置１０として使用することができる。

また、演算部１１と記憶部１２を、本実施の形態に係る処理のロジックをハードウェア回路として組み込んだ装置として構成することもできる。

以下、検索装置１０により実行される検索処理を詳細に説明する。以下、基本的な処理を行う方式を実施例１として説明し、実施例１に対してノードの圧縮を可能とした機能を加えた例を実施例２〜４として説明する。

（実施例１）
図３は、本実施の形態における検索対象となる辞書の構成例を示す図である。図３に示すように、辞書は、単語とその意味（単語の説明）からなる。なお、単語に対応付けられる情報は任意であり、"意味"は一例である。例えば、意味に代えて、あるいは、意味に加えて、単語に対応する他の言語の単語、単語に対応する漢字、単語に対応する品詞、あるいは単語に対応するＵＲＬなどが、単語に対応付けられる情報であってもよい。

本実施の形態では、辞書をインデックス化して、検索対象データ（辞書データ）とし、検索装置１０の記憶部１２に格納する。

図４に、検索装置１０の記憶部１２に格納される検索対象データの例を示す。図４は、実施例１〜４に共通である。前述したように、本実施の形態では、マルチウェイ基数探索法をベースとした検索処理を行うことから、検索対象データは、木における各内部ノードのデータを保持するｎｏｄｅ ａｒｒａｙ（ノード配列）と、木における各リーフノードのデータであるｌｅａｆ ａｒｒａｙ（リーフ配列）を有する。配列として格納される各ノードのデータには、各配列のＩｎｄｅｘを指定することでアクセスできる。

ｌｅａｆ ａｒｒａｙとｎｏｄｅ ａｒｒａｙからなる検索対象データ（辞書データ）は、例えば可搬メモリ等の記録媒体に格納して、当該可搬メモリから検索装置１０にロードすることで、検索装置１０を検索対象データに対する検索装置１０として使用することができる。また、検索対象データを、あるコンピュータからネットワークを経由して検索装置１０にロードすることもできる。

図５を参照して、実施例１における内部ノードのデータ構造について説明する。図５は、チャンクのビット長が２の場合、つまり、木の各ノードから４方向に分岐する場合の例であるが、チャンクのビット長が何ビットであっても同様の構造である。なお、例えば１文字が８ビットで表わされる場合において、入力文字列から切り出される２ビットのチャンクは文字そのものではないが、文字を構成する情報であることから、チャンクを文字情報と呼ぶことができる。

図５に示すように、内部ノードは、ｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１を有する。ｖｅｃｔｏｒは、当該内部ノードからの分岐数のビットからなるビットベクトルである。キーデータのチャンクが２ビットの場合、００、０１、１０、１１の４種類の値を取り得る。ｖｅｃｔｏｒの各ビットは、右端から順に、上記４種類の各値に対応している。なお、「右端から」とするのは一例であり、「左端から」であってもよい。例えば、ｌｉｔｔｌｅ ｅｎｄｉａｎのＣＰＵを用いる場合に右端から数え、ｂｉｇ ｅｎｄｉａｎのＣＰＵを用いる場合に左端から数える。

図５の例では、例えば、ｖｅｃｔｏｒの右端（０番目）のビットがチャンク００に対応し、１番目のビットがチャンク０１に対応し、２番目のビットがチャンク１０に対応し、３番目のビットがチャンク１１に対応する。ｖｅｃｔｏｒの各ビットは、当該内部ノードからの遷移先（子ノード）が、内部ノードであるか、リーフノードであるかを示す。本実施の形態では、１が内部ノードを示し、０がリーフノードを示すが、これは例であり、１がリーフノードを示し、０が内部ノードを示すように構成してもよい。

例えば、図５に示す内部データに対応するチャンクが００、０１、１０、１１のうちの０１であった場合、演算部１１は、ｖｅｃｔｏｒの０番目から数えて１番目のビット（１）を参照することで、次のノードは内部ノードであることを把握する。また、例えば、チャンクが００、０１、１０、１１のうちの００であった場合、演算部１１は、ｖｅｃｔｏｒの０番目のビット（０）を参照することで、次のノードはリーフノードであることを把握する。

上記のように演算部１１は、ｖｅｃｔｏｒにより遷移先のノードが内部ノードであるかリーフノードであるかを把握できるが、このままでは、内部ノード／リーフノードのデータを取得するために、ｎｏｄｅ ａｒｒａｙ／ｌｅａｆ ａｒｒａｙにおけるどのＩｎｄｅｘの要素にアクセスすればよいかわからない。そこで、本実施の形態では、内部ノードはｂａｓｅ０、ｂａｓｅ１を保持する。

ｂａｓｅ１は、ｎｏｄｅ ａｒｒａｙにおける、当該内部ノードのｖｅｃｔｏｒのビット１に対応する子の内部ノードの格納開始Ｉｎｄｅｘを保持する。ｂａｓｅ０は、ｌｅａｆ ａｒｒａｙにおける、当該内部ノードのｖｅｃｔｏｒのビット０に対応する子のリーフノードの格納開始Ｉｎｄｅｘを保持する。

本実施の形態では、ｎｏｄｅ ａｒｒａｙにおいては、各内部ノードについて、当該内部ノードの子となる内部ノードのデータがＩｎｄｅｘの順番で格納されている。例えば、ある内部ノードについて、子の内部ノードが３つある場合、当該子の内部ノードの３つのデータは、ｎｏｄｅ ａｒｒａｙにおいて、Ｉｎｄｅｘが連続する３つのデータとして格納される。この３つのデータのうちＩｎｄｅｘが先頭（最小）となるデータのＩｎｄｅｘがｂａｓｅ１である。

また、ｌｅａｆ ａｒｒａｙにおいて、各内部ノードについて、当該内部ノードの子となるリーフノードのデータがＩｎｄｅｘの順番で格納されている。例えば、ある内部ノードについて、子のリーフノードが３つある場合、当該子のリーフノードの３つのデータは、ｌｅａｆ ａｒｒａｙにおいて、Ｉｎｄｅｘが連続する３つのデータとして格納される。この３つのデータのうちＩｎｄｅｘが先頭（最小）となるデータのＩｎｄｅｘがｂａｓｅ０である。なお、本実施の形態で使用するＩｎｄｅｘは、格納場所を指す指標であり、これを「アドレス」と言い換えてもよい。

上記のようにしてｎｏｄｅ ａｒｒａｙ／ｌｅａｆ ａｒｒａｙにデータが格納されていることから、演算部１１は、次のようにして、ｂａｓｅ０／ｂａｓｅ１を用いて子の内部ノード／リーフノードのデータにアクセスする。

ｖｅｃｔｏｒのあるビット位置（０番目から数えてｖ番目とする）の子の内部ノードへのアクセスに関し、演算部１１は、ｖｅｃｔｏｒの０番目からｖ番目までのビット位置の１の個数を算出（カウント）する。つまり、ｖｅｃｔｏｒの右端から（ｖ＋１）ビットの中の１の個数を算出する。この個数をｂｃ（ｂｉｔ ｃｏｕｎｔ）とすると、演算部１１は、ｎｏｄｅ ａｒｒａｙにおいて、ｂｃにｂａｓｅ１を加えた値から１を引いた値（ｂｃ＋ｂａｓｅ１−１）のＩｎｄｅｘにアクセスすることで該当内部ノードのデータを取得できる。

ｖｅｃｔｏｒのあるビット位置（０番目から数えてｖ番目とする）の子のリーフノードへのアクセスに関し、演算部１１は、ｖｅｃｔｏｒの０番目からｖ番目までのビット位置の０の個数を算出（カウント）する。つまり、ｖｅｃｔｏｒの右端から（ｖ＋１）ビットの中の０の個数を算出する。この個数をｂｃ（ｂｉｔ ｃｏｕｎｔ）とすると、演算部１１は、ｌｅａｆ ａｒｒａｙにおいて、ｂｃにｂａｓｅ０を加えた値から１を引いた値（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘにアクセスすることで該当リーフノードのデータを取得できる。

図５には、上記の方法で、子の内部ノード（Ｉｎｄｅｘ：２４９８）、及びリーフノード（Ｉｎｄｅｘ：３１２７〜３１２９）にアクセスすることが示されている。また、リーフノードのアドレスには、そのリーフノードに到達した単語の意味等（あるいは意味等の格納場所へのポインタアドレス）が格納される。

一般にＣＰＵにはビットの数を高速に算出するｐｏｐｃｎｔという機能が備えられており、本実施の形態では、この機能を有効に活用でき、高速に探索を行うことができる。なお、ｐｏｐｃｎｔを使用することは例であり、ｐｏｐｃｎｔを使用しないこととしてもよい。

図５は、チャンク長が２ビット、つまり、ｖｅｃｔｏｒが４ビットである例を示しているが、これは例であり、チャンク長／ｖｅｃｔｏｒは他の長さであってもよい。図６に、チャンク長が６ビット、つまり、ｖｅｃｔｏｒが６４（２^６）ビットである場合の例を示す。図６には、既に説明したとおりに、内部ノードがｖｅｃｔｏｒ、ｂａｓｅ０／ｂａｓｅ１を有し、ビットカウント及びｂａｓｅ０／ｂａｓｅ１により、子の内部ノード／リーフノードにアクセスできることが示されている。

本実施の形態では、内部ノードは、ビットベクトルと２つのｂａｓｅを持てばよく、分岐毎にポインタを有する方式に比べて、各ノードのデータ量を大幅に削減でき、結果として、検索対象データのデータ量を削減できる。

図７を参照して、演算部１１が実行する検索処理の処理手順を説明する。この処理の前提として、演算部１１にはキーデータが入力され、また、記憶部１２には、上述した構造を持つ検索対象データ（ｎｏｄｅ ａｒｒａｙ／ｌｅａｆ ａｒｒａｙ）が格納されているものとする。また、図７は、リーフノードに到達することで検索処理が終了する例を示している。

演算部１１は、ｎｏｄｅ ａｒｒａｙにおける最初の内部ノードからｖｅｃｔｏｒを取得し（ステップ１０１）、また、キーデータ（入力文字列）から最初のチャンク（文字情報）を取得する（ステップ１０２）。

演算部１１は、チャンクに該当するｖｅｃｔｏｒの位置のビットを読み、当該ビットが１であるかどうか判定する（ステップ１０３）。当該ビットが１である場合、前述したように、ビットカウントｂｃを算出し、（ｂｃ＋ｂａｓｅ１−１）のＩｎｄｅｘに格納されている内部ノードにアクセスして、当該内部ノードのｖｅｃｔｏｒを取得する（ステップ１０４）。

演算部１１は、キーデータから次のチャンクを取得し（ステップ１０５）、再びステップ１０３の判定を実行する。

ステップ１０３の判定の結果、チャンクに該当するｖｅｃｔｏｒの位置のビットが０である場合（ステップ１０３のＮｏ）、ステップ１０６に進む。ステップ１０６において、演算部１１は、前述したように、ビットカウントｂｃを算出し、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘに格納されているリーフノードにアクセスして、当該リーフノードの値（例：単語の意味）を取得する。

（実施例２）
次に、実施例２として、実施例１で説明した方式に対して、リーフデータを圧縮できる方式を説明する。例えば、辞書として、単語と、その単語の品詞を対応付けた辞書を用いる場合において、重複する値（名詞、動詞、助詞等）を持つリーフノードが多く発生することが考えられる。実施例２は、実施例１の方式をベースとし、リーフノードを圧縮して保持できるようにしている。以下では、主に実施例１と異なる部分について説明する。

図８は、実施例２における内部ノードを示す図である。図８に示すように、実施例２においては、実施例１で説明したｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１に加えて、ｌｅａｆｖｅｃが追加される。ｌｅａｆｖｅｃはｖｅｃｔｏｒのビット長と同じビット長である。

また、ｌｅａｆ ａｒｒａｙにおける各内部ノードの子になるリーフノード（つまり、各段のリーフノード）に関して、同じ値を持つ連続するリーフノードは、連続が開始する最初のリーフノードのみが保持される。図８の例では、Ｉｎｄｅｘが３１２７、３１２８、３１２９のリーフノードに関して、値は全部同じで「名詞」であり、この場合、Ｉｎｄｅｘが３１２７のリーフノードのみが保持される。このような圧縮の結果、複数のリーフノードがある場合でも、同じ値を持つ複数のリーフノードを含まず、それぞれ異なる値となる。

ｌｅａｆｖｅｃの要素は０又は１のビットであり、右端から、圧縮前のリーフノードの連続が開始する位置に対応するビットに１が立てられている。例えば、図８の例では、最初のリーフノードから連続が始まるので、当該最初のリーフノードに対応する最初（０番目）のビットに１が立てられている。また、連続が終わり別の値のリーフノードが始まる場合（リーフノードが変化する場合）、その位置に１が立てられる。リーフノードが変化する場合とは、最初のリーフノードを含む。ここでの「連続」とは１個の場合を含む。つまり、リーフノードのデータが全て異なる場合、リーフノードに対応するｌｅａｆｖｅｃのビット位置には全て１が立てられる。ｌｅａｆｖｅｃの使用方法は以下のとおりである。

演算部１１が、チャンクに対応するｖｅｃｔｏｒのビット（０番目から数えてｖ番目のビットとする）が０であることを検出すると、子がリーフノードであることを把握する。演算部１１は、ｌｅａｆｖｅｃにおける右端の０番目から数えてｖ番目までのビット（ｖ＋１個のビット）における１のビットの個数を算出する。当該個数をｂｃとすると、ｖｅｃｔｏｒの場合と同様に、演算部１１は、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘのリーフノードにアクセスする。

図９に、実施例２における内部ノードとリーフノードのデータ例を示す。図９の例において、演算部１１は、チャンクに基づき、（ａ）で示す内部ノードにおけるｖｅｃｔｏｒの０番目から数えた１番目のビットが１であることを検知し、それに対応する（ｃ）の内部ノードにアクセスすることが示されている。また、例えば、（ａ）の内部ノードにおいて、チャンクが０番目から数えた２番目（０）に対応する場合に、演算部１１は、ｌｅａｆｖｅｃにおける２番目までの３ビットにおける１の個数を算出し、ｂａｓｅ０を用いて、当該個数に対応するリーフノード（Ｌ（０））にアクセスする。

リーフノードの圧縮は、上記のようにｌｅａｆｖｅｃを用いる以外の方法で実現してもよい。以下、リーフノードの圧縮に係る他の方法を実施例３として説明する。ただし、実施例３の方法は、ｌｅａｆｖｅｃを用いる方法と実質的に同じである。

（実施例３）
図１０は、実施例３における内部ノードを示す図である。図１０に示すように、実施例３においては、実施例１で説明したｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１に加えて、ｍａｓｋが追加される。ｍａｓｋはｖｅｃｔｏｒのビット長と同じビット長である。

また、ｌｅａｆ ａｒｒａｙにおける各内部ノードの子になるリーフノード（つまり、各段のリーフノード）に関して、同じ値を持つ連続するリーフノードは、連続が開始する最初のリーフノードのみが保持される。図１０の例では、Ｉｎｄｅｘが３１２７、３１２８、３１２９のリーフノードに関して、値は全部同じで名詞であり、この場合、Ｉｎｄｅｘが３１２７のリーフノードのみが保持される。このような圧縮の結果、複数のリーフノードがある場合でも、同じ値を持つ連続する複数のリーフノードを含まない。

ｍａｓｋの要素は０又は１のビットであり、右端から、圧縮前のリーフノードの連続が開始する位置に対応するビットに０が立てられ、当該開始位置から同じ値の連続するリーフノードの位置に１（マスク）が立てられる。また、連続が終わり別の値のリーフノードが始まる場合（リーフノードが変化する場合）、その位置に０が立てられる。リーフノードが変化する場合とは、最初のリーフノードを含む。

なお、内部ノードに該当する位置は、１を立ててもよいし、０でもよいが、本例では０としている。図１０の例では、３つのリーフノードが連続するから、最初のリーフノードに該当するビット位置に０が立てられ、以降のリーフノードに該当するビット位置にはマスクである１が立てられる。ｍａｓｋの使用方法は以下のとおりである。

演算部１１が、チャンクに対応するｖｅｃｔｏｒのビット（０番目から数えてｖ番目のビットとする）が０であることを検出すると、子がリーフノードであることを把握する。実施例３では、演算部１１は、ｖｅｃｔｏｒとｍａｓｋのＯＲ演算を行って、ＯＲ演算を行った後のｖｅｃｔｏｒにおける右端の０番目から数えてｖ番目までのビット（ｖ＋１個のビット）における０のビットの個数を算出する。当該個数をｂｃとすると、演算部１１は、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘのリーフノードにアクセスする。

図１１に、実施例３における内部ノードとリーフノードのデータ例を示す。図１１の例において、演算部１１は、チャンクに基づき、（ａ）で示す内部ノードにおけるｖｅｃｔｏｒの０番目から数えた１番目のビットが１であることを検知し、それに対応する（ｃ）の内部ノードにアクセスすることが示されている。また、例えば、（ａ）の内部ノードにおいて、チャンクが０番目から数えた２番目（０）に対応する場合に、演算部１１は、ｍａｓｋ後のｖｅｃｔｏｒにおける２番目までの３ビットにおける０の個数を算出し、ｂａｓｅ０を用いて、当該個数に対応するリーフノード（Ｌ（０））にアクセスする。

ｍａｓｋは内部ノードの圧縮にも適用できる。ｍａｓｋを内部ノードの圧縮に適用する例を図１２を参照して説明する。図１２は、図６と同様に、チャンク長が６ビット、つまり、ｖｅｃｔｏｒが６４（２^６）ビットである場合の例を示している。この例でも、実施例１で説明したｖｅｃｔｏｒ、ｂａｓｅ０、ｂａｓｅ１に加えて、ｍａｓｋが追加される。ｍａｓｋはｖｅｃｔｏｒのビット長と同じビット長である。

また、各段の内部ノードに関して、同じ値を持つ連続する内部ノードは、連続が開始する最初の内部ノードのみが保持される。図１２の例では、（ａ）に示すように、同一のサブツリーを持つ内部ノードが３つある。この場合、（ｂ）に示すように、３つのうちの最初の内部ノードのみが保持される。このような圧縮の結果、複数の内部ノードがある場合でも、同じ値を持つ連続する複数の内部ノードを含まない。

ｍａｓｋの要素は０又は１のビットであり、右端から、圧縮前の内部ノードの連続が開始する位置に対応するビットに１が立てられ、当該開始位置から同じ値の連続する内部ノードの位置に０（マスク）が立てられる。また、連続が終わり別の値の内部ノードが始まる場合（内部ノードが変化する場合）、その位置に１が立てられる。

図１２の例では、３つの内部ノードが連続するから、最初の内部ノードに該当するビット位置に１が立てられ、以降の内部ノードに該当するビット位置にはマスクである０が立てられる。つまり、図１２（ｂ）に示すように、ｖｅｃｔｏｒの最初の１に対応するｍａｓｋのビットは１であり、次の１とその次の１に対応するｍａｓｋのビットは０である。ｍａｓｋの使用方法は以下のとおりである。

演算部１１が、チャンクに対応するｖｅｃｔｏｒのビット（０番目から数えてｖ番目のビットとする）が１であることを検出すると、子が内部ノードであることを把握する。演算部１１は、ｖｅｃｔｏｒとｍａｓｋのＡＮＤ演算を行って、ＡＮＤ演算を行った後のｖｅｃｔｏｒにおける右端の０番目から数えてｖ番目までのビット（ｖ＋１個のビット）における１のビットの個数を算出する。当該個数をｂｃとすると、演算部１１は、（ｂｃ＋ｂａｓｅ１−１）のＩｎｄｅｘの内部ノードにアクセスする。

（実施例４）
次に、実施例４について説明する。実施例４は、実施例２、３よりも更にリーフノードを圧縮できる方式である。実施例４における内部データの構造を図１３に示す。図１３に示すように、実施例４の内部データは、既に説明したｖｅｃｔｏｒ、ｌｅａｆｖｅｃ、ｂａｓｅ０、ｂａｓｅ１に加えて、「Ａ」で示すように、ｌｅａｆ ｍａｓｋとｍａｓｋｅｄ ｌｅａｆが追加されたものである。記憶部１２にはｎｏｄｅ ａｒｒａｙとｌｅａｆ ａｒｒａｙが格納されている。

ｌｅａｆ ｍａｓｋはｖｅｃｔｏｒと同じビット長の０／１のビットからなるデータである。ｍａｓｋｅｄ ｌｅａｆは、あるリーフノードのデータである。以下、ｌｅａｆ ｍａｓｋとｍａｓｋｅｄ ｌｅａｆを用いる場合の演算部１１の動作を説明する。

図１４のフローチャートを参照して、実施例４における検索装置１０の演算部１１の動作例を説明する。図１４は、実施例１、２とは異なる処理の部分を特に説明するためのものである。

ステップ２０１において、演算部１１は、現在のチャンクのｖｅｃｔｏｒにおける該当ビット（０番目から数えてｖ番目のビットとする）が０であることを検出することで、リーフノードに遷移することを検出する。

ステップ２０２では、演算部１１は、ｌｅａｆ ｍａｓｋにおいて０番目から数えてｖ番目のビットが１であるかどうかを判定する。これが１である場合（ステップ２０２のＹｅｓ）、ｍａｓｋｅｄ ｌｅａｆの値をリーフデータの値として取得する（ステップ２０３）。

ステップ２０２において、ｖ番目のビットが１でない場合（ステップ２０２のＮｏ）、演算部１１は、実施例２と同様にして、ｌｅａｆｖｅｃの０番目からｖ番目までの１の個数（ｂｃ）を算出し、（ｂｃ＋ｂａｓｅ０−１）のＩｎｄｅｘのリーフノードにアクセスして値を取得する（ステップ２０４）。

次に、図１５を参照して、実施例４におけるｌｅａｆ ｍａｓｋに関連するデータの作成方法を説明する。以下で説明するデータの作成は、検索装置１０が行ってもよいし、他の装置（コンピュータ）が行ってもよい。以下では、データの作成を行う装置を作成装置と呼ぶ。作成装置は、検索装置１０又は他の装置である。作成装置が他の装置である場合、データ作成後に、作成データを検索装置１０の記憶部１２に格納する。

まず、作成装置は、圧縮なしでｌｅａｆ ａｒｒａｙを計算する。これにより、例えば４分木であれば、親の内部ノード毎に、例えば図５のＬで示すように、Ｉｎｄｅｘが連続するリーフノードのデータが作成される。

また、６４分木であれば、親の内部ノード毎に、ｌｅａｆ ａｒｒａｙの項目数は最大で６４になる。また、例えば１６分木の例において、リーフ情報が３種類のＡ、Ｂ、Ｃ（例えば、名詞、動詞、助詞）であるとすると、リーフ情報が、図１５（ａ）に示すとおり、例えばＡＢＡＡ ＢＢＢＡ ＢＣＢＢ ＣＣＣＣのようにｌｅａｆ ａｒｒａｙ内に並ぶ。

次に、作成装置は、マスクされるリーフ情報を選ぶ。本例では、Ｂをマスクして省略することにする。一般には、連続する断片が現れる回数が最も多いものをマスクするのが有効であることから、作成装置は、連続する断片が現れる回数が最も多いＢをマスクすると決定する。なお、「連続する断片」は、ＡＢＡにおけるＢのように１つの場合を含む。マスクされたリーフの情報Ｂは、ｍａｓｋｅｄ ｌｅａｆに格納する。

次に、作成装置は、マスクされるリーフ情報が現れるスロットを、ｌｅａｆ ｍａｓｋ に保存する。マスクされるリーフ情報が現れるスロットとは、ｖｅｃｔｏｒにおける当該リーフに対応するビット位置に相当する。例えば、ｖｅｃｔｏｒが００１０である場合に、左端を１番目として数えて２番目のビット０に対応するリーフをマスクする場合、ｌｅａｆ ｍａｓｋに、０１００が保存される。

また、作成装置は、ｌｅａｆ ａｒｒａｙにおいて、マスクされるリーフ情報のスロットを、直前の値と同じにする。これにより、図１５（ａ）に示すリーフ情報から、図１５（ｂ）に示すように、「ｌｅａｆ ｍａｓｋ：０１００ １１１０ １０１１ ００００」が得られ、「ｌｅａｆ ａｒｒａｙ： ＡＡＡＡ ＡＡＡＡ ＡＣＣＣ ＣＣＣＣ」が得られる。なお、本例は、ｂｉｇ ｅｎｄｉａｎであるため、左端から数える。図１５（ｂ）において、下線部分がマスクされた部分であり、数える方向での直前の値（左の値）と同じ値になっている。

次に、リーフマスク無しの場合と同じように、連続する部分を圧縮する。これにより、図１５（ｃ）に示すように、「ｌｅａｆｖｅｃ：１０００ ００００ ０１００ ００００」となり、「ｌｅａｆ ａｒｒａｙ：ＡＣ」となる。

上記の処理の結果、図１５（ｄ）に示すように、「ｌｅａｆ ｍａｓｋ： ０１００ １１１０ １０１１ ００００」、「ｍａｓｋｅｄ ｌｅａｆ：Ｂ」、「ｌｅａｆ ｖｅｃｔｏｒ：１０００ ００００ ０１００ ００００」、「ｌｅａｆ ａｒｒａｙ：ＡＣ」が得られる。

なお、参考までに、リーフマスク無しで圧縮した場合のｌｅａｆ ａｒｒａｙは「ＡＢＡＢＡＢＣＢＣ」となり、実施例４により高い圧縮効果が得られることがわかる。

実施例４では、マスク１つ（例：６４ｂｉｔ）とリーフ１つが追加されるが、不連続であったいくつかのリーフを省略することができ、ｌｅａｆ ａｒｒａｙのさらなる圧縮が実現できる。これは、リーフ１つの大きさ（ｌｅａｆ ａｒｒａｙの１エントリのサイズ）が１６バイトなど大きかった場合などに特に有効となる。

なお、実施例２、３、４は、リーフノードを圧縮する例を示しているが、同じデータを持つ内部ノードに関しても、リーフノードの場合と同じようにして、圧縮することが可能である。また、リーフノードの圧縮と内部ノードの圧縮の両方を行うこととしてもよい。

（実施の形態の効果）
以上、説明したように、本実施の形態では、木のデータ量を大幅に削減できることから、例えば汎用ＣＰＵのキャッシュ（例：Ｌ１、Ｌ２、Ｌ３キャッシュ）に検索対象データを格納して検索処理を実施でき、高速な検索処理を実現できる。

また、木の各レベルで、ビット単位で部分木の有無を表現するため、メモリ効率が良い。特に、例として６４分木を用いる場合、６４ビットずつ部分木の有無（子配列）を表現するため、６４−ｂｉｔ ＣＰＵでの処理効率が良いという特徴を持つ。

また、ｖｅｃｔｏｒ等において、１であるビットを数え、配列の中の該当する子に１ステップで飛べるため、高速処理を実現でき、メモリ効率も良い。また、１であるビットを数えるために、ｐｏｐｃｎｔ ＣＰＵ ｉｎｓｔｒｕｃｔｉｏｎ を使用でき、高速処理を実現できる。また、汎用的な多進木（Ｍｕｌｔｉｗａｙ ｔｒｉｅ）をベースにしているため、拡張性・柔軟性が高く、経路表検索に限らず、様々な検索に適用できる。

更に、実施例２〜４で説明したリーフ情報の圧縮を行うことで検索対象データの量を小さくでき、更なる高速化を実現できる。

（実施の形態のまとめ）
以上、説明したように、本実施の形態により、辞書データを格納した記憶手段と、入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記演算手段は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行することを特徴とする検索装置が提供される。

前記辞書データにおける各内部ノードは、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスするように構成してもよい。

前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報と、前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。

前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するリーフベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。

前記演算手段は、前記ビットベクトルと前記リーフベクトルのうちの前記ビットベクトルを先に調べ、当該ビットベクトルのビットの値に基づき前記リーフベクトルを使用することとしてもよい。

前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスするようにしてもよい。

前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納されており、同じ値を持つ内部ノードは圧縮され、複数の内部ノードは、同じ値を持つ複数の内部ノードを含まず、前記辞書データにおける各内部ノードは、圧縮前の内部ノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスすることとしてもよい。

前記辞書データの各内部ノードについて、遷移先となるリーフノードにおける所定の値がマスクされ、当該マスクされた値が別の値に変更された後に、同じ値を持つリーフノードが圧縮されたことにより、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記リーフノード配列において、格納位置が連続して格納されており、前記辞書データにおける各内部ノードは、前記マスクされた所定の値と、当該所定の値を持つリーフベクトルの圧縮前の位置を示すビットを有するリーフマスクと、圧縮前のリーフノードの値が変化した格納位置を示すビットからなるリーフベクトルとを含み、前記演算手段は、前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記ビットベクトルにおける当該ビットの位置と同じ位置に、前記リーフマスクにビットが立っているか否かを判定し、立っている場合に、前記所定の値を当該遷移先のリーフノードの値として取得し、立っていない場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスすることとしてもよい。

前記演算手段は、当該演算手段により構成されるＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出することとしてもよい。

また、前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成することとしてもよい。また、前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長であることとしてもよい。

また、前記演算手段と前記記憶手段は、６４ビットＣＰＵ上で構成し、前記チャンクは、６ビット長であり、前記ビットベクトルは、６４ビット長であり、前記演算手段は、前記６４ビットＣＰＵのｐｏｐｃｎｔ命令を用いて前記ビットの数を算出し、前記遷移先のノードへのアクセスを、ベース情報からの、当該ビットの数に基づくオフセットを用いて行うこととしてもよい。

また、前記演算手段は、前記キーデータから前記所定ビット長よりも長いビット長のチャンクを取得し、当該チャンクを用いて探索を行うことにより、ダイレクトにリーフノードに到達するようにしてもよい。

また、本実施の形態により、コンピュータを、前記検索装置における各手段として機能させるためのプログラムを提供することもできる。また、本実施の形態により、前記辞書データを格納したコンピュータ読み取り可能な記録媒体を提供することもできる。

なお、上述した「記憶手段」は、記憶部、記憶回路、記憶デバイスのいずれかと置き換えてもよい。また、上述した「演算手段」は、演算部、演算回路、演算デバイスのいずれかと置き換えてもよい。

また、本実施の形態に係る検索方法を、入力文字列に基づき辞書データに対する検索処理を行う検索方法であって、前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、前記検索方法は、入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報の値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行するステップを有することを特徴とする検索方法として構成してもよい。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０、２０ 検索装置
１１ 演算部
１２ 記憶部
１３ 入力部
１４ 出力部

Claims (10)

1. 辞書データを格納した記憶手段と、
   入力文字列に基づき前記辞書データに対する検索処理を行う演算手段と、を備える検索装置であって、
   前記記憶手段に格納される前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
   前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
   前記演算手段は、
   入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行する
   ことを特徴とする検索装置。
2. 前記辞書データにおける各内部ノードは、遷移先の１つの内部ノードの格納位置を示す第１のベース情報、及び、遷移先の１つのリーフノードの格納位置を示す第２のベース情報を含み、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報を用いて当該遷移先の内部ノードにアクセスし、遷移先がリーフノードである場合に、前記第２のベース情報を用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする請求項１に記載の検索装置。
3. 前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納され、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスし、
   遷移先がリーフノードである場合に、前記第２のベース情報と、前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする請求項２に記載の検索装置。
4. 前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、
   前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するリーフベクトルを含み、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする請求項２に記載の検索装置。
5. 前記辞書データにおける各内部ノードについて、遷移先となるリーフノードは、前記リーフノード配列において、格納位置が連続して格納されており、同じ値を持つリーフノードは圧縮され、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、
   前記辞書データにおける各内部ノードは、圧縮前のリーフノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記第２のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおけるリーフノードを示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする請求項２に記載の検索装置。
6. 前記辞書データにおける各内部ノードについて、遷移先となる内部ノードは、前記内部ノード配列において、格納位置が連続して格納されており、同じ値を持つ内部ノードは圧縮され、複数の内部ノードは、同じ値を持つ複数の内部ノードを含まず、
   前記辞書データにおける各内部ノードは、圧縮前の内部ノードの値が変化した格納位置を示すビットを有するマスクベクトルを含み、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先が内部ノードである場合に、前記第１のベース情報と、前記マスクベクトルでマスクした前記ビットベクトルにおける内部ノードを示すビットの数とを用いて当該遷移先の内部ノードにアクセスする
   ことを特徴とする請求項２に記載の検索装置。
7. 前記辞書データの各内部ノードについて、遷移先となるリーフノードにおける所定の値がマスクされ、当該マスクされた値が別の値に変更された後に、同じ値を持つリーフノードが圧縮されたことにより、複数のリーフノードは、同じ値を持つ複数のリーフノードを含まず、前記リーフノード配列において、格納位置が連続して格納されており、
   前記辞書データにおける各内部ノードは、前記マスクされた所定の値と、当該所定の値を持つリーフベクトルの圧縮前の位置を示すビットを有するリーフマスクと、圧縮前のリーフノードの値が変化した格納位置を示すビットからなるリーフベクトルとを含み、
   前記演算手段は、
   前記ビットベクトルのビットの値に基づき判定された遷移先がリーフノードである場合に、前記ビットベクトルにおける当該ビットの位置と同じ位置に、前記リーフマスクにビットが立っているか否かを判定し、立っている場合に、前記所定の値を当該遷移先のリーフノードの値として取得し、立っていない場合に、前記第２のベース情報と、前記リーフベクトルにおける前記格納位置を示すビットの数とを用いて当該遷移先のリーフノードにアクセスする
   ことを特徴とする請求項２に記載の検索装置。
8. コンピュータを、請求項１ないし７のうちいずれか１項に記載の前記検索装置における各手段として機能させるためのプログラム。
9. 請求項１ないし７のうちいずれか１項に記載の前記辞書データを格納したコンピュータ読み取り可能な記録媒体。
10. 入力文字列に基づき辞書データに対する検索処理を行う検索方法であって、
    前記辞書データは、内部ノード配列とリーフノード配列を有する多進木構造のデータであり、
    前記辞書データにおける各内部ノードは、遷移先が内部ノードであるかリーフノードであるかをビットで表したビットベクトルを含み、
    前記検索方法は、
    入力文字列から文字情報を取得し、アクセスしている内部ノードの前記ビットベクトルにおける当該文字情報の値に対応するビットに基づき、当該内部ノードからの遷移先が内部ノードであるか、リーフノードであるかを判定し、遷移先のノードにアクセスする処理を、遷移先がリーフノードになるまで繰り返し実行するステップを有する
    ことを特徴とする検索方法。

Images