タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

algorithmとAlgorithmと勉強に関するpaellaのブックマーク (14)

  • 過去10年間のComputer Science系論文で被引用数トップ10を作ってみた - 情報科学屋さんを目指す人のメモ(FC2ブログ版)

    何かのやり方や、問題の解決方法をどんどんメモするブログ。そんな大学院生の活動「キャッシュ」に誰かがヒットしてくれることを祈って。 2000年以降の論文に限定して、 CS系論文の被引用数ランキングを作って分析してみた。 この作業を通じて予想以上に得るものがあった。 ランキングの作り方 CiteSeerXが公開している「Most Cited Computer Science Articles (2010/9/14)」を元データに採用した。 ここから2000年以降の文章に限定した後、ハンドブックや雑誌記事などを取り除いて論文だけのランキングを作成した。 被引用数は時間が経つほど増える一方なので、2000年・2001年あたりの論文が有利であることに注意する必要がある。 ただし、このことがかえって得るものを増やしてくれた。 アブストラクトをチェック 良い機会であるので、 各論文の概要や結論をチェック

  • A*アルゴリズムについて整理 - yasuhisa's blog

    辞書を参考にしながら。NAISTのI期辺りでやったはずなんだが、かなりすっ飛んでいる。 デジタル人工知能学事典 [CD-ROM付] 作者: 人工知能学会出版社/メーカー: 共立出版発売日: 2008/05/16メディア: 単行購入: 1人 クリック: 6回この商品を含むブログ (6件) を見る A*アルゴリズムとは?グラフ探索アルゴリズムの一つ。「開始ノードから現在位置に至るまでのコスト」と「現在位置からゴールまでの推定コスト」の2つのコストを用いてadmissibleな条件(後述)の元でコストが最小であるような経路を効率的に見つけることができるアルゴリズムである。1960年代に開発されたアルゴリズムであるが、50年経った今でもばしばし使われている。 現在いるノードをp、開始ノードからpまでの最小コストをg(p)、pからゴールまでの最小コストをh(p)と書くとすればpを経由して開始ノード

    A*アルゴリズムについて整理 - yasuhisa's blog
    paella
    paella 2011/03/23
    あとで読む。c++のソースサンプルあり。
  • インテル・AMDのCPUアーキテクトが明かす: GNU grep が速い理由 - karasuyamatenguの日記

    GNU grepの元祖作者がFreeBSDハッカーをschoolしている。 http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html FreeBSD対GNU grepのパフォーマンスを議論していると思われるとことに「俺はgrepの初代作者だ」と名乗って現われた男がいる。 履歴書(http://duckytech.com/resume.pdf)を見ると、GNU coreutilsに貢献した後、インテルやAMDCPUアーキテクトを勤めている男だ。これは話を聞いた方がよさそうだ。 FreeBSDユーザでもある彼はリストを観閲していたらたまたまGNU対BSDのgrep論争に当ってしまったようだ。BSDのリストにGNU grepの秘密を解く。 技1: 全ての入力バイトを見ないから速い 技2: 見るバイトに関

    インテル・AMDのCPUアーキテクトが明かす: GNU grep が速い理由 - karasuyamatenguの日記
    paella
    paella 2010/11/19
    サーチを速くして、IOを速くするのに何をしているか、という話。面白い。BM法で出来るだけバイトを見ないで、コピーを避けて、アラインメントを調整して。¥nを見るのは最後の方というのも興味深い内容。
  • 開発メモ: トップNソートの検討

    上位N件をソートした状態で取り出すという、いわゆる「トップNソート」の効率的な実装について検討してみた。 背景 データベースに対して、ある順序でソートした時の最初の何件かが欲しいというクエリを投げることはよくあるだろう。SNSで言えば、誰かのコンテンツの最新10件を表示するとかいう場合だ。SQLだと "ORDER BY xxx LIMIT yyy" とかいう感じ。同じような操作は全文検索システムのスコアリングでも定番である。俺もよく自分で実装するわけだが、その度に適当な試行錯誤をして時間がもったいないので、今回は入念に調べて決定版を出そうじゃないか。 全体をソートして上位を取り出せば目的は満たせるのだが、それだと無駄な計算が多い。100万件の中から上位10件だけ欲しい場合に、残りの99万9990件まで律儀にソートする必要はない。ということで、上位N件をソートして取り出すという「トップNソー

    paella
    paella 2010/11/01
    データからトップNを出す場合の効率的なソートアルゴリズムについて。これはよく読もう。
  • 【レポート】GNU grepが高速な理由 | エンタープライズ | マイコミジャーナル

    FreeBSD - The Power To Serve why GNU grep is fast (なぜGNU grepは高速なのか)といったタイトルの興味深いメールがFreeBSD開発者メーリングリストに投函された。メールを出したのはGNU grepのオリジナル開発者であるMike Haertel氏。Mike Haertel氏はFreeBSDユーザでもあり、FreeBSD開発者メーリングリストで興味深いやりとりがあったため、このメールを流したとしている。Mike Haertel氏の紹介する内容はgrep(1)の実装のみならず、高速な文字列処理を実現するひとつの方法として参考になる。紹介されているGNU grep高速さの秘訣は次のとおり。 GNU grepは入力バイトのすべてをチェックするようなことは避けている。 GNU grepはバイトごとに適用する操作を極力最小限に減らしている。 G

    paella
    paella 2010/08/26
    GNU grepが高速である理由の概要説明。マルチバイト文字でもこの方法が速いのかどうかは、ここだけでは分からなかったけどメモ
  • d.y.d. 2倍だけじゃない

    10:01 10/07/20 それでも2倍だ 先日のvectorの伸長度合いの記事に関して 当に1.5倍のほうがメモリ効率がよいのか という反応をいただきました。とても興味深い。みんな読みましょう。 自分の理解メモ: 「再利用ができるから嬉しい」等の議論をするなら、 今までに確保したメモリ (1 + r^1 + ... + r^k) のうち、 有効に使えてるメモリ r^{k-1} (バッファ拡大直後) や r^k (次のバッファ拡大直前) の割合で評価してみようじゃないかという。 まず簡単のために再利用をしない場合を考えると、この割合はそれぞれ (r-1)/r^2、 (r-1)/r になります(途中計算略)。 この利用率が最悪になる瞬間 (r-1)/r^2 を最善にしよう、 という一つの指標で考えてみると、式を微分なりなんなりしてみると r = 2 で最大(25%)となることがわかります

    paella
    paella 2010/07/07
    動的メモリ確保が、最初のサイズのn倍で増加していく事への検証記事。各言語の増加割合や、黄金比よりも小さい増分でのメリット(要注目!)など、面白い情報が分かりやすい説明で。
  • ギャップ・バッファ

    説明 ギャップ・バッファは,テキスト・エディタなどで用いられる,シーケンスを扱うデータ構造です. ここで公開するプログラムはK. Inaba氏の制作されたエディタ,GreenPadにおいて使われているギャップ・バッファをC++言語に含まれるSTLのvectorを使うように改造したものです. また,それをC言語のみで書き直したものも公開しています. 両方ともNYSL(ライセンス)とします. ダウンロード C++言語版: (2003年3月26日) gapbuffer.h C言語版: (2008年9月19日)- 仮の実装なのでバグがあるかもしれません. gbuf.h gbuf.c 解説 ギャップ・バッファはテキスト・エディタのテキスト・バッファなど,長く連なるデータを保持する際に用いられるシーケンス・コンテナです. 局所的な要素の挿入,削除を頻繁にする場合に適したデータ構造です. 双方向リスト(

    paella
    paella 2010/05/26
    ギャップ・バッファなる、過去のEmacsでも使われていた長く連なるデータを保持するために用いられるシーケンス・コンテナ。局所的な要素編集が多いときに適したデータとのこと
  • QuickDrawはどのように素早く円を描いていたのか? - ザリガニが見ていた...。

    かつてのMac OS9までの描画エンジンの主役はQuickDrawが担っていた。GUIなOSでは、文字も含めてすべてをグラフィックとして扱うので、画面に見えているすべてのもの*1はQuickDrawによって描かれていたことになる。描画エンジンは、GUIなOS開発の要となる技術である。その出来が、GUIなOS開発の成否を分けるとも言える。 そして、最初期のQuickDrawは、ビル・アトキンソンがたった一人で開発したそうである。 当時(25年以上前)のCPUは、動作クロックが8MHzという性能だった。(現在は2GHz=2000MHzかつ、複数コアが当たり前) そのような性能であっても、違和感なくマウスで操作できるOS環境にするために、斬新な発想や試行錯誤を重ね、相当な努力の末に開発されたのがLisaやMacintoshであった。 Amazon.co.jp: レボリューション・イン・ザ・バレー

    QuickDrawはどのように素早く円を描いていたのか? - ザリガニが見ていた...。
    paella
    paella 2010/03/20
    QuickDrawで高速なRoundRectをどのように実現していたか、トライ&エラーで高速化を考えていっている記事。非常にエキサイティングな内容。
  • ボロノイ図 - Wikipedia

    この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "ボロノイ図" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2011年10月) ボロノイ図の一例 個々の色分けが一つの領域を表す ボロノイ図(ボロノイず、英: Voronoi diagram)は、ある距離空間上の任意の位置に配置された複数個の母点(英: site、サイト)に対して、同一距離空間上の他の点がどの母点に近いかによって領域分けされた図のことである。特に二次元ユークリッド平面の場合、領域の境界線は、各々の母点の二等分線の一部になる。母点の位置のみによって分割パターンが決定されるため、母点に規則性を持たせれば美しい図形を生み出す

    ボロノイ図 - Wikipedia
    paella
    paella 2010/03/16
    Wikipediaのボロノイ図に関する説明。二次元画像においては関連項目の離散ボロノイ図にあるように、一番近い母点に所属させれば良い。ふむふむ。
  • 動的計画法とナップサック問題を学びたい人におすすめのサイト - ダウンロードたけし(寅年)の日記

    組み合わせ最適化の手法として「動的計画法」というモノがあります。 wikipediaから抜粋 動的計画法(どうてきけいかくほう、英: Dynamic Programming, DP) コンピュータ科学の分野において、ある最適化問題を複数の部分問題に分割して解く際に、そこまでに求められている以上の最適解が求められないような部分問題を切り捨てながら解いていく手法 一見難しそうですが、実は理解するのは以外と簡単です。いろいろな場面で応用が利く便利な手法ですので、覚えておいて損はないものです。コンピュータ系、情報系のお勉強をする人であれば、おそらく一度は習ったりするかもしれません。 ナップサック問題と動的計画法 動的計画法の一番親しみやすそうな例として「ナップサック問題」というのがよく取り上げられます。 こんな感じの問題です。 今ここに様々な大きさの品物が置いてあるとします。そしてそれらの品物は各

    動的計画法とナップサック問題を学びたい人におすすめのサイト - ダウンロードたけし(寅年)の日記
    paella
    paella 2010/03/02
    面白い説明と、導入も含めたその先へのリンク。良い記事。
  • Quicksilverは如何にして鋭い検索を行っているのか? - ザリガニが見ていた...。

    Quicksilverの検索性能が、感性をくすぐってきた。 「apple」→「AppleScript Editor」 「ase」→「AppleScript Editor」 「prol」→「Property List Editor」 「im」と入力して、「Image Capture」を起動したいが、「iMove」がトップヒットになってしまう...。 そんな状況でも、候補リストから2回連続で「Image Capture」を選択すれば、3回目以降は「Image Capture」がトップヒットになる。 直近のユーザーの好みを学習してくれるのだ。 もちろん、「ima」まで入力すれば「Image Capture」がトップヒットになる。 「ase」「prol」のような、単純な前方一致でも、部分一致でもない検索には恐れ入る。しかも、シンプルだけど学習もしてくれる。使うほどに手に馴染んでくる仕組みは、この辺

    Quicksilverは如何にして鋭い検索を行っているのか? - ザリガニが見ていた...。
    paella
    paella 2010/03/02
    鋭い検証記事。面白い。
  • パラメトロン計算機

    久野君たちの努力により, Beautiful Codeの翻訳がでた. 以前 三省堂の洋書の棚にあるのを見たことはあったが, その時はパスした. 翻訳をみると, なにしろ多くの人がそれぞれのプログラム言語で書いた自分のプログラムを(それもかなり大きい部分を)自讚しているから, 読むのが大変そうである. 短くて面白かったのは, 33章「『』のためにプログラムを書く」であった. 要するに平面上の3点A, B, Cの座標が与えられた時, その3点が同一直線上にあるかを判定するプログラムを書くのだ. 私がやっても多分こういうアプローチになるであろうという風に話は展開していく. まずA,Bの2点を通る直線の式を決め, 点Cがそれに乗っているかを問うもの. これは最初の2点がy軸と平行な線上にあるときの始末が面倒. 次はABを通る直線の勾配と, ACを通る直線の勾配を計算し, それらが一致するかを見る

    paella
    paella 2010/01/09
    面上の3点A, B, Cの座標が与えられた時, その3点が同一直線上にあるかを判定するには、その行列式((Ax*By+Bx*Cy+Cx*Ay)-(Ax*Cy+Bx*Ay+Cx*By))が0になれば良い、という話。3点の面積が0になれば良いという理屈。なるほど。
  • HashMapの大きさ

    Javaのソースコードをレビューしていると、HashMapを作成して、キーと値の組を数個しか入れていないものを見かけたりしています。実際、マッピングとして、3個のキーと値の組しか入れていなくて、そのようなHashMapを3個作成しているコードがありました。 そこで、HashMapのオブジェクトの大きさを調べてみました。HashMapを作成すると、そのインスタンスには、以下のインスタンスフィールドが含まれます。 (配列)参照型 1個、int型 3個、float型 1個 これだけで、5個×4バイト=20バイトです。参照型は、ネストしたクラスであるEntry型の配列となっており、最初にデフォルトでは大きさ16の配列が生成されています。つまり、16×4バイト=64バイトの大きさの配列です。したがって、デフォルトのままでHashMapを生成すると、84バイトは最低限消費します。 そこに、3個のキーと

    HashMapの大きさ
    paella
    paella 2009/10/01
    効率を考えたときに何を重要視するか。データ数が少ないところでハッシュを使っても意味がない。
  • iPhone and iPad Particle Designer With Cocos2D Support | iPhone and iPad SDK Development Tutorials and Programming Tips

    สล็อตเว็บตรง เว็บใหญ่ API แท้ รับทรูวอเลท สล็อต แตกหนักทุกเกม100% เว็บสล็อตชั้นนำ สล็อตเว็บตรง เว็บใหญ่ API แท้ รองรับทรูวอเลท ใช้งานง่าย ฝากถอนไม่มีขั้นต่ำ สล็อตแตกหนักทุกเกม เล่นได้ทุกค่าย เว็บตรง 100%

    iPhone and iPad Particle Designer With Cocos2D Support | iPhone and iPad SDK Development Tutorials and Programming Tips
    paella
    paella 2009/09/08
    UIの素材集のまとめ。いいリンク先ばかりだったのでブックマーク。
  • 1