他の言語に慣れた人がPythonを使ったときにつまずきがちな10のポイント - 西尾泰和のはてなダイアリー
今日質問されて、以前Twitterで書いたのを思い出して、そして検索性が悪くて見つけ出すのに苦労した。こちらに転載しておく。詳細は気が向いたときに埋める。 オプション引数の評価タイミング Rubyではオプション引数は関数が呼ばれるたびに評価される。 def foo() print "foo!" end def bar(x=foo()) end bar #=> foo! と出力される bar #=> foo! bar #=> foo! Pythonでは関数の定義時に1回だけ評価される。 def foo(): print "foo!" def bar(x=foo()): pass #=> foo!と出力される bar() #=> 何も出力されない bar() 「引数が省略されたら今の日時」みたいな毎回評価したい場合はデフォルト値をNoneにしておいて「Noneだったら＝省略されていたら」のif
word2vecの特許の請求項9 - 西尾泰和のはてなダイアリー
word2vecの特許が話題だったので、請求項9をわかりやすくレイアウトしてみました。 9. (C1) A method for assigning a respective point in a high-dimensional space to each word in a vocabulary of words, the method comprising: { (C2)obtaining a set of training data, wherein { （C3)the set of training data comprises sequences of words } ; (C4)training a plurality of classifiers and an embedding function on the set of training data, wherein {
論文紹介「ガウス過程に基づく連続空間トピックモデル」 - 西尾泰和のはてなダイアリー
Deep Learningで単語を連続なユークリッド空間に投影したらそれが意味を表現すると盛り上がっているけど、それをやるのに最適化の難しいニューラルネットを使わないで正規分布だと思って最適化したらいい、という論文。 word2vecには直接論文上は言及していない。制限ボルツマンマシン(RBM)は一般にLDA(Letent Dirichlet Allocation)を超えるって言われてて、更に多層にして"Deep Learning"したら更に性能が上がるよ、なんて報告されているけど、最適化が難しいし、何を学習してんのかわかんないし、他のモデルとの接続が難しい。だから研究の場ぐらいでしか使われてない。 RBMでは隠れ層への重みが意味をコードしていて、LDAではp(k|w)が意味をコードしていて、結局のところ「単語がd次元連続ベクトルに対応している」というコンセプトが重要。というわけで単語をd
Deep Learning論文紹介「Deep learning via Hessian-free optimization」 - 西尾泰和のはてなダイアリー
"Hessian-Free"という新しい最適化手法をDeep Learningのauto-encoderの学習に使ってみたら事前学習なしで既存の報告の性能を超えたぞ凄いだろう、という話。 ニューラルネットのパラメータ決定はよく研究されている問題で、勾配法で効率よく計算できると言われている。しかしDeep Learningのように隠れ層がとても多いケースではうまくいかない。学習にとても時間がかかったり、学習データに対してさえ酷いパフォーマンスしか出せなかったりする(under-fitting)。 最適化に関する研究者の間では勾配法が病的な曲率を持った目的関数に対しては不安定であることがよく知られている。2次の最適化法はこのような目的関数に対してもうまく働く。だからDeep Learningにもこの種の最適化を使ったらいいんじゃないか。 でもまだいくつか問題がある。まずでかいデータセットに対し
スレッドの(というか並行処理の)歴史 - 西尾泰和のはてなダイアリー
Twitterから転載 ふとスレッドっていつ発明されたんだろうと調べてみたけどよくわからない。Linuxがカーネルスレッドをサポートしたのが2.6からで2003年とか意外と新しい？？もちろんユーザレベルのスレッドはもっと古いんだろうけど、いつからだろう。 hideaki_t: NeXTSTEP(Mach 2.0?)にはcthreadがありました。 atsuoishimoto: 私がスレッドって用語初めて聞いたのは、たしか'90年代初頭のOS/2だったかなぁ？ これが2004年の話か＞NetBSD 2.x+, and DragonFly BSD implement LWPs as kernel threads (1:1 model) shidocchi: 私は院の研究室でMachのソースリーディングをやってた頃知った。 これが2001年 ＞ October 2, 2001 Mac OS X
FPGAでライフゲームを作りました - 西尾泰和のはてなダイアリー
動画の内容 ランダムに初期化(see 線形帰還シフトレジスタ - Wikipedia) しばらく実行(高速モード：1ステップ3msec。VGA60Hzの画面の更新が17msecなので画面1回更新されるごとに5ステップ進んでいる計算) 画面をクリア、低速モード(256倍遅い)に移行 Rペントミノを配置するボタンを押す しばらく走らせる 高速モードに変える 実装 読み書き用のアドレスをインクリメントする 2行+3マス文の323bitのシフトレジスタに読んだデータをpushする(see シフトレジスタ - Wikipedia) シフトレジスタの0, 1, 2, 160, 161, 162, 320, 321, 322の9ビットを束ねてアドレスとし、ライフゲームのルールがハードコードされた512bitのROMから1bit読む 読んだ値をVRAMに書き込む 各1クロックでできるかな〜と思ったけども、
続:Haskellのfibが遅い件 - 西尾泰和のはてなダイアリー
とても勉強になる流れなのでとりあえずざっくりとまとめる Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い Haskellの有名なfibの定義は素朴なループでの定義に比べて格段に遅く、O(n^2.6)くらいの実行時間がかかり、N = 100000でPythonにすら負ける Togetter - 「Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い件」 Integerの足し算のコストとかも絡んでくるのでややこしいという話など fib = 1 : 1 : zipWith (+) fib (tail fib) が遅いかどうかは、使い方に依存する - www.kotha.netの裏 fibを先頭から順に使って行った場合(例:sum (take 300000 fib))の方が、fib !! 3
Needleman-Wunsch algorithmを実装した - 西尾泰和のはてなダイアリー
前に86チャットで誰かがdiffを作ろうとしていて、長さ N, M の文字列に対して素朴に N * M の配列を確保していたせいで大きなサイズの入力でメモリを食い過ぎて破綻していたときに「動的計画法で端から埋めていくんだから、直前の１列だけ取っておくだけでいいでしょ」「いや、後でパスを求めないと行けないから全部持つ必要があるんだ！」「ないよ！パスの根元だけ参照で持っておけばいらないパスはGCで消えるでしょ！」という話をしたんだが、今ちょっと自分でも必要になったので作ってみた。うん、思った通りに動くな。 テストケースに書いてあるけど、実行すると下のような入出力になる。 >>> test("1", "001") in1: 1 in2: 001 (((), (0, 2)), 'D') out1: --1 out2: 001 >>> test("1", "100") in1: 1 in2: 100
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
