algorithmに関するflakwingのブックマーク (191)

  • トップクラスだけが知る「このアルゴリズムがすごい」――「探索」基礎最速マスター

    トップクラスだけが知る「このアルゴリズムがすごい」――「探索」基礎最速マスター:最強最速アルゴリズマー養成講座(1/4 ページ) プログラミングにおける重要な概念である「探索」を最速でマスターするために、今回は少し応用となる探索手法などを紹介しながら、その実践力を育成します。問題をグラフとして表現し、効率よく探索する方法をぜひ日常に生かしてみましょう。 まだまだ活用可能な探索 前回の「知れば天国、知らねば地獄――『探索』虎の巻」で、「探索」という概念の基礎について紹介しました。すでに探索についてよく理解している方には物足りなかったかと思いますが、「問題をグラフとしてうまく表現し、そのグラフを効率よく探索する」というアルゴリズマー的な思考法がまだ身についていなかった方には、得るものもあったのではないでしょうか。 前回は、「幅優先探索」と「深さ優先探索」という、比較的単純なものを紹介しましたが

    トップクラスだけが知る「このアルゴリズムがすごい」――「探索」基礎最速マスター
  • 第76回 計算量の数学 計算量と実際のコード その2 | gihyo.jp

    物事はシンプルであればあるほど記憶しやすく、組み合わせて何事かを処理するのも容易になります。アルゴリズムもシンプルであればあるほど優れていると言えます。ただ、物事をシンプルにする、とひとことで言っても、いくつかの処理のステップをまとめて1つの名前を付けること、つまり、抽象化によってシンプルにした場合には注意が必要です。抽象化してシンプルになった名前の裏では、汗水たらしててんてこ舞いして働いている人がいるかもしれませんから。営業担当者が「簡単です!うちに任してください!」といって取ってきた仕事を、製造現場の労働者が泣きの涙で作って出荷している・・・という笑えない状況と、どこか似ているような似ていないような。いえ、決して営業さんは悪くないんですよ。悪くないんですけど。 図76.1 笑顔の営業、涙の現場 計算量:ハッシュサーチの場合O(1) バイナリサーチは十分高速な検索アルゴリズムです。これ以

    第76回 計算量の数学 計算量と実際のコード その2 | gihyo.jp
  • 第2回 検索アルゴリズムを分析してみよう! (1) 基本原理とYahoo!検索アップデート | gihyo.jp

    こんにちは。ディーボの藤沢です。この連載の偶数回目は、「⁠検索アルゴリズムを分析してみよう!」と題して、Yahoo!Googleの検索アルゴリズムについて、最新の検索アルゴリズムの動向や検索アルゴリズム分析ツール「ALGO Buster(アルゴバスター⁠)⁠」の紹介などを交えてお伝えしていきたいと思います。 Yahoo!Googleの検索結果の順位がどのように決まるのか、詳細は公表されていませんが、この順位決定ルールを検索アルゴリズムといいます。この順位決定ルールを完全に知ることはできないのですが、より深く、より正しく理解すれば、それだけSEO対策の精度も上がり上位表示の可能性が高まります。 検索アルゴリズムはYahoo!やGoogleによって改良が続いており、検索順位決定ルール自体もどんどん変化をしています。あるキーワードの検索結果で今日1位だったサイトが明日1位である保証はありませ

    第2回 検索アルゴリズムを分析してみよう! (1) 基本原理とYahoo!検索アップデート | gihyo.jp
  • 第7回 転置索引の構築 | gihyo.jp

    はじめに これまで、転置索引の構造や具体的なデータ構造を見てきました。今回は、検索したいテキスト文書から、どのようにこの構造を構築するかを説明していきます。 ディスクベースの構築方法 第3回では、表を作成しそれを転置させることで転置索引を構築しました。実際にコンピュータに処理をさせる場合も、メモリ上の2次元配列で同様に構築することが可能となります。しかし、通常の転置索引は非常に疎な表となるため、この方法ではメモリを使いすぎてしまいます。また、リンクリストなどのメモリ上でのデータ構造を用いることにより、上記の方法と比較して少ないメモリ量で構築することもできます。 これらの方法はいずれも、対象とする文書集合を変換した転置索引が実メモリに収まる場合にのみ可能となる方法となります。しかし多くの場合、転置索引は実メモリよりも大きくなります。そのような場合はディスクを用いた構築方法が必要となり、効率的

    第7回 転置索引の構築 | gihyo.jp
  • 経路探索アルゴリズムの「ダイクストラ法」と「A*」をビジュアライズしてみた - てっく煮ブログ

    as詳解 ActionScript 3.0アニメーション ―衝突判定・AI・3DからピクセルシェーダまでFlash上級テクニック を読んでいて、経路探索のアルゴリズムで A* が取り上げられていました。A* については、いろいろ検索して調べたりもしたのですが、やっぱりに書いてあると理解しやすいですね。せっかくなので自分流に実装してビジュアライズしてみました。ダイクストラ法まずは A* の特別なケースでもあるダイクストラ法から見ていきます。クリックすると探索のシミュレーションが開始します。スタート地点(S)からゴール(G)への探索が始まります。色がついたところが「最短経路が決定した場所」です。スタート地点から少しずつ探索が完了していきます。半分ぐらい完了しました。まだまだ進みます。最後まで終わりました。最短経路を黒色矢印で表示しています。ダイクストラ法は、スタート地点から近いノード(=マス

  • 第6回 日本語における転置索引 | gihyo.jp

    はじめに 前回までの数回では、転置索引の論理的構造や実装のための具体的なデータ構造について見てきました。今まで特に触れてきませんでしたが、これらの説明はすべて英語の文書を対象としたものでした。 英語は単語の間に空白を置くため、文を空白で区切ることで単語を抽出することができます。しかし、日語の文では各単語はつながっているため、日語で転置索引を構築する場合は英語と同じように、文を単語や文字の並びに分けてあげる必要があります。今回は、その方法について説明します。 文を単語や文字の並びに分割する方法 日語のように単語が空白で区切られていない文を単語に分割するには、大きく分けて以下の2つの方法があります[1]⁠。 形態素解析による分割 N-gram(q-gram)による分割 以下では、それぞれについて説明していきます。 形態素解析による分割 形態素解析(Morphological Analys

    第6回 日本語における転置索引 | gihyo.jp
  • 知れば天国、知らねば地獄――「探索」虎の巻

    いよいよ今回から、具体的なアルゴリズムの紹介に入っていきます。今回は、プログラミングにおける重要な概念である「探索」について考えます。グラフに変換し、探索する、という流れを知るとともに、そのグラフを効率よく探索する方法について紹介します。 今後紹介していくアルゴリズムについて お待たせしました! 「最強最速アルゴリズマー養成講座」という連載タイトルのとおり、今回の連載からいよいよ具体的なアルゴリズムの紹介に入っていきたいと思います。 しかし、それを読んでいただく前に、1つ注意してもらいたいことがあります。連載第3回でもお伝えしたように、「問題を、既存の適当なアルゴリズムに当てはめる」という考え方は、非常に危険である、ということです。 筆者の経験上、TopCoderでRedCoder以上を目指すのであれば、回答時間短縮のために、いままでのパターンを利用するのも方法の1つなのですが、連載では

    知れば天国、知らねば地獄――「探索」虎の巻
  • 第4回 平面走査法による線分の交差検出(中編) | gihyo.jp

    はじめに 今回は、平面走査法による線分交差検出のデータ構造を実装していきます。内容がかなり難しくなってきますが、説明とソースコードを納得できるまで読み返していただければと思います。 平面走査法と水平方向 前回は、多数の線分から交差を検出する方法として、平面走査法(plane sweep algorithm)の考え方を紹介しました。これは、x軸に平行な走査線を上から下へと動かしていき、走査線と交わる線分のみを計算対象とすることで、交差検出の計算量を減らすというものでした(図1⁠)⁠。 図1 平面走査法 実は、これだけでは考え方としてまだ不足なのです。図2を見てください。図2では図1と違い、すべての線分が同じくらいのy座標範囲にまとまって存在しています。こうした場合、走査線が多数の線分と交わる時間が大半を占めるため、計算量をほとんど削減できないことになってしまいます。 図2 走査線と多数の線分

    第4回 平面走査法による線分の交差検出(中編) | gihyo.jp
  • 第5回 転置索引の実装 | gihyo.jp

    はじめに 前回、前々回と転置索引の論理的構造について見てきました。今回は、転置索引の具体的なデータ構造や実装について説明していきます。 辞書の実装 辞書は通常、単語に対応した情報を高速に取得するために、ハッシュや木構造などのデータ構造を取ります。現在は, 安定した性能や単語の順序関係を利用したいなどの理由で、木構造のデータ構造が使われることが多いと思います。最も単純な場合、2分探索木(Binary Search Tree)や2分探索(Binary Search)の実装が考えられます。 2分探索(木)による辞書の実装 では、辞書の具体的なデータ構造について、図を交えて解説していきましょう。 前回も触れましたが、辞書には単語とその単語に対応するポスティングリストの位置情報のペア(のリスト)が格納されています。単語で検索をするので、ペア自体は単語をキーとして並び換えられます。 たとえば, 前回の

    第5回 転置索引の実装 | gihyo.jp
  • 第1回 直線の幾何 | gihyo.jp

    計算幾何学とは 小学生や中学生の頃、算数や数学の授業で、台形の面積を求めたり、直線の方程式を解いたりした記憶が誰にでもあることでしょう。計算幾何学とは、コンピュータサイエンスの立場から、こうした「図形」に関するアルゴリズムを研究する学問です。計算幾何学は、今日のコンピュータグラフィックスやCADの発展においてきわめて重要な役割を担っているほか、地理情報システム(GIS)やロボット工学といった数多くの分野に応用されています。 連載では、ブログ可視化サイトの「Blogopolis」で採用されている計算幾何的アプローチを引き合いに出しつつ、Javaプログラムでアルゴリズムを実装しながら、計算幾何学の初歩を学びます。 Blogopolisとボロノイ図 Blogopolisは筆者の開発したWebサイトで、主に日国内で開設された25万件以上のブログを解析し、「⁠仮想都市景観」として視覚化したサービ

    第1回 直線の幾何 | gihyo.jp
  • NYから東京まで何マイル?Google検索で都市間の直線距離を表示 | SEOモード

    Google+にて、Google検索で「how far is it from A to B」で検索するとAとBの都市間の直線距離を表示できるようになったとの投稿がありました。 実際にやってみたところ、こんな風に表示されました。 こちらは「NYと東京の距離」。 これまでも下図のように移動距離は表示していましたが、(私が調べた限りでは)交通手段があって、アクセス可能な場合に限られていたようです。 いずれにしても、この直線距離の表示はまだ日語環境では導入されておらず、英語環境でも「How far is it from London to New Delhi(ロンドンとニューデリーの距離)」では表示できなかったので、一先ずは限定的な提供のようですね。 ※こちらの記事は最初別のタイトルで公開されましたが、私の勘違いが含まれていたので、書き直して再投稿いたしました。 最初の記事を読まれた方にはご迷惑

    NYから東京まで何マイル?Google検索で都市間の直線距離を表示 | SEOモード
  • 第7回 性能改善の鍵、インデックスの特性を知る~B-treeとハッシュ (1)B-tree | gihyo.jp

    SQLアタマアカデミー 第7回性能改善の鍵、インデックスの特性を知る~B-treeとハッシュ (1)B-tree はじめに データベースを扱う仕事をしていると、パフォーマンスの問題に悩まされることは日常茶飯事です。とくに最近は、データベースに格納されるデータ量が飛躍的に増え、サーバのCPUやメモリといったハード面の増強だけでは追いつかないことも多くあります。 そのようなケースに対応するため、DBMSは性能改善のための手段を多く用意しています。その中で最もコストパフォーマンスの良い方法が、インデックス(索引)です。アプリケーションにもハード構成にも影響を与えずに実行でき、うまくいかなければすぐに削除できるという手軽さが大きな魅力で、効果はしばしば絶大です。 インデックスにはいろいろな種類があり、またDBMSによってもサポートする種類に差がありますが、稿では最も重要な2つを取り上げます。それ

    第7回 性能改善の鍵、インデックスの特性を知る~B-treeとハッシュ (1)B-tree | gihyo.jp
  • 細かすぎて伝わりにくいTopCoderのコーディングスキル向上マジック

    細かすぎて伝わりにくいTopCoderのコーディングスキル向上マジック:最強最速アルゴリズマー養成講座(1/3 ページ) 競技プログラミングはレベルの高い人たちの集まり――そんな考えを持っている初心者の方、TopCoderはあなたのコーディングスキルを爆発的に高める魔法のような場です。今回は、初心者にこそお勧めしたいTopCoderの魅力について考えます。 教育的な観点から見るTopCoder 今回からTopCoderに関する実践的アルゴリズムを解説していく予定でしたが、序盤のうちに触れておきたいことがありましたので、今回の枕は“教育的視点から見るTopCoder”というテーマで少し書こうかと思います。 まず、最初に宣言しておきたいことは、この連載は初心者向きである、ということです。「どう考えても上級者向けだろう」という意見はたくさんの方から寄せられていますが、筆者は、まだプログラミングレ

    細かすぎて伝わりにくいTopCoderのコーディングスキル向上マジック
  • 第6回 SQLで木構造を扱う~入れ子区間モデル (3)フラクタルとしての入れ子集合 | gihyo.jp

    フラクタルとしての入れ子集合 フラクタル 入れ子区間モデルでノードを挿入するときに重要な役割を果たす公式ⓐとⓑ(第6回 SQLで木構造を扱う~入れ子区間モデル(1)参照)は、区間(線分)を3分するための2点を与えるものです。そしてこれを繰り返し適用すると、同じ構造を持つ小さな入れ子集合を次々と作ることができます。 このような自己相似的な図形をフラクタルと呼びます。フランスの数学者マンデルブロが1977年に一般化した概念で、日でも一時期はやりました。海岸線や樹木の形など自然界にも多く存在する形状ですが、それだけでなく経済活動など人間社会にもこれに近似した現象が観察できることで知られています[4](⁠図8⁠)⁠。 図8 フラクタル図形の一種:シェルピンスキーのギャスケット ※ この図は、Wikipedia語版の「シェルピンスキーのギャスケット」に掲載されている図をベースにアレンジしていま

    第6回 SQLで木構造を扱う~入れ子区間モデル (3)フラクタルとしての入れ子集合 | gihyo.jp
  • 第6回 SQLで木構造を扱う~入れ子区間モデル (2)稠密性について | gihyo.jp

    稠密性(ちょうみつせい)について 前回から見えるように、整数から有理数へ範囲を広げることの利点は非常に大きいのですが、その理由は、有理数が整数にはない稠密性(ちょうみつせい:density)という性質を持っていることにあります。あまり日常で使う言葉ではありませんが、直感的に言えば物がぎっしり詰まっているということです。もう少し数学的に厳密に書くと、 x<yを満たす任意の数x、yについて、x<m<yとなる数mが存在する となります。平たく言えば、どんな2つの数の間(区間)にも、まだまだ無限に数がある、ということです。 ここでキーとなるのは「任意の」という言葉です。特定のx, yではなく、大小関係を満たすあらゆる数のペアについて成立することがキモです。たとえば、1と2の間には、0.5という数が存在します。今度は1と0.5の間で見ても、0.25というさらに中間の数が存在します。後は同じ手順で、1

    第6回 SQLで木構造を扱う~入れ子区間モデル (2)稠密性について | gihyo.jp
  • 第6回 SQLで木構造を扱う~入れ子区間モデル (1)もしも無限の資源があったなら | gihyo.jp

    はじめに 前回では、入れ子集合モデルという、リレーショナルデータベースで木構造を扱うための新しい方法論を紹介しました。このモデルは、RDBSQLと親和性の高い優れたものではあるのですが、挿入など更新時に、無関係のノードまで変更対象としなければならないのが大きな難点でした。 そこで今回は、上記の欠点を解消する進化版のモデルを紹介します。この方法を理解していく過程で、私たちはRDBと集合論の結び付きの深さを再確認することになります。 ふだんこの連載は、1回完結の読み切り形式なのですが、今回に限り、前号の内容を前提としています。未読の方は、前号を先に読むと理解が増すでしょう。 稼働環境 すべてのリレーショナルデータベース もしも無限の資源があったなら 座標に整数のみを使う場合の限界 入れ子集合モデルの大きな欠点は、ノードを挿入(追加)するときに、自分より「右側」にある無関係なノードをもっと右へ

    第6回 SQLで木構造を扱う~入れ子区間モデル (1)もしも無限の資源があったなら | gihyo.jp
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
    flakwing
    flakwing 2009/10/18
    協調フィルタリング, Map-Reduce, 分散型単純ベイズ分類器と補完型単純ベイズ分類器, 進化的プログラミングのための分散型適応度関数機能, 行列ライブラリーとベクトル・ライブラリー
  • アルゴリズムの紹介

    ここでは、プログラムなどでよく使用されるアルゴリズムについて紹介したいと思います。 元々は、自分の頭の中を整理することを目的にこのコーナーを開設してみたのですが、最近は継続させることを目的に新しいネタを探すようになってきました。まだまだ面白いテーマがいろいろと残っているので、気力の続く限りは更新していきたいと思います。 今までに紹介したテーマに関しても、新しい内容や変更したい箇所などがたくさんあるため、新規テーマと同時進行で修正作業も行なっています。 アルゴリズムのコーナーで紹介してきたサンプル・プログラムをいくつか公開しています。「ライン・ルーチン」「円弧描画」「ペイント・ルーチン」「グラフィック・パターンの処理」「多角形の塗りつぶし」を一つにまとめた GraphicLibrary と、「確率・統計」より「一般化線形モデル」までを一つにまとめた Statistics を現在は用意していま

  • 「1000のアルゴリズムを持つ男」vs.「やわらか頭脳」

    「1000のアルゴリズムを持つ男」vs.「やわらか頭脳」:最強最速アルゴリズマー養成講座(1/3 ページ) 典型的なアルゴリズムをたくさん知っている人間が最強か――? いいえ、典型的なアルゴリズムを知らなくても、違ったアプローチで答えに迫る方法はいくらでも存在します。短い実行時間で正確な答えを導き出せるかを考える習慣をつけましょう。 アルゴリズマー養成講座と銘打ってスタートした連載。もしかすると読者の方の興味は、はやりのアルゴリズムや汎用的なアルゴリズムを知ることにあるのかもしれません。しかし、今回は、いわゆる「典型的なアルゴリズム」を用いずに進めていきたいと思います。 なぜ典型的なアルゴリズムを用いないのか。それは、典型的なアルゴリズムばかりを先に覚え、それだけでTopCoderなどを戦っていこうとした場合、それに少しでもそぐわない問題が出た場合に、まったく太刀打ちできなくなってしまう

    「1000のアルゴリズムを持つ男」vs.「やわらか頭脳」
  • 類似画像検索システムを作ろう - 人工知能に関する断創録

    C++版のOpenCVを使ってカラーヒストグラムを用いた類似画像検索を実験してみました。バッチ処理などのスクリプトはPythonを使ってますが、PerlでもRubyでも似たような感じでできます。 指定した画像と類似した画像を検索するシステムは類似画像検索システムと言います。GoogleYahoo!のイメージ検索は、クエリにキーワードを入れてキーワードに関連した画像を検索しますが、類似画像検索ではクエリに画像を与えるのが特徴的です。この分野は、Content-Based Image Retrieval (CBIR)と呼ばれており、最新のサーベイ論文(Datta,2008)を読むと1990年代前半とけっこう昔から研究されてます。 最新の手法では、色、形状、テクスチャ、特徴点などさまざまな特徴量を用いて類似度を判定するそうですが、今回は、もっとも簡単な「色」を用いた類似画像検索を実験してみます

    類似画像検索システムを作ろう - 人工知能に関する断創録