WordNetとWiktionaryから作った統合英和辞書を転置して和英辞書を作る際に、訳語を正規化するとともに、関連語の訳語を伝搬して、再現率を高めようという話。公開運用サイトはこちらなので、使ってみていただきたい。これで再現率に関しては英辞郎に匹敵する…

子供達が最近よくドラえもんの話をしてくる。児童館で原作の単行本を借りて読んだり、ドラえもんを題材とした漢字の教材に取り組んだりしているためだ。これはよい機会と思い、藤子F不二雄ミュージアムに連れ出してみた。

久しぶりにE-M10を持って子供を連れてお台場に行ってきた。やっぱたまに撮ると楽しい。

いろいろ調べてからヘッドホン（イヤホン）を買ったという話。自分の需要とコスパを考えて、KZ ZS10 proを選んだのだが、なかなか満足しているので、推奨の言葉を書いてみたい。

EPUB対応の電子書籍リーダーで共通して使えるEPUBの電子辞書データを作ろうと思いたち、例のWiktionaryとWordNetの統合辞書データを変換して実際に作ってみた。また、一連の英和辞書関連のプロジェクトページも作った。

オープンなデータで英和辞書と和英辞書を構築して検索する連載の5回目である。今回は、曖昧一致検索も含めた複雑なパターン一致検索を実装し、さらに類語検索も実装する。曖昧一致検索と類語検索は、辞書の利便性を飛躍的に高めてくれる。いつものデモサイト…

英和辞書・和英辞書として使える辞書検索システムを作る連載の4回目である。今回はWictionaryから辞書データを抽出して、WordNetとも併合して、本物の英和辞書として使えるシステムを構築した。今回もデモサイトを作ったので、お試しいただきたい。凝った機…

DBMで単語辞書を作る連載の3回目だ。今回はデモを実装した。仕様を単純化したプロトタイプであり、基本的な機能の説明をするのに丁度よいはずだ。それにもかかわらず、普通に実用できるものに仕上がっている。

前回、Wikipediaの記事を解析して、単語の共起語のデータベースを作った。今回は、共起語データベースを解析して類語を推定する。すなわち、共起語データベースをシソーラスとみなして、関連語の検索を行う。

DBMで単語辞書を作る連載の2回目だ。今回作る辞書検索システムの看板機能は、類語検索である。そして、類語を自動的に推定するための一手法として、共起語を使う方法がある。ここでは、Wikipediaをコーパスとして、共起語を抽出する。

キーワード検索システムとか全文検索システムとか検索エンジンとか呼ばれる仕組みの肝は転置索引とか転置インデックスとか呼ばれるデータベースである。それは、検索語をキーとして、その検索語に該当する文書のIDのリストを値とする連想配列に他ならない。…

reallocを使ってメモリアロケーションのサイズを少しずつ伸ばしていく際に、償却時間計算量はO(N)になるだろうか、それともO(N^2)だろうか。結論としては、普通にやるとO(N^2)になる。ただし、セオリー通りにアプリケーション側で工夫するとO(N)にできる。性…

データベースマネージャTkrzwを無事にリリースしたはよいが、ドッグフードは自分で食わないといけない。DBMを作るとまず最初にやりたくなるのが、それを使った単語辞書を作ることである。仕事柄、英和辞書と和英辞書はよく使うのだが、自分で作ったものを毎…

レンタルのVPSで自分のLinuxサーバを運用しているわけだが、その再インストールと再設定を行った。新しいドメイン名を取得して、新しいOSを入れて、Webサーバを立てて、開発環境を構築する。これはその手順の自分用のメモだが、似たようなことをしたい人には…

データベースライブラリであるTkrzwの初版をリリースした。Kyoto Cabinetの正式な後継製品である。本家のサイトはここである。設計目標の通り、高速かつ堅牢で多目的に使える実装になったと思っている。私の下手な英文を読ませるのも忍びないので、ここに概…

キーと値の連想配列であるDBMのインターフェイスでLRUレコード削除機能付きのキャッシュ機構を実装してみた話。

頭脳労働者諸氏が家に籠もって仕事をするようになって早数ヶ月、その末席に連なる私も、自室の椅子に座って一日中作業をするのが日常になった。環境の変化によって多かれ少なかれ体調を崩す人もいることだろう。腰痛とか肩こりとか頭痛とか鬱とか。私の場合…

データベースの文脈において、シャーディングとは普通はデータベースを行で水平分割して複数の計算機に割り当てることを意味する。今回は敢えてそれをローカルで行う機能について考えてみたい。つまり、単一の計算機上でデータベースファイルを複数に分けて…

この週末の頑張りで、Tkrzwの実装がほぼ全て完了した。権利関係の処理が済むまでにもうちょいかかりそうなので、先に各種プログラミング言語でのAPIについて語りたい。C++、Java、Python、Rubyのインターフェイスを比較してみると面白い。

小ネタなのだが、ラテン文字のマッチング用の正規化処理を自前で書くにはどうすれば最も簡単なのか考えてみた。

長きに渡った集中連載もこれでひとまずは終了である。過去ログはこちらを見てね。最後に実装作業の計画についてまとめておこう。

DBMをRDBMS風に使うためにセカンダリインデックスを使いたくなる場合もあるかもしれない。その設計と実装について考えてみたい。

DBMでサービスを提供している最中に、データベースファイルのバックアップを取りたくなることがあるだろう。当然、サービスのダウンタイムにならないように、データベースにアクセスする他のスレッドはブロックしないで行いたい。それにはどうするか。

私が設計したDBMに特徴的な機能である、アトミックなレコード処理について詳しく紹介したい。以前誰かがデータベースのクンフーであると言ってくれた面白い機能だ。

ファイルI/Oの実装として、ファイルの内容に同期したメモリ上の領域にアクセスするメモリマップI/Oを利用する際のインターフェイスについて考察する。

DBMのインターフェイスでオンメモリのストレージを実現できる。その設計と実装について考えてみよう。

スキップデータベースを検索するアルゴリズムの要点について考えてみる。メモリ確保の戦略が重要になってくる。

ソート済みのレコードの連結リストにスキップリストを付与したものがスキップデータベースである。その具体的な書式についてここで完全に定義する。

ハッシュデータベースとツリーデータベースの設計については一段落したので、次にスキップリストデータベースの設計に移る。まずはスキップリストの概要についてまとめてみよう。

ツリーデータベースを実装するにあたり、具体的にどういうデータ構造を使うかを検討する。並列化についてもここで検討する。