巡回セールスマン問題における最短経路をpgRoutingで探索する
先日、PostgreSQLアンカンファレンスを開催した際、「pgRoutingを使って巡回セールスマン問題を解く」という発表を国府田さんがされていました。 第8回 PostgreSQLアンカンファレンス＠東京（2016/9/10） - connpass http://pgunconf.connpass.com/event/37285/ 第8回 PostgreSQLアンカンファレンス ツイートまとめ - Togetterまとめ http://togetter.com/li/1023030 非常に面白そうな機能で、私も少し使ってみましたので、今回はその使い方や使用例などを含めてご紹介します。 ■「巡回セールスマン問題」とは何か 「巡回セールスマン問題」というのは、以下のようなものです。 巡回セールスマン問題（じゅんかいセールスマンもんだい、英: traveling salesman probl
データベースのテーブル結合アルゴリズムを調べた - yattのブログ
入れ子ループ 一行づつ、全てのキーとチェックをかけて同じかチェックするよ ソートマージ ２つのテーブルをソートしてからチェックするのでキーの比較回数少ないよ セミジョイン 分散ＤＢ前提。キーをリモートホストに送信して部分的な結合結果を受け取って、その結果を基に最終的な結合結果を計算するよ。データの転送量減るよ 理解のために簡単にそれっぽい動作をpythonで実装してみた MySQL、Oracleなどで結合にどんなアルゴリズムを使っているのかは、クエリプランを見るとわかるらしい。 sqlite3は内部結合はwhere句に単純に展開されるらしかった。 http://www.sqlite.org/optoverview.html
なぜBTreeがIndexに使われているのか - maru source
※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます（特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう？？ Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (本の最後によみがな順で単語が並べられたりしています
MinHashによる高速な類似検索 - Preferred Networks Research & Development
年が明けてもう一ヶ月経ちましたね．岡野原です． 今日はMinHashと呼ばれる手法を紹介します．これは特徴ベクトルの高速な類似検索に利用することができます(クローラーの文脈だとShingleとして知られている）． 今や世の中のあらゆる種類のデータが，高次元のバイナリベクトルからなる特徴ベクトルで表されて処理されるようになってきました．例えば文書データであれば文書中に出現する単語やキーワードの出現情報を並べた単語空間ベクトル（Bag of Words）で表し，画像データも，SIFTをはじめとした局所特徴量を並べた特徴ベクトル（とそれをSkecth化したもの）として表せます．行動情報や時系列データも特徴量をうまく抽出する．グラフデータもFast subtree kernels[1]と呼ばれる方法で非常に効率的に特徴ベクトルに変換することができ，グラフの特徴をよく捉えることができるのが最近わかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
