トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|

ToDo:


2017-01-03

_ マサカリ

ぱっと震源わからなかったけど、この人達か

https://twitter.com/g3akk

https://twitter.com/kuenishi/with_replies

あまりなんという意見もないけど、とりあえず揉め事を見るのは楽しい

(13:23)

_ LLVM

すごーく大変だというイメージだったのだけど、バックエンドが割と動いてきてて、俺もなかなかたいしたもんだなぁとか思う。あとLLVMのコード、コーディング規約はムチャクチャだし、そこらじゅうにコピペがあるけど、慣れてくるとまあまあいじりやすいな

けどなんか出てくる問題がヘビーな感じになってきた。 signed int どうしたらいいかなあ。あった方がいい気しかしないんで、頑張って実装してみるか

int a = 1;
if (a < 0) abort();

int a = 1;
if (!(a > -1)) abort();

になるから abort するというのが、今起きてる問題で…ええと、両辺 0x800000 足してから比較すればオッケーか。ただ 0x800000 というのが 24bit 前提なのはダメで…色々めんどいな。どうしたもんか

やっぱ signed 実装はめんどい気する。とりあえず 16777215 じゃなくて -1 なんてのが出てくるのが問題といえば問題なんで、そっちをなんとかするかなあ

(14:01)

_ 囲碁master

http://nlab.itmedia.co.jp/nl/articles/1701/03/news011.html

すごい話やな

(22:46)


2017-01-02

_ FFRK

年末、クラウドさんがおかしな理由で復権した

あらすじ: http://shinh.skr.jp/m/?date=20150530#p02

ジャ系魔法によって、魔法が台頭したところまでか。

物理復権(第二次)

FFTが入ってくる。FFTていうのはヘンなゲームで、なんだか知らないが、主人公が弱い。正確には戦うと別に強くない凡庸な人なのだけど、仲間や自分を強くするアビリティをたくさん持っている。なんか主人公がひたすら仲間を励ましたり叫んだりしている中、途中から入ったバランスぶっ壊れの常に2倍速で動く爺さんが敵を殲滅する、というようなゲームだったのだった

で、それを割と忠実に再現したんだろうけど、ラムザさんはFFTにさけぶという、当時は完全にぶっこわれた必殺技と一緒に出てくる。効果は仲間全体の物理攻撃力1.5倍(ダメージにすると2倍程度)+ヘイスガ。そもそもヘイスガだけでも割と貴重な時代だったのに、なんでいきなりダメージ2倍やねん的な

FFRKは、鉄壁のグリモアとかいう、敵の全ダメージ6割カット、というアホな必殺技を入れてしまった→持ってるか持ってないかで格差デカすぎ→フレンドという機能で他人の必殺技を一つ持ち込めるようにして、格差を埋める

という歴史があったのだけど、さけぶのせいで必須必殺技が2つになってしまった。両方持ってなかった僕はなんだか大変だったように思う。まあ必須と言っても、さけぶの方が無いなら無いでキツいがなんとかなった……というか当時が一番頭使ってた気がする

バースト必殺技

バッツに強い必殺技が→3日後→ロックにもっと強い必殺技が→3時間後→クラウドさんバースト必殺技という新ジャンル技ゲット

みたいな感じでバッツとロックを当て馬にしつつクラウドがすごく強い必殺技を持ってくる。今までのダメージ必殺技は、使うと何回か殴ってかなり強い、みたいな感じだったのだけど、バースト必殺技は使ったあと4ターンほど強いモードになって、「たたかう」と「ぼうぎょ」コマンドが消えて変わりに結構強いバーストアビリティができるようになる…みたいな感じだった

クラウド自体は後続に割とすぐにどんどん抜かれていったけど、バーストというアイデア自体はなかなか楽しさやら爽快感があって、良い発明だったように思う。

魔法復権(第二次)

物理攻撃の強さは割と長い間頭打ちになっていた。物理攻撃力に対するダメージの計算式は、攻撃力が低いうちは攻撃力の1.8乗で線形より勢いよくダメージ量が増えていくんだけど、攻撃力が特定の値になると突然 sqrt(攻撃力) に比例する感じになって、それ以上攻撃力を増やしてもほとんど意味ない、みたいな感じになるからだった。レベルが上がったり装備が良くなったりした結果、さけぶを使うとだいたいその地点に到達しちゃうのであった。

一方、魔法はさけぶの1.5倍みたいな増え方をするバフ必殺技は無かったのだけど、1.3倍の必殺技がいくつかあった。これを2,3回重ねがけすると、魔法は物理より遅く sqrt(魔力) に切りかわるので、物理より強い攻撃ができるようになってきたのだった。

あと、なんかこれバランスおかしいでしょ、っていう魔法系バースト必殺技がいくつか出てきた。最初はFF2のマリアで、次に目立ったのはFF13のレインズかな。マリアは物理必殺技より強いくらいの威力あるんじゃないのコレ、ていう威力のバーストアビリティを毎ターン撃ってた。レインズはその規模の威力に加えて、発動時に全体の魔力1.3倍アップ、防御力もちょっとアップ、バーストアビリティの行動の間隔が短い、使いやすい聖闇属性、みたいな、なんでこんなに強い要素をてんこもりにしちゃったの、的なものだった

この時期くらいから、なんか妙に脇役とかマイナーなキャラが強烈に強い必殺技を持ってる不思議な感じになってたと思う

しかしというかこのダメージのシステムはどうなんかね。最初から比例くらいにしておいた方がインフレを制御しやすいと思うんだけど、なんで 1.8 乗とか使うんだろう

物理魔法拮抗

あとなんかオーバーフロー必殺技というのが出てきて、9999ダメージじゃなくて99999ダメージを最大値とした単発の技が出てきた。バーストの方が継戦力に優れるわけだけど、このゲームのボスは基本後半の攻撃がすごく強いので、一撃ででかいダメージを与えて発狂フェーズを短期決着できるのはなかなかいいじゃん、という感もあった

この頃の後半くらいに、物理が sqrt になる地点を上げたりして、まあ物理も悪くもないね、的な感じになって良いバランスになった気がする。物理は威力は劣るもののデバフとかが充実してるのと、物理魔法攻撃力両方1.3倍、みたいなのが出てきたため、物理と魔法混合パーティが普通に使える感じになってきた

あとマルチプレイヤーでの戦闘も実装されて、適当な人と組むとどうしても物理魔法混合になりがちということもあった

まあでも魔法の方が強いかな…ていうくらいのタイミングで、最初にバーストをもらったせいで後続より絶望的に弱い感じだったクラウドに、2つ目のバーストがきて、なんか普通に強いぽかった。でその後にFF8の主人公のスコールにも2つ目がきて、これはもっと強い感じだった

とまあ、物理と魔法両方使えるし、主人公格が強くなってきたし、なんか色々あったけどいい感じに進んでるなぁ…とか思ってた。年末年始のガチャで登場するものも、今までの強いやつを順当に強くしてる感じで、まあホントいい感じだった

クラウド

クラウドに新基軸の武器が与えられる。なんだかそれ自体がそれなりに強い攻撃をした後、ソルジャーモードというのに短期間入る。ソルジャーモード中は、確定クリティカル、ダメージアップ(攻撃力アップでないのでsqrtがどうこうの議論が無い)、とすごく強くなる。この技を使ってから既存のクラウドの必殺技使うと20万ダメージとかいって、今までは色々準備して99999で喜んでたので、これはすごいインフレだなぁという話になった

このくらいまでなら良かったのだけど、このクラウドの技、メインの部分は割とどうでも良くて、瞬間火力を増やしてくれる部分が嬉しいので、フレンドとして強いキャラが使うとなんかいいじゃんとなった。つまりガチャしなくていいというか

で、これをフレンドとして使うもっとも有効なキャラは…ということで出てきたのがFF8の雷神。なんか6回ほど貯めてから使うと大変強い攻撃*10、みたいな技があるので、6回貯めてクラウドさん呼んで、仲間がいろいろ補助してから撃つと、60万とか70万とか出ることがわかった。

これは現環境では、最強クラスの敵でも即死する威力。敵はだいたいダメージ与えるほど強くなってく感じなので、準備段階ではダメージを与えないように戦って、相手がショボい攻撃しかしないようにして、突然ドーンと終わらせる、みたいなことができちゃう。インフレで対処しにくい問題だと思うんだよね

しかしこの人、なんか主人公のライバルキャラと仲がいい人…みたいなとても脇役的なポジションらしいんだけど。。せっかくいい感じだったのに、どうなるんだろうこのゲーム感

(01:56)


2016-12-28

_ れじすたあろけーしょん

世の中色々デバッグが大変なものというものがございますが

レジスタアロケーションやスタックへのメモリ割りつけはクッソ大変なものの一つだよなってことを

思い出しました

(13:08)

_ 大変な理由

まず一般的に、そもそもデータを出力するプログラムのデバッグは大変。なぜなら、苦労しておかしいところをつきとめるまでは作業の序盤で、何故おかしな値を出したか、を調べなければならないからで、通常出力されたデータには出力した理由とかが不十分にしかあらわれていないことが多いから

レジスタアロケーションとかが何故余計大変かっていうと、アセンブリだからってのがあり。アセンブリっていうやつ、読む訓練を積んでいると読むの速くなっていくわけだけど、あれ何故速くなってるかというと、「こういうパターンの時はこういう操作をしている」というパターンマッチをひたすら行なう処理を良くしていってるから。

で、そのパターンマッチは出力されたコードは正しいことを前提にしてるから、すごく細かい、ここでBPからのオフセットが1つずれてる…みたいな処理は、本当見落とす。かといって脳内のパターンマッチルーチンを切った状態でアセンブリ読むのは慣れてないのだよなあ

(13:14)

_ チャート式

http://yukilingo.hatenablog.com/entry/2016/12/25/235754

高校がまさにこういう物量教育で辟易してたなぁと思う。うちの高校の言う通りやってりゃ受かるとか自慢げに言ってたけど、んなもん言う通りやってたらそれやるだけで1,2浪するがなっていう

全部やってこいみたいな宿題出てたから、半年くらい遅れつつ答えを全部写経(どうせチェックされないので適度に飛ばしつつ)してたけど、あの時間無駄もいいところなんで、つまり受験の邪魔されてたんじゃないだろうか

(21:38)


2016-12-23

_ あらゆる計算がDAGに見える

という病にかかっているように思う。まあ病といっても悪影響は特にないが

開始地点は…8年前とかで、 GNU gold なんかの記事を読んだあたりじゃないかと思う。まず、会社に入って、なるほど並列計算というのは色々難しいな、 asynchronous なサーバはこういう感じになるのか、などということを肌で感じた。で、 GNU gold がタスクをタスクキューに突っ込んでいって、終わったら依存が全部解決してるタスクが実行可能になって…みたいなモデルだと読んで、なるほどこれはバカパラレルでない計算についても最高速が出せる、完璧に正しいアプローチだなーとか思ったように思う

数年は完璧だと思ってたと思う。 Molatomium なんかが素晴らしそうだーと思ってた

http://jglobal.jst.go.jp/public/20090422/201102297100224901

実際、このモデルは計算の粒度が大きい、ビルドシステムみたいなところでは完全完璧に動く。ビルドシステムに色々な理由で関わって、この周りについてアレコレ考えたことは、病状の進行に間違いなく影響があったと思う。

でも、どこかの段階かで、銀の弾丸でないことに気付いていったと思う。実際、計算の粒度が細かいところで、このモデルで成功してる、つまり最高速に近い速度が出せてる計算環境は無いんではないかと思う。

理屈の上では完璧最強なDAGをワーカーどもが順番に取っていくモデル、なんで実際成功しないかというとデータのローカリティと同期のコストだと思う。つまり、理論上計算が完全に無駄なくスケジューリングされてるように見えて、粒度の細かさに反比例したロスが同期で起き、さらにデータのコアやマシン間のデータ移動でのロスも起きる。

僕が関わるようなシステム(つまりおおむね規模が大きく、計算よりはIOやメモリに律速されている)では、データのローカリティの方が特に大きかったように思う。例えばkatiで同時に計算できるから、こことここはパイプラインで…みたいなことをやったら、2倍弱くらいになって欲しいのに実際は1割かそこらしか速くならない、みたいなことがちょくちょく起きた。これなんかは非常に粒度が大きい並列化で、プログラムを書いた本人が、一番適切だと考えてる、つまり一番同期の回数が減るであろうと考えてる地点でブチっと切ってるにも関わらず、あまりうまくいかなかった。コードの見た目の裏で行なわれてる、キャッシュミスの影響がでかいということかなと思う。

こういう話をしてると、「今時のコンパイラは人間より賢いから〜」氏が湧いてきたりする。これはまあ…局所的なところでは正しいこともあるし、特に計算が律速してる世界では正しいことも多いと思うんだけど…データをどこに置くか的な話題はまだまだコンパイラにはできないように思う(もちろん研究はたくさんあるようだが)。というか、C言語をはじめとする現代のプログラム言語の抽象単位が、データへのアクセスを等速と考えすぎてて、なんかうまいこといく気が全くしない

でも、「今時のコンパイラは人間より賢いから〜」氏がそんなに論外なことを言ってるかというと、むしろ氏は結構正しくて、実際問題人間がとても効率的に動くデータ配置を考えてるうちに、機械が目的を達成してる、なんてことはまあ普通に起きるわけで。ここで最適化というのは、単に最速でリリースできるような結果が欲しいという話で、5年後に0.01秒でサーブできるシステムができるよりは、1年後に1秒でサーブできるシステムができる方がいい、っていう、ガチ最適化屋としてはつまらないであろうトレードオフがあり。まあつまり老人が言ってるイメージ、というかステレオタイプがある「結局機械の最適化は人間がやる最適化には勝てない」は、無限時間が経過した後では正しいのだけど、現実には無限の時間給料払ってられないので、まあトレードオフになる

さてそんなところにtensorflowです。これは完全にDAGをどうこうという計算モデルで…しかし人間が tf.device でどこで計算をするかを決めることができる。うーんなるほどという感じ。こいう計算モデルで計算時間的に最速のものが出来るとはとうてい思えないけど、まだまだどういうふうにやればいいか固まってないジャンルだけに、とにかく開発者が新しいモデルを実験する時間を最小化して、しかし年月単位とかでは待ちたくないので、ほどほどにスケールするようにする、てのはなかなか良い落としどころな気もする…

まあ、で、それはそうとDAGに戻ると、LLVMのバックエンドを見ると、これはこう、SSAしたコードてのは、最初っからDAGなわけです。TFのDAGも実質一個ループを入れてやれば十分にTuring完全なやつだろうし…うーんDAGてのは強力な物体だなあなどと思うわけです

CPUてこう、最終的には順番に並んだ命令を実行してるわけだけど、現代的のCPUは命令列からDAGというか依存関係を復元してたりするわけで、そもそも最初から命令セットは単なる配列じゃなくて、DAGであるべき…てことはないんですかねえ。現代的なコンパイラがDAGを作って命令列に落として、CPUが命令列からデータ依存を考えてる…てのはムダな気がするというか

PEZYの人たちとかが死ぬほど考えてそうな話題だとおもう

(02:12)


2016-12-14

_ フラグ

https://twitter.com/omo2009/status/808539204850315264

gflags好きっ子としてはね…というかglobal変数が好きというのがある。GLのアレとかTFのsessionとか、まあ悪くないという感がある。いやそれはあまり関係ないだろうけど

フラグの値をテストの冒頭で挿したりするの、あれはまあいいんじゃないかって感があるケースと、うーん微妙というケースがある気がする

なんかおおざっぱに言うと、フラグが使われるのがモジュール内の奥地で、モジュールのプライベートな関数とかが全部のそのフラグを引きまわすようなケース…これはまあテストの冒頭で挿す方がいいと感じる。なんていうか、テストが汚なくなることによって、プロダクションのコードが綺麗になるならいいじゃないか、的な

一方で、 func(FLAGS_hoge) みたいな感じで渡した引数が func の中だけで使われてないと、これはちょっと引数にして呼び出し側で定義した方がいいかなぁ…などと思うケースも多い気がする

まあでも基本ケースバイケースだと思うんだよなぁ。正直このへんの決定をどっちに倒しても生産性とかに大幅に差は出ないわけで、自分がチーム内で弱い立場なら他の人の決定に従い、強いならちょっと自分の趣味を主張してみる、みたいな、そのくらいでいい気がする。このレベルのことだと、ほげほげというアプローチがグッドプラクティスです、みたいに主張するのも、こう「それによって生まれる軋轢」>「統一によって得られる快適」みたいになる可能性もあるよなと思う

僕はこう一応、このレベルの話に関しては「あ、うん、僕はAの方が好きなんですけどね、まあBの主張もわかるんで…このプロジェクトはBで統一しましょう」みたいな対応をできてる……つもり……だといいな……ホントかな

(00:57)

_ まあテストというのは

本質的に書く流儀みたいなのがわれやすい感あるよね。

似たようなちょっと難しいテストケースを複数書く時とか、どうも同じコードをコピペしがちになって、それはよくないと共通部分をくくり出したりすると、それはそれで「テストはのっぺりとした入出力の羅列であるのが望ましい」みたいな感覚と矛盾したりして…

僕はこれについてはどっちかというとくくり出したいタイプかなぁと思う。基本同じロジックが2回以上目に入るのがあまり好きでないのだけど…テストだから小賢しい抽象化しないのが良い、みたいなのが理解できるケースも多いんだよな

まあ知らん系

(01:02)

本日のツッコミ(全2件) [ツッコミを入れる]

_ morrita [概ね同意で、話の流れとしては https://talks.godoc.org/github.com/tcnksm/..]

_ shinh [はい、フラグのとこだけそのスライド読んでから書いたので、もりたさん同様、「良くない例なの?むしろグローバルがいいだろ..]


2016-12-06

_ fancontrol

どうもファンがムダにうっさいぽいので導入してみた。

/etc/default/grub をいじって

GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax"

その後 sudo pwmconfig 。できたファイルを見ると FCTEMPS が無くて不審だった。なんかどうも temp3 が CPU 温度ぽかったので

INTERVAL=10
DEVPATH=hwmon2=devices/platform/it87.2608
DEVNAME=hwmon2=it8728
FCTEMPS=hwmon2/device/pwm1=hwmon2/device/temp3_input
FCFANS= hwmon2/device/pwm1=hwmon2/device/fan1_input
MINTEMP=hwmon2/device/pwm1=20
MAXTEMP=hwmon2/device/pwm1=60
MINSTART=hwmon2/device/pwm1=150
MINSTOP=hwmon2/device/pwm1=0

て感じで。負荷かけてみた感じ一応機能してるみたい…

(12:01)


2016-12-02

_ 依存型

Tensorflowでshapeに定数じゃない値で型つけたいみたいな気がするけど、依存型てそれ?て聞いたら、そうだがこれを読め、と言われて流し読みした

http://notogawa.hatenablog.com/entry/2016/11/19/145847

なるほどよくわからん…が銀の弾丸じゃないぽさが漂ってるなあ…と思った。僕が欲しいのは単にtype annotationに近いものな気がするな

それはそれとして、型だけじゃなくて、実行フェーズが二段階ある、てのも話をややこしくしてるなぁとか思う。なんかスコープが複数ある感じになるのがなぁという。スコープとかデバイスの設定にwithを使ったりするわけだけど、あれはmutexとかと似た面倒さがある気がする

def foo_in_scope:
  return ...
def foo:
  with scope():
    op = foo_in_scope()
def foo_and_bar:
  with scope():
    op = foo_in_scope()
    op = bar(op)

みたいなやつとか。foo_in_scopeにwith文持っていって共通部分をくくり出したい気がするけど、できない系

(10:10)

本日のツッコミ(全1件) [ツッコミを入れる]

_ notogawa [説明のための題材選択は,最近の仕事がらみ,プラス, shinhさんが http://shinh.skr.jp/m/..]


2016-11-29

_ ディープ

最近話してて、ディープラーニングがどうこうって、自然科学ぽさがあるなと思った。計算機科学って人工物なので基本的に原理からきちんとわかってるところが多いわけだけど、ディープラーニングはあまりそうではない。なんだかよくわからないブラックボックスがあって、ミクロな原理はよくわかってないけど、マクロな観測から役に立つものを作ったり。

例えば薬とかって、「原子分子レベルの機序はよくわかってないけど、経験上この物質はこの病気に良くて、直感的な説明はほげほげ」くらいの感覚で実用物を作ってる面があると思う。ディープラーニングも、「quantizeして大丈夫ていう科学的な根拠はないけど、経験上結果に悪影響ないことが多くて、直感的な説明としては、元々ノイズに強いニューラルさんにとっては計算精度の低下もノイズの一つとして扱ってると考えられる」など、まあ似てる

こういう状態で取れる方向性としてはおおまかに二種類あるかなあ…と思う

  • ブラックボックスのふるまいを観測し、より良く理解して、その理解を応用してより良いものを作る
  • ブラックボックスはそのままに、とにかく色々やってより良いものを作る

前者はまさに自然科学という感じで、仮にブラックボックスをきちんと理解できれば、他の計算機科学に近づくかなぁ、と思う。

後者は色々やる、てのを今は人手でやることが多いと思うんだけど、その色々やること自体を機械にやらせることになるのかなぁと思う。そうなるとますますブラックボックスが大きくなることになって、ディストピア感もあるが、それはそれで面白い展開かもなぁと思う

20XX年、ディープラーニングがどう動いてるかをディープラーニングで動くAIに考えてもらったところ、1年ほどの計算の後AIはAIの動作原理を理解したという。しかし人間にはAIの説明するAIの動作原理は理解できなかった……

などという

(22:12)

_ 下訳

http://blog.practical-scheme.net/shiro/20161124-machine-translation-as-draft

大変建設的な議論で良いなあ

機械翻訳を下訳に使うての、欧米の言語だと割と普通にやってることらしいですね。EUとかが無限にクオリティの高いコーパスを作ってくれて、それのおかげで機械翻訳のクオリティが良くなり、さらにそれが翻訳作業を加速させてコーパスがたくさんできて……みたいな

(22:16)


2016-11-11

_ 大統領選

http://www.huffingtonpost.jp/michael-moore/5-reasons-why-trump-will-win_b_11254142.html

via https://twitter.com/kinu/status/796257849886183424

マイケルムーアの選挙前の文章、全部面白かったけどきぬこさんがはってた上と

http://www.huffingtonpost.jp/michael-moore/5-ways-to-make-sure-trump-loses_b_11900362.html

はコイツ本当にすごいやつだなあと思った。前者の読みはこれだけ危機感出しても甘かったくらいだったのが現実なわけだが

(02:01)


2016-11-04

_ 人生の転機

最近機械学習ぽいこと、というか機械翻訳という、流行りの深層学習を使ってるぽいチームに移ったりしてた。理由は流行りぽいからという、まあ

というような話を結構前にした時に、人生の転機と書いてたのは、結婚か転職かと思われた、というようなことを言われて、そんなの書いたっけ、と思った。まあ結構前に

http://shinh.skr.jp/m/?date=20160609#p01

で思い出して調べたら、ホントだ書いてた。まあ今みたいに酔っぱらって適当なことを書いてたのだと思われる…特に全然違う話題が2行目にあるあたり酔っぱらってる感がある。が調べるとタイミング的にはまあこのへんに異動したぽい

しかし人生の転機でないかと言われるとまあ転機ではなくはないと思う。がまあ結婚か転職でないなら違うというのが通常の考え方かなあと思う。せめて海外転勤くらいしてくれないとという感がある

ええとそんなことよりディープラーニング。よくわからないなあというのが正直なところ。何がわかってないか、何がわかってないとわかってるのか、何がさっぱりわかってないのか、考えてみると

  • オーバーオールとして、何故これがうまくいくのか。わからん、そしてこれはどうも、誰もわかってない。謎であるということがわかった
  • 古典(とはいえAI研究としては僕の分類では3つ目くらいの世代の)、というか統計ベースな機械学習。全くわからん。今ならこのレイヤの研究を完全にすべてすっとばせそう、という理由で今のタイミングで異動したと言って問題なかったように思う
  • いうてSVMとかK-meansとか、まあうん、「ああそれ授業でやったな〜」学生程度の理解はしたような気もする
  • まあそのへんすっとばしたのは正解であろう。別にいらない気がする
  • 深層学習。重みがたくさんあって、十分に深くて、もうなんでもいいから非線型なんかを入れると、なんかうまくいく。うまくいかないなら次元を増やすか深さを増やせ。というような世界観に思う。いやそんなことはないんだろうが、現段階で結果的にそうなる気がする
  • 既存のモデル、こういうことを期待してこういう作りになってます〜、実際結果もいいんですよ〜と主張している。実際結果もいいし、部分的にはその期待通りに動いているような値を出してる場所もあるんだけど…しかし誰も何故本当にその作りで期待されている学習が行なわれるか、本当に期待されている学習が行なわれているのか、あまり確認できてないように思われる。とにかく入口と出口以外に人間が評価できるポイントがあまりない(翻訳の場合少しあるんだが、うーんホント感)
  • 論文。そのよくわからないところに、さらに上乗せで「こういう問題に対処するためにこういう解決が起きることを期待してこういう実験をしてみました〜」みたいなのが多いという印象。たいていうまくいった例がくっついているが…定量的にその部分に関してうまくいったということを測る指標がないのが、ウーン
  • あとネットワークを複雑化すると常に一定よくなるというのがあると思っていて、提案手法はたいていベースより複雑になってるので、その効果を越えられているん?というと、ウーン
  • そもそも https://xkcd.com/882/ が起きてないの?ていうと、ウーン

ちょっとこのへんで話題が変わってるというか、個人的な話が増える

  • tensorflowがわからない。コードが読みにくい。どうも数式がコードに落ちてる…ていうのに馴染みが少ない
  • そもそも数式が読めない(まあ適当に流す)。3次元を越えたものは僕にはわからないということが、物理学科の学生として学んだことであった
  • P(Y|X) を見るとウッヤラレタと思う
  • しかし驚くべきことに、Πとかが登場する複雑な式は読めるケースがある。何故ならそういう式は割と思いつきで作られてる(素人の感想です)
  • 毎度LSTM/GRNのこれてなんだっけ、みたいなことになる(まあ適当に流す)
  • tensorflowで作ったグラフをダンプしたやつがデカすぎてよくわからない(そもそもダンプして読むみたいなobjdump読む的発想が良くないという批判はあると思う)
  • グラフを理解したとして(してないが)、それが実際どう計算されるか想像できてない
  • ネットワークまたいで何MBの転送が起きてるんだろうか
  • CPU-GPU間で何MBの転送が起きてるんだろうか
  • GPU-GPU間で何MBの転送が起きてるんだろうか
  • GPU内の並列性てどのくらいの規模のなに
  • パラメータサーバちゃん、本当に必要なの
  • SGDはわかる。それをadaptiveにしようてのもわかるんだが…なんで何種類もあるの
  • 簡単なコードを足すと…typoでこける。Pythonていうか動的型付け言語苦手やねん
  • self が無いとかね(たぶんこのグチ100回目くらい)、もっと早く教えてほしい
  • テンソルの形が違うとかね(new!)、もっと早く教えてほしい
  • tensorflow、使いかたのドキュメント多いけど、中どうなってる、ての少ないような。whileとかどうなってるねん。なんでcondに渡すのlambdaやねん
  • それはそれとして、とりくむ対象に対する、古典的なアプローチについての勉強は重要に思う。やはりドメインの理解は重要だなあとか
  • 少なくとも機械翻訳はそう感じる。alignmentとかBLEUとかは知らないとどうしようもない感があった

などなど……まだまだあったと思うけど

(23:23)


2024年
5月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
1.shinh(2016-12-14 13:34) 2.morrita(2016-12-14 03:48) 3.notogawa(2016-12-02 20:44)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h