Content-Length: 319816 | pFad | https://b.hatena.ne.jp/site/chasen.org/~taku/
サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
iPhone 16e
chasen.org/~taku
iPhoneのSDKの条項に変更が加わり、Flashのクロスコンパイルを含む 純正開発ツール以外で作成されたバイナリの配布が禁止となるようです。 世間でも散々言われていますが、この変更は正直とても残念です。 Apple的には「製品のクオリティーが保てないから」という理由だそうですが、 Windows版iTunesが意味もなくQuickTime入れたり、Windows非標準のUIを 使いまくっていて、お世辞にもクオリティーが高いとは言えないのを棚にあげて、 クオリティー云々と言い訳できるのでしょうか。アプリなんて所詮 玉石混淆。決めるのはユーザです。 MeCabは以前GPL/LGPLでした。Appleを含む複数の方からこのライセンスでは 使いにくいと言う指摘をうけ、前職の同僚と協議をしながらBSD/LGPL/GPL のトリプルライセンスにしたという経緯があります。結果としてこの変更は うまく
UbuntuやMac OSXを使っていると、権限の高いオペレーションを実行しようとしたときに、ユーザのパスワードを要求するダイアログが起動します。毎回ハイハイと思いつつ入力しているのですが、ふと考えるとこのセキュリティモデルというかユーザビリティー的に大丈夫なのかどうかと思うようになりました。 例えば、インストーラーでダミーのパスワードダイアログを表示させればマルウェア作者はユーザのパスワードを取り放題だし、OSのファイル保存ダイアログをクラックして、適当なファイル保存のタイミングで同ダイアログを出せば、無知なユーザはホイホイパスワードを入力してしまうのではないでしょうか。Webサイトのフィッシングと全く同じ話です。 このダイアログはそもそも CUIプログラム sudo のラッパーにすぎません。しかし、話はそんなに単純ではありません。CUIの場合は、ほとんどの操作が「能動的」なために、su
最近IT業界界隈で勉強会がブームになっているようです。子持ちエンジニアにとっては 参加したくても参加できないのが残念だったりしますが、時間のある 若い人には参加するだけでなく、ぜひそこで発表し意見をぶつけ合って欲しいです。 私が在籍していたNAISTの松本研は、それこそ勉強会だらけの研究室でした。 いまでもその伝統は残っており、スケジュールを見ると勉強会の多さに驚かされます。 私はデータマイニング・機械学習の勉強会に参加していたのですが、 6~7人のメンバーで週二回のペースで論文を読みまくっていたので、 結構な頻度で担当が回ってきました。最初の頃はこのハイペースに戸惑う学生 もいますが、徐々になれてきてこのペースの勉強会に積極的に参加し発表(論文紹介) できるようになってきます。物心がつくと、勉強会のために論文を読むのではなく、 日頃から暇を見つけては論文を読むような習慣が身についてきます
プログラマ・ソフトウェアエンジニアと呼ばれる人間には、 2つのタイプがあるような気がしています。 ひとつは、もともと機械いじりやハードウェアが好きな 「ハードウェア」プログラマ、もう一つはその反対の「ソフトウェア」プログラマ。 それぞれどういう特徴があるか、独断と偏見でまとめてみました。 (私自身ハード出身なのでそちらに偏重していますw ) 「ハードウェア」プログラマ 「最適化」という言葉が好き 外的な制約(メモリ/速度/ディスク)がある方が燃えるし、真の能力を発揮できる 逆に制約がないと何していいのかわからず、平凡なアイデアしか思いつけない 開発言語は、制約から決定する O(n) の計算量でも、その定数項を気にする 専用ハード好き (地球シミュレータ, メーンフレーム) 定量評価ができないような仕事は興味ない 固定長データ バイナリデータ 再帰なんてもってのほか スピード狂 CPUがどれ
世の中には熱狂的なファンに支えられるサービスやプロダクトがあります。 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 実際には、最後の文字も変わらないし、 単語の長さが変わらないというもの、大きな
組込用のIMEを作っている方とお話したことあるのですが、組込用のIMEは ポータビリティを高めるために、いわゆるファイルIOは使っておらず システムからimmutableメモリ領域(システム辞書など)とmutableメモリ領域(ユーザ辞書など) をわたしてもらって使うような仕様になっているそうです。 ファイルIOはポータビリティを考えるといろいろ面倒なことがあるのでなるほどな思いました。 実はこういうバイト列を辞書のシリアライズ先として使うことはプリミティブですが身軽です。 自然言語処理のシステムでは静的な辞書や機械学習結果のモデルをロードすることが多々あります。 自分が何かを作るときは、辞書や学習モデルをバイナリのバイト列として格納し、メモリイメージとして読み込むような設計にしています。 例えば、Dictionary というクラスがあったときには、ファイルから辞書を読み込むような インタ
http://www.atmarkit.co.jp/news/200904/10/matz.html PerlやRuby、Pythonといったスクリプト言語では、 記述が非常にストレートで端的になる。JavaやC++といった言語では、 「public static void mainなど、コンピュータに伝える約束事が多くて、 やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」（まつもと氏）。 これは書くときだけでなく、読むときにも同様だ。 まつもと氏の記事を読んで、仕事として大規模な共同開発の経験に基づいているのかなと思いました。 publicとかstaticとかconstというのは書く側からすると約束事で めんどいということには同意しますが、毎日のようにコードレビューを している経験からいうと、コードレビューをする側にとってこいうキーワードがあるかないかで全く意味が異なります。メ
Next: LSI Probabilistic Latent Semantic Indexing (SIGIR '99) Thomas Hofmann International Computer Science Institute, Berkley, CA & EECS Department, CS Divison, UC Berkeley hofmann@cs.berkley.edu 発表者 工藤 拓 taku-ku@is.aist-nara.ac.jp 自然言語処理学講座 M1 平成12年7月4日 LSI Aspect Model EM アルゴリズムによるパラメータ学習 PLSI と LSI の比較 U-PLSI,Q-PLSI 実験,結果 考察 この文書について... Taku Kudo 平成12年7月4日
BACT: a Boosting Algorithm for Classification of Trees $Id: index.html 1574 2007-01-26 11:59:13Z taku $; Introduction BACT is a machine learning tool for labeled orderd trees [Kudo & Matsumoto 2004]. The important characteristic is that the input example x is represented not in a numerical feature vector (bag-of-words) but in a labeled ordered tree. Author Taku Kudo Download BACT is free software;
手書き文字認識エンジンZinniaを先日公開しました。全くデモがなくていまいちどういうライブラリか分かりにくかったのですが、Youtube 上に Zinnia を iPhone 上で動作させたというデモ動画を見つけました。すばらしい。 http://www.youtube.com/watch?v=i88uaIu3Khk ほかにもいくつかフィードバック等を見つけました。 Mathieu Blondel さんは、zinnia と tomoe, そして自身が開発なさっている hmm ベースの手書き文字認識エンジンを客観的に比較なさっています。 私自身こういう比較を 行なったことなかったのですが、tomoe に比べて、速度面でも精度面でもsignificantに上回っているようです。特に速度は 10倍ぐらいtomoenに比べて高速なようです。 他にも、tomoe本体の認識エンジンに zinniaを
オンライン手書き文字認識エンジンZinniaを公開しました。 http://zinnia.sourceforge.net/index-ja.html Zinniaは機械学習アルゴリズム SVM を用いたポータブルで汎用的な オンライン手書き文字認識エンジンです。Zinniaは組み込みの容易さと汎用性を高めるために、 文字のレンダリング機能は持っていません。Zinniaは文字のストローク情報を座標の連続として受け取り、 確からしい順にスコア付きでN文字の認識結果を返すだけに機能を限定しています。 また、認識エンジンは完全に機械学習ベースであるために、文字のみならずユーザの任意のマウス・ペンストロークに対して任意の文字列をマッピングするような認識エンジンを小コスト作成することができます。 2年前に、Ajax手書き文字認識と言うものを作ったのですが、その認識エンジンをスクラッチからポータブルでつ
Mac OS X Leopard の Spotlight に MeCab が使われているらしいという情報を聞いたので、実際に深追いしてみました。 いとも簡単に /usr/lib/libmecab* , /usr/include/mecab.h と /usr/lib/mecab/dic/apple/{ja,tc,sc} というディレクトリを発見しました。ts, sc は traditional/simplified Chinese (繁体字/簡体字) の略で、中国語の辞書だと推察されます。辞書のディレクトリはさらに dic/apple/ja/{LE,BE} という風に、エンディアンごとに分かれています。MeCabの辞書はエンディアン依存なので、こうするしかないのかもしれません。 さて、この辞書を使って、UTF8の文字列を流し込んでみたのですが、うまいこと解析してくれません。MeCabのバイナ
Anthy-YahooJIMServiceは、Yahoo!の仮名漢字変換WebサービスをLinux上の仮名漢字変換のバックエンドとして使うためのラッパーライブラリです。 libanthy.so (Anthyの変換コアライブラリ)を再実装し、そっくりライブラリ を入れ替えることで YahooJIMService経由での日本語入力を実現しています。 共用のLinuxデスクトップやキオスク・多目的端末での利用を想定しています。 機能 サポートされている機能 通常の連文節変換 予測入力 (SCIMを使う場合は予測入力の設定をONにしてください) 文節を伸ばす、縮める (JIMServiceの制約から完璧ではありません) サポートされていない機能 学習機能 (候補を修正しても、次回以降反映されません) ユーザ辞書 スクリーンショット 通常の変換. 右画面はYahooJIMServiceが返す変換結果
少し前の話ですが、Yahooがかな漢字変換Webサービスを出したようです。拙作のAjaximeみたいなサービスを簡単に作れるインフラが整ってきたようです。早速 Ajaxime のバックエンドをこれになーんてハックもいいのですが、やってて手応えがないので、Linux上で動く変換エンジンをYahooかな漢字変換サービスを使ってできないかと思って libanthy のラッパーライブラリを書いてみました。 http://chasen.org/~taku/software/anthy-yahoojimservice/ Anthyのドキュメントを読んでみると、APIセットが小粒で直感的で、数十のAPI関数を独自に実装したlibanthy.so をLD_LIBRARY_PATHで突っ込んでやればよさそうです。この方法のいいところは、UIの面倒なところを全くいじることなく、Yahooかな漢字変換Webサー
一時期オープンソースがはやった時期がありましたが、今はどうなんでしょう? 当時はオープンソースでバラ色の人生みたく過大評価されていたような記憶があります。 過大評価は言い過ぎですが、いまこうやってブログをかけるのもオープンソースの おかげであることは間違いありません。 しかし、すべてのオープンソースプロジェクトが成功したかというと、簡単に YES といえないような気がします。こういう話を某エンジニアとしたら、彼も 同じような視点(というかその方の場合は実経験かもしれませんが)を持ってて、 なんか話が盛り上がってしまいました。 その問題点とは肥大化です。オープンソースは誰でもプロジェクトに参加できるのですが、 ディベロッパーの技術もピンキリなため、時にはどーでもいい拡張がコミットされてしまう ことがあります。その最たるものが周辺技術との統合。ホニャララメタデータをMySQLに保存, ○○バッ
« 2005年08月 | メイン | 2005年10月 » 2005年09月28日 はてなキーワードを高速に付与 (マルチバイト処理) 前回に紹介した hackですが、いくつかの問題があるようです。 とくにマルチバイトの処理は完全にスルーしてました。まずかったです。mecab がやってることは件のキーワードの処理とほぼ同じですが、ちゃんとマルチバイト処理をやっています。そこで、安直に mecab の該当部分を移植してみました。基本的には mblen 相当を実装するだけです。(mblen を使ってもかまいません) Download file 投稿者 taku : 21:52 | コメント (44) | トラックバック 2005年09月23日 手書き文字データ Ajax 手書き文字認識を公開して、おかげさまで多数のアクセスがありました。 みなさんが入力,選択したデータは、すべて蓄積しています。
最近新幹線に乗る機会が多々あったので、暇つぶしに Javascriptだけで(Ajax等は使わずに) 分かち書きが出来るソフトウェアを作ってみました。実用性は謎です。 http://chasen.org/~taku/software/TinySegmenter/ たった 25kbyte ですが、新聞記事でしたら、95%程度の精度で分かち書きができます。 辞書は全く持たず、文字単位で分割するか分割しないかを当てる機械学習器を 作って分割しています。 モデルをコンパクトにするために、L1ノルム正則化の トリックを使っているのですが、想像以上にコンパクトになって、しかも そこそこうまくいっていて、刺激的です。
TinySegmenterはJavascriptだけ書かれた極めてコンパクトな日本語分かち書きソフトウェアです。 わずか25kバイトのソースコードで、日本語の新聞記事であれば文字単位で95%程度の精度で分かち書きが行えます。 Yahoo!の形態素解析のように サーバーサイドで解析するのではなく、全てクライアントサイドで解析を行うため、セキュリティの 観点から見ても安全です。分かち書きの単位はMeCab + ipadicと互換性があります。 デモ 日本語の文章を入力し、解析ボタンをクリックしてください。 ダウンロード TinySegmenterはフリーソフトウェアです. 修正BSDライセンスに従って本ソフトウェアを使用,再配布することができます. Download TinySegmenter version 0.2 使い方 <script type="text/javascript" src
CaboCha0.60pre1を sourceforge.net に置きました。 約2年ぶりの更新ですが、機能やアルゴリズムを整理し、フルスクラッチから書き直しました。 1年前から出張の移動時間などを利用してコツコツと書きためていたのですが、 この正月休みに一気に整理してみました。 変更点: - UTF8対応 (./configure --with-charset=UTF8) - 文節区切りと固有表現抽出に CRF (実装はCRF++)を使用 - ChaSenへの依存を廃止し、MeCab のみのサポートに - 固有表現を行う前に文字列の正規化を行うことで若干の精度向上 - 簡易並列処理の廃止。係り受けのみ - APIの一新、より粒度の細かい制御が可能 - PerlやMakefileに依存していた部分の排除。 - 単一バイナリ cabocha-learn による学習の簡易化 (Windows
Espresso を飲みながらさらに Espresso を考えていました。 r_instance = A^n * r_instance_0 となるのは間違いないと思います。A は P * P^{T}、さらに P = 1/|I||P| * pmi(i, p)/ maxpmi です。 A は、インスタンスどうしの類似度を表現した正方対称行列です。A_{i,j} はインスタンス i, j の類似度です。 類似度は、パターン個数次元からなるベクトルの内積で、各次元は pmi となります。 この形だと、r_instanc は r_instance_0 できまるので、初期値に依存してるように思えますが、A^n がいったい どういう意味を持つのかずっと考えていました。 A_{i,j} が 0, 1 の場合、A は無向グラフの接続行列となります。i,j がつながっている場合は A_{i,j} = 1となり
昨日のエントリーは私の完全な勘違いでした。大学数学やりなおします。orz 行列表現にはまちがいはないのですが、あの形はマルコフ連鎖そのものなので、 x_instance = A * x_instance の解は、x_instance = A^{n} * x_instance0 なので、x_instance0 の初期値 に依存します。A^{n} が収束し B になるとすれば、x_instance = B * x_instance0 となります。 A^{n} が収束することが条件ですが、相互情報量の最大値で正規化されているので、たぶん収束するでしょう。 しかし、Espresso のおもしろいところは, B が求まってしまえば、どんな初期値でもただ1回の行列のかけ算で 最終的な答えがでてしまうところです。 B は、全パターンと全インスタンスの類似度から生成される行列で、信頼度とは無関係です。相互
Espresso という情報抽出アルゴリズムを使った研究が散見されるようになったので、 ちょっと深追いしてみました。基本的に Bootstrapping をベースにしているようです。 Bootstrapping のアイデアはわかりやすいのですが、実際動かすには設定すべき パラメータがいくつもあります(各Iteration でどういう基準で何個パターンを 見つけたらいいのかなど)。 Espresso は、この設定すべきパラーメータが アルゴリズムとして明示的に記述されており、わりと再現・実装がしやすい アルゴリズムだと感じました。 しかし、式を追ってみると、最終的な結果は Seed に依存しないのではないか という疑惑が出てきました。 オリジナルの論文の式をみていきましょう。 http://www.patrickpantel.com/Download/Papers/2006/acl06-01
とあるIME開発者と仮名漢字変換(IME)における「文節」についてディスカッションする 機会がありました。今まであまり真剣に考えたことなかったのですが、 この「IME文節」、いろんな意味で興味深いということを改めて認識しました。 学校文法や自然言語処理におけるいわゆる「文節」とは 統語的な性質からほぼ一意に決定できる単位です。 簡単には 自立語連続＋付属語 と言えるでしょう。 たとえば、 「東京特許許可局で工藤は講演をした。」 は 東京特許許可局で｜工藤は｜講演した。 の3文節になります。小学校のときに「～ね」を挿入できる単位として 習ったかと思います。 しかし、IMEで上記の文を変換してみると。 東京|特許|許可局で|工藤は｜講演した|。 と分割されます。(WinXP) あきらかにNLP業界の文節と単位が異なるようです。 このIMEが使っている分割の単位を「IME文節」と呼ぶことにしまし
C++と Pthreads でミニマルなHTTPサーバを書く にて、ネットワークサーバのさまざまな設計・実装方針がまとめられています。 1. クライアントごとに fork 2. 事前に fork - 各プロセスで accept 3. 事前に fork - ファイルロックで accept を保護 4. 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PROCESS_SHARED) 5. 事前に fork - ソケットディスクリプタパッシング 6. クライアントごとにスレッド生成 7. 事前にスレッド生成 - Mutex ロックで accept を保護 8. 事前にスレッド生成 - メインスレッドで accept AjaxIMEの変換エンジンは自作サーバで運用しているのですが、初期の実装は prefork、 すなわち4番の実装でした。 その後、fork の部
MeCabで形態素解析器を作りたい場合は以下の二つの言語リソースが必要です。 1. 辞書 (単語と品詞のペアの集合) 2. 入力文と、それに対応する正解出力ペア(正解データ) 現在公開している mecab-ipadic は、ipadicとRWCPコーパスという正解データを使っています。 ここから分かるとおり、少なくともMeCabを使う場合は、コスト値を丹念にチューニング するといった職人芸は要りません。形態素解析への入力文とそれに対応する(理想)出力 があればコスト値を機械学習的なアプローチで構築することができます。 さらに、正解データを人手で作る必要は必ずしもありません。 すなわち、Yahoo!の形態素解析器の出力結果を「擬似正解」とみなして MeCabの学習プログラムを走らせれば、Yahoo!の出力を高い精度で再現できる MeCab用辞書を作成することが原理的に可能です。 ふだんはあま
hillbigさんのブログで 紹介されていた "Scalable Training of L1-regularized Log-linear Models", G. Andrew and J. Gao., ICML 2007. をCRF++上に実装してみました。 現在の CRF++ の実装、そしてオリジナルも含めた多くの実装は L2-regularized log-linear model です。hillbig さんのプレゼンにもありますが、L2は若干高性能だけど、全パラメータが非0になって、最終的なモデルがデカく なってしまうのですが、L1だと不必要･冗長なパラメータを完全に0にする効果があり、モデルをコンパクトにします。 3年前のmecabに関する論文では、L2 と L1 の CRF を比較して、L2のほうが若干高性能ということを確認していました。 L1-regularized の場合
次のページ
このページを最初にブックマークしてみませんか？
『Taku Kudo』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: https://b.hatena.ne.jp/site/chasen.org/~taku/
Alternative Proxies:
Alternative Proxy
pFad Proxy
pFad v3 Proxy
pFad v4 Proxy
