Slide 1 of 37
2015年12月17日、Google Chrome の JavaScript エンジン(処理系)である V8 の公式ブログにて、 JavaScript の標準的な乱数生成APIである Math.random() の背後で使われているアルゴリズムの変更がアナウンスされました。 Math.random() 関数は JavaScript を利用する際には比較的よく使われる関数ですので、親しみのある方も多いのではないかと思います。 新たなバグの発見や、従来より優秀なアルゴリズムの発見によってアルゴリズムが変更されること自体はそれほど珍しくはないものの、 技術的には枯れていると思われる Math.random() のような基本的な処理の背後のアルゴリズムが変更されたことに驚きを感じる方も少なくないかと思いますが、 それ以上に注目すべきはその変更後のアルゴリズムです。 実際に採用されたアルゴリズムの原
Wikipediaを漁っていたところScalable Bloom Filters(SBF)というデータ構造を発見してしまったので紹介します1。 参照した論文 http://haslab.uminho.pt/cbm/publications/scalable-bloom-filters SBFの説明に入る前に、Bloom Filterについて簡単に紹介します。もっとも、日本語のWikipediaでも十分詳しい説明が載っていたりするのですが……。 ささっと説明 Bloom Filterはちょっと不思議な性質を持つデータ構造の一種です2。 いわゆるSetと同じ操作を提供する 要素を入れる操作と、ある要素が入っているかを調べる操作 どちらも時間計算量O(1)で実現できる ハッシュテーブルなどを用いて実装される同種のデータ型と比して、とても空間効率が良い その代わりに、ある要素が入っているかの判定を
オバマ大統領の再選に大きく寄与したことで大きな注目を集めているA/Bテスト。A/Bテストを導入した、することを検討している、という開発現場も多いのではないだろうか。 そんな中、Web上で次のような議論を見つけた。 20 lines of code that will beat A/B testing every time Why multi-armed bandit algorithm is not “better” than A/B testing 一言でまとめると「A/Bテストよりバンディットアルゴリズムの方がすごいよ」「いやいやA/Bテストの方がすごいし」ということだ。 で、バンディットアルゴリズムとは一体何者なのか? そこでBandit Algorithms for Website Optimization (O'REILLY)を読んでみた。その結果分かったことを踏まえてざっくりと
by Neil Fraser, April 2006 Computing the differences between two sequences is at the core of many applications. Below is a simple example of the difference between two texts: Text 1: Apples are a fruit. Text 2: Bananas are also fruit. Diff: AppleBananas are also fruit. This paper surveys the literature on difference algorithms, compares them, and describes several techniques for improving the us
The latest news from Google on open source releases, major projects, events, and student outreach programs. At Google, we think that internet users’ time is valuable, and that they shouldn’t have to wait long for a web page to load. Because fast is better than slow, two years ago we published the Zopfli compression algorithm. This received such positive feedback in the industry that it has been in
のような感じにエンコードされることが分かります。 自分の好きなデータで試すことができて便利!という話でした。 PS. 以下は実行結果です。 % make % gzip < alice.txt > alice.txt.gz % ./puff -10 alice.txt.gz puff() succeeded uncompressing 1328 bytes 8 compressed bytes unused inpos=406,inbits=224,outpos=0,outbytes=45 41 6c 69 63 65 20 77 61 73 20 62 65 67 69 6e 6e 69 6e 67 20 74 6f 20 67 65 74 20 76 65 72 79 20 74 69 72 65 64 20 6f 66 20 73 69 74 74 A l i c e w a s b
I think the diff algo used for pack files was linked to one of the delta encoding out there: initially (2005) xdelta, and then libXDiff. But then, as detailed below, it shifted to a custom implementation. Anyway, as mentioned here: Git does deltification only in packfiles. But when you push via SSH git would generate a pack file with commits the other side doesn't have, and those packs are thin pa
The latest news from Google on open source releases, major projects, events, and student outreach programs. The Zopfli Compression Algorithm is a new, open sourced general purpose data compression library that got its name from a Swiss bread recipe. It is an implementation of the Deflate compression algorithm that creates a smaller output size compared to previous techniques. The smaller compresse
高速文字列解析の世界というタイトルからは、どんな中身なのかあまり伝わってこないので、どんなことが書いてある本なのか、中身をちょっと紹介してみる。 1章、2章は概観や準備であり、3章からが本番なのだが、Burrows Wheeler Transform、簡潔データ構造、ウェーブレットツリー、データ圧縮、全文検索、テキストマイニングのためのデータ構造、という章題になっている。 何に使うのかという目的ベースで考えると、この本に載っているのは、データ圧縮、情報検索とテキストマイニングの基盤技術である(データ圧縮については基盤と言うよりはそのものだが)。ただ、この本には本当に基盤技術の話しか載っていないので、「この本で情報検索はバッチリだぜ!!」というような訳にはいかない。テキストマイニングに関しても同様である。別途入門書を読むなりしないと、より高次元(ここでの高低は技術の積み重ねの高低であり、難し
このテーブルの番号は 1 Byte になっているため、0-255 の 256 個しか登録できません。そのため、画像で使用されている色が 256 個より多い場合は、なんとかして 256 個にしなくてはいけません。 この「なんとかして 256 色にする」というのが減色処理で、なるべく元の画像からの変化を分からないようにしながら色を減らしていくためのアルゴリズム実装です。(この記事では減色アルゴリズムについての説明は省略します。) テーブルを作成したら、画像のそれぞれのピクセルを RGB 形式からテーブルの何番目の色を使うかに置き換えます。 上図のように、1 ピクセルあたり 24bit 必要だった画像が 1 ピクセルあたり 8bit になったので、データサイズは大体 1/3 になります。 (パレットのデータに最大 3 Byte * 256 = 768 Byte 必要とか、同じように圧縮されないと
Open Data Structures covers the implementation and analysis of data structures for sequences (lists), queues, priority queues, unordered dictionaries, ordered dictionaries, and graphs. Data structures presented in the book include stacks, queues, deques, and lists implemented as arrays and linked-lists; space-efficient implementations of lists; skip lists; hash tables and hash codes; binary search
プログラミングの腕試しの機会として注目を集める競技プログラミング。基礎的なものから上級問題までプログラミングコンテストTopCoderを攻略するノウハウを楽しみながら理解する。初心者でも大丈夫。簡単な問題から積み上げて、TopCoderの上位をめざそう! ■目次: 準備編 第1章 プログラミングコンテストって? 第2章 TopCoderに参加しよう 第3章 最低限必要な知識をつけよう! 初級編 第4章 シミュレーション 第5章 全探索 中級編 第6章 計算量 第7章 動的計画法・メモ化 第8章 探索範囲を狭めるアルゴリズム 上級編 第9章 応用問題 第10章 グラフ問題対策 第11章 数学問題対策
Cute Algorithms! 稲葉 一浩 at #spro12 SLOWEST SORT まずは準備運動です! Thanks to: @y_benjo @rng_58 @hos_lyric @oxy @xhl_kogitsune @args1234 アルゴリズムと言えば! ソート! Radix Sort Merge Sort Bubble Sort Heap Sort Insertion Sort Quick Sort Shell Sort ソートと言えば! Radix Sort Merge Sort Bubble Sort Heap Sort Insertion Sort Quick Sort Shell Sort O(n log n) ! では、逆に・・・ ソートの「遅さの限界」は? 一番たくさん大小比較を実行するソート法は? 最遅ソート!? 「最も遅い」ソート法は? • よくある
2012/6/21のPFI全体セミナー, 「文字列データ圧縮ことはじめ」の内容です。データ圧縮の話とそれに纏わる歴史と最近の話を紹介しています。
This is the common project page for: LuaJIT — a Just-In-Time Compiler for Lua. Coco — a Lua extension for True C Coroutines. DynASM — a Dynamic Assembler for code generation engines. Lua Bitop — a Lua extension for bitwise operations on numbers. Privacy Policy This website does not request, store or process any private data. This website is fully static and does not allow entry of personal informa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く