タグ

ブックマーク / tkng.hatenablog.com (4)

  • The Tradeoffs of Large Scale Learningを読んだ - 射撃しつつ前転 改

    The Tradeoffs of Large Scale Learning (L. Bottou and O. Bousquet, NIPS 2008) は、大規模データから機械学習を行う際のエラーについての考察を行った論文である。 機械学習を行う場合、なんらかの損失を定義し、その損失を最小化するようにパラメータを調整する事が多い。また、最終的にその損失を0にする事は概ね不可能である。エラーが発生する理由を、さらに3つに分解する事ができる。 真の確率分布を近似する際に発生するエラー(例えば、混合正規分布を単なる正規分布で近似したりすると、表現力が不足する) 期待損失と経験損失で、最小化している物が違うために発生するエラー 最適なパラメータと、現実的な時間で求める事ができるパラメータの差分として発生するエラー 一つ目のエラーを減らすためには、できるだけ表現力の大きなモデルを選ぶべきであるが、

    The Tradeoffs of Large Scale Learningを読んだ - 射撃しつつ前転 改
    rawwell
    rawwell 2010/02/07
    "The Tradeoffs of Large Scale Learning (L. Bottou and O. Bousquet, NIPS 2008) は、大規模データから機械学習を行う際のエラーについての考察を行った論文である。  機械学習を行う場合、なんらかの損失を定義し、その損失を最小化するよ
  • Firefoxからsshのダイナミック転送を使って非公開サーバへアクセスする - 射撃しつつ前転 改

    sshにはダイナミック転送という機能がある。この機能を使うと、sshはアプリケーション側にはSOCKSプロクシとして振る舞うが、そこからsshの接続先までは暗号化された状態で通信が行われる。 これだけだと通常のトンネリングとどう違うのかよくわからないかもしれないが、ダイナミック転送の場合は転送ポートを指定する必要がない。ここがダイナミックと表現される所以だろう。 例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これまではsshのトンネリング機能を使ってアクセスしてきたのだが、ウェブアプリケーションをデバッグする際はいちいちウェブアプリケーションのポート毎にトンネルを掘るのが面倒くさい。オフィスに限らずデータセンターへ

    Firefoxからsshのダイナミック転送を使って非公開サーバへアクセスする - 射撃しつつ前転 改
    rawwell
    rawwell 2009/06/22
    "例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これ
  • しかしSVMも最近は速いらしい - 射撃しつつ前転 改

    Complement Naive BayesがSVMより速いよーと主張していたので、SVMもなんか最近は速くなってるらしいよ、という事を紹介してみたい。近年はSVMなどの学習を高速に行うという提案が行われており、実装が公開されているものもある。その中の一つにliblinearという機械学習ライブラリがある。ライブラリ名から推測できる通り、liblinearではカーネルを使うことが出来ない。しかし、その分速度が速く、大規模データに適用できるという利点がある。 liblinearを作っているのはlibsvmと同じ研究グループで、Chih-Jen Linがプロジェクトリーダーであるようだ。libsvmはかなり有名なライブラリで、liblinearにはそういった意味で安心感がある。(liblinearの方は公開されてしばらくは割とバグがあったらしいけど。) liblinearにはL1-SVM, L

    しかしSVMも最近は速いらしい - 射撃しつつ前転 改
    rawwell
    rawwell 2008/12/29
    『ボトルネックがCommunication & Synchronization Cost』『単純な計算時間自体はスケールしているように見えます』
  • Apacheのmod_proxy_balancerを使うときはretryを設定すべき - 射撃しつつ前転

    今作っているサービスは、Apacheのmod_proxy_balancerを使ってロードバランシングしている。しかし、バックエンドのサービスサーバを一旦落としてから復帰させると、コネクションがしばらくつながらないという問題に悩んでいた。1分ぐらい放置するとつながるようになるんだけど、1分は結構長い。 よくわからないのでソースを読んでみたところ、mod_proxy_balancer.cを眺めた感じ、ap_proxy_retry_workerという関数がコネクションの再確立をしているのではないかと思えた。しかし、関数の定義を眺めてみると、現在時刻がエラー発生時刻とworker->retryを足した数字よりも大きければworkerのstatusからPROXY_WORKER_IN_ERRORのビットを下ろしているだけで、コネクションの確立がどうのこうのなんて関数はまったく呼ばれてない。ここでなにが

    Apacheのmod_proxy_balancerを使うときはretryを設定すべき - 射撃しつつ前転
  • 1