Geohashのアルゴリズム
Photo by Ludovico Cera 前回、最後にGeohashのエンコード・デコード方法を解説、とか書いたのですが、私が書く前にyuroyoroさんがブログで解説していました。しっかり解説されているので、ぜひ、そちらをご覧ください。 Geohashのミソは、座標を2進数にして、それを交互に並べる所にあります。そしてそれをBASE32でエンコードすることで、座標を文字列にして表現しています。 BASE32は、5ビットで1文字なので、Geohashの長さが奇数の場合は、経度の方がビットが短くなります。 (例: 5文字の場合 全25ビット 緯度が13ビット、経度が12ビット) そのため、グリッドの大きさが、Geohashが奇数の場合は縦長、偶数の場合は横長になります。 ビット列から文字列へのエンコード方法に、BASE32を使っているのは大文字小文字を区別しないためだと思いますが、これを
Alcor の Abbreviation Scoring - steps to phantasien(2009-09-12)
同僚の生産性ツール愛好家が熱に浮かされて言った. "QuickSilver の検索がすごいんだよ!" どう凄いのかというと, たとえば "Skype を検索するのに <sp> でいい!" らしい. それは凄いのかも. 私もいちおう QuickSilver を使っているけれど, 素敵機能の類はまったく活用していない. だいたい私の使うアプリケーションはどれも一文字で特定できる. Firefox, Emacs, iTerm, Activity Monitor... そういえば iTunes は iTerm と被ってる. ためしに <iu> と打ってみたら iTunes にマッチする. なんとなく凄い気がしてきた. 同僚はこのアルゴリズムが気になるらしい. 編集距離の仲間かとも思ったけれど, 違う気がする. とりあえずぐぐってみたところ, QuickSilver は 2007 年に オープンソー
B木の Copy-Modify 方式での実験的コード - Tociyuki::Diary
id:naoya さんの Python 版B木に触発されて、Ruby 版の insert・delete だけを実装した B 木を書いてみました。 実装にあたり、標準的な教科書に良く掲載されている Overwrite 方式ではなく、現代的な Copy-Modify 方式、すなわち B 木の葉から根に向かって更新のおこなわれるノードを複製してから修正をおこなっていき、最後に根をすげ替える方式に挑戦してみました。こうすることにより、更新の途中でなんらかの例外が発生したとしても、直前の B 木を壊さずにすみ、安全にロール・バックすることができるようになります。また、更新の途中の元の B 木はいっさいがっさい元のままですから、根を変更バージョンごとに持つようにすれば、現代的なデータ・ベース・マネジメント・システムに採用されている Multi-Version Concurrency Control(M
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
