[Groonga-commit] groonga/grnxx at acb735e [master] Update TODOs.

アーカイブの一覧に戻る

susumu.yata null+****@clear*****
Fri May 30 17:57:26 JST 2014


susumu.yata	2014-05-30 17:57:26 +0900 (Fri, 30 May 2014)

  New Revision: acb735e4c5f82fb910123154848caa0c636ab3a0
  https://github.com/groonga/grnxx/commit/acb735e4c5f82fb910123154848caa0c636ab3a0

  Message:
    Update TODOs.

  Modified files:
    new-interface/table.hpp

  Modified: new-interface/table.hpp (+37 -4)
===================================================================
--- new-interface/table.hpp    2014-05-30 16:42:58 +0900 (795a32a)
+++ new-interface/table.hpp    2014-05-30 17:57:26 +0900 (8bb8df6)
@@ -262,17 +262,50 @@ class Table {
       const SorterOptions &options,
       Error *error) const = 0;
 
-  // TODO: Grouper
+  // 分類器を作成する.
+  // 成功すれば有効なオブジェクトへのポインタを返す.
+  // 失敗したときは *error にその内容を格納し, nullptr を返す.
+  //
+  // 返り値は std::unique_ptr なので自動的に delete される.
+  // 自動で delete されて困るときは release() で生のポインタを取り出す必要がある.
+  //
+  // TODO: 時刻のカラムについて,月や曜日によるグループ化ができると便利である.
+  //       同様に値の範囲(たとえば 100 ずつ)でグループ化ができると便利である.
+  //
+  // TODO: 各グループの構成要素が必要かどうか,構成要素の数が必要かどうか,
+  //       などのオプションによって実装を切り替えることが望ましい.
+  //       たとえば,構成要素が不要であればハッシュ表がよさそうである.
+  //
+  // TODO: 配列型の要素単位でグループ化する場合,
+  //       入力された行 ID の一覧を整列する方法では対処できない.
+  //       そのため, Grouper で適当なデータ構造を用意する必要がある.
   //
-  // 時刻のカラムについて,月や曜日によるグループ化ができると便利である.
-  // 同様に値の範囲(たとえば 100 ずつ)でグループ化ができると便利である.
+  // TODO: グループの数は未知なので,呼び出し側で確保した領域に
+  //       グループの情報を格納するというインタフェースが使いにくい.
+  //       そのため, Grouper に領域を確保させるか,
+  //       グループ化の結果を少しずつ取り出せるようにするなどの工夫が必要である.
   //
-  // グループ単位の集計操作は個別に実装を検討する.
+  // 失敗する状況としては,以下のようなものが挙げられる.
+  // - オプションが不正である.
+  // - リソースが確保できない.
+  virtual std::unique_ptr<Grouper> create_grouper(
+      const GrouperOptions &options,
+      Error *error) const = 0;
 
   // TODO: 検索結果の型を決める.
   //
   // 行 ID の配列とスコアの配列に分けるのと,
   // 行 ID とスコアをメンバとする構造体の配列にする案がある.
+  //
+  // 前者はスコアを必要としないクエリを無駄なく処理できるのが魅力です.
+  // その代わり,フィルタをかけるにせよ整列をするにせよグループ化をするにせよ,
+  // スコアがある状況では効率がそれなりに悪くなることが予想されます.
+  //
+  // 後者は,スコアが不要なときに無駄なメモリ消費が発生したり,
+  // キャッシュの効率が少し低下したりすることが予想されます.
+  //
+  // 正直なところ,後者の方が良いのではないかという気がしてきました.
+  // 一度,簡単なプログラムでも作って試してみた方がよいだろうと思います.
 
   // TODO: 検索結果のマージ方法を検討する.
   //
-------------- next part --------------
HTML����������������������������...
ダウンロード 



More information about the Groonga-commit mailing list
アーカイブの一覧に戻る