きまぐれ日記: MeCabがiPhone,OSXに載っていると言うのは止めようと思う
iPhoneのSDKの条項に変更が加わり、Flashのクロスコンパイルを含む 純正開発ツール以外で作成されたバイナリの配布が禁止となるようです。 世間でも散々言われていますが、この変更は正直とても残念です。 Apple的には「製品のクオリティーが保てないから」という理由だそうですが、 Windows版iTunesが意味もなくQuickTime入れたり、Windows非標準のUIを 使いまくっていて、お世辞にもクオリティーが高いとは言えないのを棚にあげて、 クオリティー云々と言い訳できるのでしょうか。アプリなんて所詮 玉石混淆。決めるのはユーザです。 MeCabは以前GPL/LGPLでした。Appleを含む複数の方からこのライセンスでは 使いにくいと言う指摘をうけ、前職の同僚と協議をしながらBSD/LGPL/GPL のトリプルライセンスにしたという経緯があります。結果としてこの変更は うまく
きまぐれ日記: sudo のGUIダイアログはセキュリティ的に大丈夫なのか?
UbuntuやMac OSXを使っていると、権限の高いオペレーションを実行しようとしたときに、ユーザのパスワードを要求するダイアログが起動します。毎回ハイハイと思いつつ入力しているのですが、ふと考えるとこのセキュリティモデルというかユーザビリティー的に大丈夫なのかどうかと思うようになりました。 例えば、インストーラーでダミーのパスワードダイアログを表示させればマルウェア作者はユーザのパスワードを取り放題だし、OSのファイル保存ダイアログをクラックして、適当なファイル保存のタイミングで同ダイアログを出せば、無知なユーザはホイホイパスワードを入力してしまうのではないでしょうか。Webサイトのフィッシングと全く同じ話です。 このダイアログはそもそも CUIプログラム sudo のラッパーにすぎません。しかし、話はそんなに単純ではありません。CUIの場合は、ほとんどの操作が「能動的」なために、su
きまぐれ日記: 「ハードウェア」プログラマと「ソフトウェア」プログラマ
プログラマ・ソフトウェアエンジニアと呼ばれる人間には、 2つのタイプがあるような気がしています。 ひとつは、もともと機械いじりやハードウェアが好きな 「ハードウェア」プログラマ、もう一つはその反対の「ソフトウェア」プログラマ。 それぞれどういう特徴があるか、独断と偏見でまとめてみました。 (私自身ハード出身なのでそちらに偏重していますw ) 「ハードウェア」プログラマ 「最適化」という言葉が好き 外的な制約(メモリ/速度/ディスク)がある方が燃えるし、真の能力を発揮できる 逆に制約がないと何していいのかわからず、平凡なアイデアしか思いつけない 開発言語は、制約から決定する O(n) の計算量でも、その定数項を気にする 専用ハード好き (地球シミュレータ, メーンフレーム) 定量評価ができないような仕事は興味ない 固定長データ バイナリデータ 再帰なんてもってのほか スピード狂 CPUがどれ
きまぐれ日記: ファンに支えられるプロダクトとユーザにdisられるプロダクト
世の中には熱狂的なファンに支えられるサービスやプロダクトがあります。 Appleファン、Googleファン、日産ファンといえばピンときますが、 Microsoftファン、Yahooファン、トヨタファンと言うとあまり聞きません。 ファンに支えられることは素晴らしいことですが、ファンが多いからといって プロダクトの完成度やクオリティが高いとは限りません。私がファンになるのは アイドルぐらいで、ソフトウェアに関してこれとってファンはないのですが (いやむしろありとあらゆるプロダクトを触ってみては〇〇はウンコと言っていますが...) 某製品の改善点をそのファンに伝えると「愛が足りない」とか 「そんな所誰が気にするのか」とかわされます。 あるプロダクトのファンになるかどうかは、中の人がどれだけカリスマ性があるかとか、 彼らの長期的なビジョンや理念がどれだけ魅力的かと言ったハイレベルなところで 決まり
きまぐれ日記: 「読めてしまう」コピペがなぜ読めてしまうのか
http://www.asks.jp/users/hiro/59059.html http://www.itmedia.co.jp/news/articles/0905/08/news021.html 最初読んだとき、違和感なく読めてしまったのですが、よくよく見てみると、そんなトリックがあったのですね。 さて、この「読めてしまう」がなぜよめてしまうのでしょうか？ 人間の言語モデルの単語パープレキシティは、約100ぐらいであると言われています。どういうことかというと、 人間が文章を読んでいるときに、次の単語を過去の文章から推測するのは 1/100 程度の 確率で正解するということです。 件のコピペですが、最初の文字は変わらないので、その正解率は平仮名の数(52)倍になります。 すなわち、52/100 =~ 0.5 実際には、最後の文字も変わらないし、 単語の長さが変わらないというもの、大きな
きまぐれ日記: ファイルIOではなくバイト列IO
組込用のIMEを作っている方とお話したことあるのですが、組込用のIMEは ポータビリティを高めるために、いわゆるファイルIOは使っておらず システムからimmutableメモリ領域(システム辞書など)とmutableメモリ領域(ユーザ辞書など) をわたしてもらって使うような仕様になっているそうです。 ファイルIOはポータビリティを考えるといろいろ面倒なことがあるのでなるほどな思いました。 実はこういうバイト列を辞書のシリアライズ先として使うことはプリミティブですが身軽です。 自然言語処理のシステムでは静的な辞書や機械学習結果のモデルをロードすることが多々あります。 自分が何かを作るときは、辞書や学習モデルをバイナリのバイト列として格納し、メモリイメージとして読み込むような設計にしています。 例えば、Dictionary というクラスがあったときには、ファイルから辞書を読み込むような インタ
きまぐれ日記: pubic static はコンピュータに伝える約束事ではない
http://www.atmarkit.co.jp/news/200904/10/matz.html PerlやRuby、Pythonといったスクリプト言語では、 記述が非常にストレートで端的になる。JavaやC++といった言語では、 「public static void mainなど、コンピュータに伝える約束事が多くて、 やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」（まつもと氏）。 これは書くときだけでなく、読むときにも同様だ。 まつもと氏の記事を読んで、仕事として大規模な共同開発の経験に基づいているのかなと思いました。 publicとかstaticとかconstというのは書く側からすると約束事で めんどいということには同意しますが、毎日のようにコードレビューを している経験からいうと、コードレビューをする側にとってこいうキーワードがあるかないかで全く意味が異なります。メ
きまぐれ日記: 手書き文字認識エンジン Zinnia on iPhone
手書き文字認識エンジンZinniaを先日公開しました。全くデモがなくていまいちどういうライブラリか分かりにくかったのですが、Youtube 上に Zinnia を iPhone 上で動作させたというデモ動画を見つけました。すばらしい。 http://www.youtube.com/watch?v=i88uaIu3Khk ほかにもいくつかフィードバック等を見つけました。 Mathieu Blondel さんは、zinnia と tomoe, そして自身が開発なさっている hmm ベースの手書き文字認識エンジンを客観的に比較なさっています。 私自身こういう比較を 行なったことなかったのですが、tomoe に比べて、速度面でも精度面でもsignificantに上回っているようです。特に速度は 10倍ぐらいtomoenに比べて高速なようです。 他にも、tomoe本体の認識エンジンに zinniaを
きまぐれ日記: Zinnia: 機械学習ベースのポータブルなオンライン手書き文字認識エンジン
オンライン手書き文字認識エンジンZinniaを公開しました。 http://zinnia.sourceforge.net/index-ja.html Zinniaは機械学習アルゴリズム SVM を用いたポータブルで汎用的な オンライン手書き文字認識エンジンです。Zinniaは組み込みの容易さと汎用性を高めるために、 文字のレンダリング機能は持っていません。Zinniaは文字のストローク情報を座標の連続として受け取り、 確からしい順にスコア付きでN文字の認識結果を返すだけに機能を限定しています。 また、認識エンジンは完全に機械学習ベースであるために、文字のみならずユーザの任意のマウス・ペンストロークに対して任意の文字列をマッピングするような認識エンジンを小コスト作成することができます。 2年前に、Ajax手書き文字認識と言うものを作ったのですが、その認識エンジンをスクラッチからポータブルでつ
TinySegmenter: Javascriptだけで実装されたコンパクトな分かち書きソフトウェア
TinySegmenterはJavascriptだけ書かれた極めてコンパクトな日本語分かち書きソフトウェアです。 わずか25kバイトのソースコードで、日本語の新聞記事であれば文字単位で95%程度の精度で分かち書きが行えます。 Yahoo!の形態素解析のように サーバーサイドで解析するのではなく、全てクライアントサイドで解析を行うため、セキュリティの 観点から見ても安全です。分かち書きの単位はMeCab + ipadicと互換性があります。 デモ 日本語の文章を入力し、解析ボタンをクリックしてください。 ダウンロード TinySegmenterはフリーソフトウェアです. 修正BSDライセンスに従って本ソフトウェアを使用,再配布することができます. Download TinySegmenter version 0.2 使い方 <script type="text/javascript" src
きまぐれ日記: 動的配列への追加コストはなぜ O(1)?
動的配列への追加コストは O(1) ってのは覚えていればそれだけの話ですが，どうしてかと言われると意外と難しいものです． というのも, このO(1)ってのは動的配列の実装方法に強く依存しているからです．実装を知っていないと答えられません． 一般論として，1つ要素を追加するとき，配列に空きがなかったら新しく配列を作り直して全要素をコピーする必要があります．コピーのコストは O(n) だから，追加コストも O(n) になるという議論が混乱の元になっています． こういうときは，要素追加を n 回繰り返したときの計算量を n で割った平均をとるという解析方法が使われるそうです．一般に, ある operation C の計算量を C を n 回行ったときの計算量 O(n) を n で割った値 O(n)/n で評価する手法をならし解析 (amortized analysis)と言うそうです． さて，s
きまぐれ日記: ソートの平均要素移動距離
配列をソートする際に各要素の平均移動距離はどれくらいになるか問題が同僚の間で話題になった. 結論から言ってしまえば，サイズ n の配列の場合平均移動距離は n/3 になるらしい． サイズ n の場合, 最右の要素は [0 .. n-1] に等確率で移動するので，直感的に考えると n/2 のような気がする．しかし，真ん中の要素は両側に移動するので，その距離は小さくなる．平均移動距離は n/2 より小さい値になるはずだ. 頭で考えるより手を動かしたほうが楽なので，モンテカルロサンプリングしてみた. 配列をランダムにシャッフルし，ソート済みの配列と比較して各要素の平均移動距離を求める．これを 1000 回繰り返し平均値を計算する. #include <iostream> #include <vector> #include <cmath> #include <algorithm> static
きまぐれ日記: MIRAとstructured outputs
MIRAというアルゴリズムが統計的係り受けの学習でいい成績を叩き出しているようです． 係り受けに特化したアルゴリズムではなく，structured output ならほぼ何でもできる非常に汎用性の高いアルゴリズムのようです．詳細はこちら 面白そうなので，ちょっと深追いしてみました．特徴をまとめると - オンライン学習 - k-best解が得られるような decoder さえあれば動く - single-best でももちろん可能 - single best の場合は Collins voted perceptron に酷似 - single best の場合の inference は SMO と共通点があり，実際 max-margin parsing の特殊系になっている などなど，面白い点がたくさんあります． もともとは Ben Tasker の Max margin parsing の
きまぐれ日記: Javascript でキャレットの位置を取得できる?
Ajax IME は Javascript を悪用しつつ強引にインラインかな漢字変換を実現しています． 簡単そうに見えて以外とややこしいのが，変換候補の表示. textarea のキャレット(カーソル) のピクセル単位での位置をなんとかして取得してその位置に変換候補を 出す必要があります． ありがちな google suggest ような補完インタフェイスだと inputbox の真下に出せばいいので位置は完全にわかるのですが，textarea は簡単ではありません． 調べた限り，どうやら標準ではキャレットの位置を取得できないそうです． ただし IE だと以下の方法でピクセル単位での位置がわかります. var caretPos = document.selection.createRange(); y = (caretPos.offsetTop + document.documentEle
きまぐれ日記: Schwartzian Transform でランダムシャッフル
Schwartzian Transform を使って配列をシャッフルする話をみて、なるほどな～と思いつつも、よくよく考えてみるとこれは2つの意味で駄目です。 1. 計算量が O(n * log(n)) であること。 2. ランダムにシャッフルできない。 1. は説明するまでもないので、2の理由を考えてみます。 まず、rand() が 0..k-1 までの k種類の整数から 1 つ数値を返すものとします。配列のサイズが n の場合、 weightの並びの場合の数は k^n 通り存在します。ところが、配列の順列の場合の数は n! です。 ここで何か矛盾点があるように思えてきます。 実際に k = 2, n = 2 の場合を考えて見ましょう。この場合、サイズ2の配列をシャッフルするんですから、 要素を入れ替える場合と入れ替えない場合が 1/2 の確率で出現するのが正しいシャッフルです。 k =
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://chasen.org/~taku/blog/archives/2006/05/textmecab.html