ToDo:
MSのやつの日本版ってこんな感じだったのか
http://nlab.itmedia.co.jp/nl/articles/1603/27/news029.html
ルールベースの比率が高いやつをディープラーニング+クラウドのマーケティングに使うってのは別にまぁいいちゃいいと思うんだけど…と思いつつツイターの方見てみた
いやーこれが人間じゃないなら驚くレベルだな
ふーむ
(00:39)
という言葉を学んだ
元はこういう腐女子由来の単語なんだろう
http://yaraon-blog.com/archives/96652
これで知った
http://anond.hatelabo.jp/20170107124627
上2つはまあどうでも良いのだけど、色々見てて目に入った、2chの見栄張りレスまとめみたいなやつはすごく面白かった。こいうのだと微笑ましい
http://fesoku.net/archives/8698250.html
(17:48)
で1.5%のものが21枚以下しか出ない確率
https://twitter.com/kagewaza_uswest/status/816593363952508928
def comb(n, k) a = (n-k+1..n).inject(1, &:*) b = (1..k).inject(1, &:*) a / b end NUM_TRIALS = 2140 EXPECTED = Rational(15, 1000) NUM_SSRS_RANGE = (0 .. 21) a = 0 NUM_TRIALS.times do |n| next if !NUM_SSRS_RANGE.include?(n) a += comb(NUM_TRIALS, n) * EXPECTED ** n * (1 - EXPECTED) ** (NUM_TRIALS - n) end p a.to_f
結果
( '-') ruby comb.rb 0.024201451571321177
不正はないかなこれは。運悪いけど……
あと1000連で8枚て人は 0.03642752999168885 らしく、21枚の人の方が運が悪いといえるんだな。二人を足して確率計算するのは恣意的に選んだ2人なので議論がおかしいと思うけど、それでも 0.3% くらいでまぁ起きる程度か
(09:16)
ぱっと震源わからなかったけど、この人達か
https://twitter.com/kuenishi/with_replies
あまりなんという意見もないけど、とりあえず揉め事を見るのは楽しい
(13:23)
すごーく大変だというイメージだったのだけど、バックエンドが割と動いてきてて、俺もなかなかたいしたもんだなぁとか思う。あと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)
年末、クラウドさんがおかしな理由で復権した
あらすじ: 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)
世の中色々デバッグが大変なものというものがございますが
レジスタアロケーションやスタックへのメモリ割りつけはクッソ大変なものの一つだよなってことを
思い出しました
(13:08)
まず一般的に、そもそもデータを出力するプログラムのデバッグは大変。なぜなら、苦労しておかしいところをつきとめるまでは作業の序盤で、何故おかしな値を出したか、を調べなければならないからで、通常出力されたデータには出力した理由とかが不十分にしかあらわれていないことが多いから
レジスタアロケーションとかが何故余計大変かっていうと、アセンブリだからってのがあり。アセンブリっていうやつ、読む訓練を積んでいると読むの速くなっていくわけだけど、あれ何故速くなってるかというと、「こういうパターンの時はこういう操作をしている」というパターンマッチをひたすら行なう処理を良くしていってるから。
で、そのパターンマッチは出力されたコードは正しいことを前提にしてるから、すごく細かい、ここでBPからのオフセットが1つずれてる…みたいな処理は、本当見落とす。かといって脳内のパターンマッチルーチンを切った状態でアセンブリ読むのは慣れてないのだよなあ
(13:14)
http://yukilingo.hatenablog.com/entry/2016/12/25/235754
高校がまさにこういう物量教育で辟易してたなぁと思う。うちの高校の言う通りやってりゃ受かるとか自慢げに言ってたけど、んなもん言う通りやってたらそれやるだけで1,2浪するがなっていう
全部やってこいみたいな宿題出てたから、半年くらい遅れつつ答えを全部写経(どうせチェックされないので適度に飛ばしつつ)してたけど、あの時間無駄もいいところなんで、つまり受験の邪魔されてたんじゃないだろうか
(21:38)
という病にかかっているように思う。まあ病といっても悪影響は特にないが
開始地点は…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)
https://twitter.com/omo2009/status/808539204850315264
gflags好きっ子としてはね…というかglobal変数が好きというのがある。GLのアレとかTFのsessionとか、まあ悪くないという感がある。いやそれはあまり関係ないだろうけど
フラグの値をテストの冒頭で挿したりするの、あれはまあいいんじゃないかって感があるケースと、うーん微妙というケースがある気がする
なんかおおざっぱに言うと、フラグが使われるのがモジュール内の奥地で、モジュールのプライベートな関数とかが全部のそのフラグを引きまわすようなケース…これはまあテストの冒頭で挿す方がいいと感じる。なんていうか、テストが汚なくなることによって、プロダクションのコードが綺麗になるならいいじゃないか、的な
一方で、 func(FLAGS_hoge) みたいな感じで渡した引数が func の中だけで使われてないと、これはちょっと引数にして呼び出し側で定義した方がいいかなぁ…などと思うケースも多い気がする
まあでも基本ケースバイケースだと思うんだよなぁ。正直このへんの決定をどっちに倒しても生産性とかに大幅に差は出ないわけで、自分がチーム内で弱い立場なら他の人の決定に従い、強いならちょっと自分の趣味を主張してみる、みたいな、そのくらいでいい気がする。このレベルのことだと、ほげほげというアプローチがグッドプラクティスです、みたいに主張するのも、こう「それによって生まれる軋轢」>「統一によって得られる快適」みたいになる可能性もあるよなと思う
僕はこう一応、このレベルの話に関しては「あ、うん、僕はAの方が好きなんですけどね、まあBの主張もわかるんで…このプロジェクトはBで統一しましょう」みたいな対応をできてる……つもり……だといいな……ホントかな
(00:57)
本質的に書く流儀みたいなのがわれやすい感あるよね。
似たようなちょっと難しいテストケースを複数書く時とか、どうも同じコードをコピペしがちになって、それはよくないと共通部分をくくり出したりすると、それはそれで「テストはのっぺりとした入出力の羅列であるのが望ましい」みたいな感覚と矛盾したりして…
僕はこれについてはどっちかというとくくり出したいタイプかなぁと思う。基本同じロジックが2回以上目に入るのがあまり好きでないのだけど…テストだから小賢しい抽象化しないのが良い、みたいなのが理解できるケースも多いんだよな
まあ知らん系
(01:02)
どうもファンがムダにうっさいぽいので導入してみた。
/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)
前 | 2024年 11月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
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 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ morrita [概ね同意で、話の流れとしては https://talks.godoc.org/github.com/tcnksm/..]
_ shinh [はい、フラグのとこだけそのスライド読んでから書いたので、もりたさん同様、「良くない例なの?むしろグローバルがいいだろ..]