C 言語のプログラムの汚さで競い合う有名なプログラミングコンテスト IOCCC の今年の結果が公開されました。 ref: http://www.ioccc.org/years.html#2012 目を見張る変態ぞろいですので、ぜひご覧ください。個人的には、deckmyn 、hamano 、hou 、kang 、tromp あたりがお気に入りです。nyaruko は内容より spoiler がすごい。あれエディタでアタリなしで描いてんのかよ、という。 ぼくのプログラムが 2 つ入賞していますのでご紹介。以下、ネタバレ＋自慢エントリなので嫌な人は見ないで！ PiE in the sky award のエントリ Most complex ASCII fluid のエントリ ref: http://www.ioccc.org/2012/endoh2/endoh2.c ref: http://www
Chordアルゴリズムの解説ページです。 掲載コンテンツへのリンク先を変更する可能性があるので、ブックマークやリンクは、このページにお願いします。 Chordは、DHT（Distributed Hash Table）と呼ばれる種類のPeer-to-Peerアルゴリズムです。 特に、構造化オーバレイ（Structured Overlay Network）と呼ばれるルーティング手法に特徴があります。 解説スライドでは、そもそもDHTとは何なのかという初歩的なことから、successorやpredecessor、finger tableと呼ばれるChordの有名な経路表の解説や、多くの解説ではあまり触れられることがないけれどもきわめて重要である、ネットワークの構築方法（join・stabilize）についても詳細に解説しています。 スライドのページ数は多いですが、１ページ当たり平均数秒で読めるは
STMはソフトウェアトランザクショナルメモリの略です。 ↓とりあえずwikipedia http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%AB%E3%83%A1%E3%83%A2%E3%83%AA 日本でSTMの話題を検索すると「楽観的ロックでしょ？」といった発言を見かける事が多く、確かに実用的な手法の多くはロックベースだったりしていますが、正直なところロックベースな手法のSTMはデータベースでのトランザクションと似ているフシがあったりしてデータベースに詳しい人からするとそれほど驚くような手法ではない事が多いのです。その
昨日一昨日、Google App Engine (GAE)に関する日本最大の勉強会（だと思う）appengine ja night #7 (ajn7)が行われました。 その中で『ランキング問題』が話題に上がりました。『ランキング問題』とは、何十万件もの点数のデータがあるときに、App Engine上で、「◯点は何位です」と高速に求めることは難しい、という問題です。（◯ページ目を表示、というページングもこれと同じ種類の問題になります。） ajn7では「上位でない限り正確な順位は必要ないのではないか」という話になりましたが、Skiplistを用いた検索アルゴリズムを使えば正確かつ高速に順位を求めることができるのではないかと思い、実装＆検証してみました。 ランキング（順位取得）のデモ 下記ページで順位取得のデモを動かしています。スコア（点数）を入力すると順位と取得にかかった時間が表示されます（時
今回はパーティクルフィルタを簡単に紹介。 (Wikipedia: 粒子フィルタ – Wikipedia) これは、一般状態空間モデルにおける状態ベクトルの推定法で、 Wikipediaではなにやら難しげに書かれているように見えますが、 要は、条件付き分布をたくさんのサンプル点で近似表現するだけの手法です。 この手法は、逐次モンテカルロ法とも呼ばれているように、 ランダムサンプリングによるモンテカルロ近似によって状態推定を行います。 パーティクルフィルタを物体追跡に適用するためには、 ・システムモデル（状態遷移関数） ・観測モデル（尤度関数） の2つを設計する必要があります。 今回は状態遷移に線形予測モデル、つまり等速直線運動を仮定し、 尤度(ゆうど：もっともらしさ)は “赤色らしさ” とします。 この尤度関数の設計はOpenCVのサンプルコードからお借りしました。感謝。 wonderflに
id:smoking186 さんの指摘を受け, First Authorの名前などを付加しました. どうもです. 記事内のcodeは最適化などを施しておらず, 冗長に, 定義どおりに書いています. ifがまとめられたりとかしますが, そのあたりはご容赦を... Rubyでlevenshtein距離を見て以来, 個人的にdiffブームが来ていた. 計算量O(ND) / O(NP)のalgorithmなどがあるのは知っていたが, 論文(英語)および, 解説のみ, またはソースコードのみなど分かれているものが多く, algorithmに疎い自分には理解するのに大変時間がかかってしまった. しかしやっとわかったので, 解説+JS実装してみる. 解説とソースコードがセットだと, 多少はわかりやすくなるかと... 自分は正直これくらい細かく言われないとすぐにはわかんない人なので(the O(ND)だけ
これはすごい！ というわけでTwitter検索を3倍高速化したという記事を翻訳してみました。Twitter Engineering: Twitter Search is Now 3x Faster2010年春。Twitterの検索チームは、我々の増え続けるトラフィックに対応し、エンドユーザにとっての遅延を減らし、我々のサービスの可用性を向上させ、新しい検索の機能を素早く開発できるようにするため、検索エンジンを書きなおす作業を始めた。 その努力の一部として、我々は新しいリアルタイム検索をリリースし、検索のバックエンドをMySQLからLuceneのリアルタイム版に変更した。そして先週、我々はRuby-on-Railsに取って代わるフロントエンドをローンチした。我々がBlenderと呼ぶJavaサーバーである。我々はこの変更によって検索のレイテンシが3分の1になり、検索機能の開発を促進できるよう
数年ぶりにA*アルゴリズムを実装したので、まとめなおしておきます。何回かじっくり読むとようやく理解が出来てきました。基本的にそんなに難しくないアルゴリズムです。 概要 「A*アルゴリズム」は、A-Star（エースター）と読み、パス探索アルゴリズムの一つです。 ノードネットワーク上にスタート地点とゴール地点を結ぶパスが存在すれば、最悪でもそのパスの存在を確認できるアルゴリズムです（見落とすことがない）。 内容はシンプルな再帰計算で、コスト計算の部分にヒューリスティックと呼ばれるパラメータがあり、その算出アルゴリズムを変更することにより、各種アプリの状況に応じた高速化と最適化が望めます。 2007-07-16 修正 「A* - Wikipedia」の擬似コードを見ていたら、自分の書いたコードでは最適なルートを計算しない可能性があることが分かりましたので修正しました。下記のC++的擬似コード内で
ダブル配列（ Double-Array ）は， トライ（ Trie ）のデータ構造の一種であり， 小さい辞書で高速に検索できるという特長を持っています． 実際に，茶筌（ ChaSen ）や 和布蕪（ MeCab ）などの 形態素解析器で利用されているという実績があります． ダブル配列では，配列を使ってトライを表現します． 配列の各要素が BASE, CHECK という二つの整数を持つので，頭文字をとって配列 BC と呼ぶことにします． 以降の説明では，配列 BC の要素 x の BASE, CHECK を それぞれ BC[x].BASE, BC[x].CHECK と記述します． 通常，BASE, CHECK は個別の配列として紹介されますが， 特に分割して考える必要がないので，このような説明にしました． 基本的に，配列 BC の各要素は トライの節と一対一で対応します． そのため，対応する
「ダブル配列におけるキャッシュの効率化」という論文を見付けた。FIT2006というフォーラムで発表されたものらしい。これはすごい。目から鱗が落ちた。なんかリンク張って良いものか迷うので、とりあえずはリンクしない。 この論文に書いてあることは2つあって、ひとつは配列サイズの削減で、もうひとつはできるだけキャッシュミスを減らすための方法である。配列サイズを削減するための方法がすごい。これまで誰も考え付かなかったのか、それとも考え付いたけどやらなかったのか？ まず、checkの要素サイズは1byteで十分である。なぜなら、遷移元のインデックスがわからなくても、遷移に使ったキーの値がわかれば十分なので。これでDoubleArray全体のサイズを5/8に減らせる。また、普通、1GBのDouble Arrayを作成したりすることは無い（せいぜい100MB程度だろう）ので、Baseにも4byteも割り当
一番右端の立っているビット位置を求める「ものすごい」コード - 当面C#と.NETな記録 「ものすごい」コードなのだけど、凄過ぎて自分には全くチンプンカンプン...。それでも、どの辺が凄いのか、ちゃんと理解したい。シンプルなコードから順を追って確かめてみた。 public static int GetNumberOfTrailingZeros( long x ) { if ( x == 0 ) return 64; ulong y = ( ulong ) ( x & -x ); int i = ( int ) ( ( y * 0x03F566ED27179461UL ) >> 58 ); return table[ i ]; } static int[] table; table = new int[ 64 ]; ulong hash = 0x03F566ED27179461UL; for
as詳解 ActionScript 3.0アニメーション ―衝突判定・AI・3DからピクセルシェーダまでFlash上級テクニック を読んでいて、経路探索のアルゴリズムで A* が取り上げられていました。A* については、いろいろ検索して調べたりもしたのですが、やっぱり本に書いてあると理解しやすいですね。せっかくなので自分流に実装してビジュアライズしてみました。ダイクストラ法まずは A* の特別なケースでもあるダイクストラ法から見ていきます。クリックすると探索のシミュレーションが開始します。スタート地点(S)からゴール(G)への探索が始まります。色がついたところが「最短経路が決定した場所」です。スタート地点から少しずつ探索が完了していきます。半分ぐらい完了しました。まだまだ進みます。最後まで終わりました。最短経路を黒色矢印で表示しています。ダイクストラ法は、スタート地点から近いノード(=マス
いよいよ今回から、具体的なアルゴリズムの紹介に入っていきます。今回は、プログラミングにおける重要な概念である「探索」について考えます。グラフに変換し、探索する、という流れを知るとともに、そのグラフを効率よく探索する方法について紹介します。 今後紹介していくアルゴリズムについて お待たせしました！ 「最強最速アルゴリズマー養成講座」という連載タイトルのとおり、今回の連載からいよいよ具体的なアルゴリズムの紹介に入っていきたいと思います。 しかし、それを読んでいただく前に、1つ注意してもらいたいことがあります。連載第3回でもお伝えしたように、「問題を、既存の適当なアルゴリズムに当てはめる」という考え方は、非常に危険である、ということです。 筆者の経験上、TopCoderでRedCoder以上を目指すのであれば、回答時間短縮のために、いままでのパターンを利用するのも方法の1つなのですが、本連載では
更新履歴 2004/01/07 O(N) 構築アルゴリズム三種追加（Ko &Alulu, Kim & al., Karkkainen & Sanders) Suffix Arrayは、最近注目を集めているデータ構造です。その理由として、 (1)大規模なデータに対して、高速に検索、情報抽出を行うことができる (2)BWTとしてデータ圧縮に用いることができる。 ことが挙げられます。(1)に関しては自然言語処理において、膨大な量のコーパスから情報（例えば、単語の出現回数など）を調べるときににSuffix Arrayを用いると非常に高速に求めることができます。 膨大な量のコーパスに基づいた自然言語処理が盛んになってきている今、Suffix Arrayが注目を集めています。 また、ゲノム情報を調べるバイオインフォマティクスにおいても、ここの配列と似ている部分（例えばCCAG）を調べるといった場合
接尾辞配列（せつびじはいれつ）やサフィックス・アレイ（英: suffix array）とは、文字列の接尾辞（開始位置を異にし終端位置を元の文字列と同じくする部分文字列）の文字列中の開始位置を要素とする配列を、接尾辞に関して辞書順に並べ替えて得られる配列である。接尾辞木の配列版。主に文字列探索、全文検索などに利用される。1990年に Udi Manber と Gene Myers が発表した[1]。
Hatena のキーワード置換アルゴリズムがTRIE ベースの手法に変更になったようです。以前に AC法でやる方法の記事を書いたのですが、それと似たことをやってるのでしょうか。 AC法のやり方は単純で、前方から最長一致でキーワードを見つけていきます。これまでは長いキーワードから順番に見つけていく方法(最長キーワード優先一致)だったそうですが、前方から見つけていく方法だと短いキーワードが優先される場合があります。 http://d.hatena.ne.jp/ita/20060119/p1 http://d.hatena.ne.jp/hatenadiary/20060119/1137667217 本文：あいうえおかきくけこさしすせそ KW1 いう KW2 うえおかき KW3 かきく KW4 きくけこさし という文でKW1-KW4のキーワードがマッチする場合、新しくなった方法では「いう」と「かき
3次元のkd木。根セル（白）をまず2つの部分セルに分割（赤）し、それぞれをさらに2つに分割（緑）している。最後に4つのセルそれぞれを2つに分割（青）している。それ以上の分割はされていないので、最終的にできた8つのセルを葉セルと呼ぶ。黄色の球は木の頂点を表している。 kd木（英: kd-tree, k-dimensional tree）は、k次元のユークリッド空間にある点を分類する空間分割データ構造である。kd木は、多次元探索鍵を使った探索（例えば、範囲探索や最近傍探索）などの用途に使われるデータ構造である。kd木はBSP木の特殊ケースである。 kd木は、座標軸の1つに垂直な平面だけを使って分割を行う。BSP木では分割平面の角度は任意である。さらに一般的には、kd木の根ノードから葉ノードまでの各ノードには1つの点が格納される[1]。この点もBSP木とは異なり、BSP木では葉ノードのみが点（ま
A*探索アルゴリズム A*（A-star、エースター）探索アルゴリズム（エースターたんさくアルゴリズム）は、グラフ探索アルゴリズムの一つ。 最良優先探索を拡張したZ*に、さらにf値として「現時点までの距離」g と「ゴールまでの推定値」h の和を採用したもの[1]。h は ヒューリスティック関数と呼ばれる。 A* アルゴリズムは、「グラフ上でスタートからゴールまでの道を見つける」というグラフ探索問題において、 ヒューリスティック関数 h(n) という探索の道標となる関数を用いて探索を行うアルゴリズムである。h は各頂点 n からゴールまでの距離のある妥当な推定値を返す関数で、解くグラフ探索問題の種類に応じてさまざまな h を設計することが出来る。 例えば、カーナビなどで用いられる単純な二次元の地図での探索では、h としてユークリッド距離 を使うことができ、この値は道に沿った実際の距離のおおま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
