はてなブックマーク

社会的に成功した人は、遺伝的に有利だったのか、環境が良かったのか、本人が頑張ったのか、犯罪を犯した人は、先天的になにかあったのか、教育や環境が悪かったのか、よくそういうことが気になります。ときどきその手のことを考えるヒントになりそうな本とかを読んでみたりしてたのですが、友人から教えてもらった本のおかげで、行動遺伝学というジャンルが、この手のトピックに科学的なアプローチで取り組んだりしているぽい、ということを知りました。というわけで、冬休みの自由課題的に色々読んだりしてみたので、なんか色々と書いてみます 結論から書いておくと、最初にあげたような疑問は、行動遺伝学を学ぶことによって完全に解決する、ということはなさそうです。ですが、いろいろわかっていることもある、考えるヒントになる、というあたりが収穫かな、と思っています 読んだもの Introduction to Human Behaviora

開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク

20%ルールという仕組みの雑談になって色々考えていたことを思い出しました。 僕はこう、20%ルールがあまり好きじゃない。まず、時間が細切れになって効率が悪い問題というのがある。「20%ルールのおかげでイノベーティブなプロダクトが生まれた」というのは、イノベーティブなアイデアにも関わらず100%の時間をそこに費やすことができなかった、ということなんじゃないか、と思ってしまう。1ヶ月で実現できたはずのアイデアに、単純計算で5ヶ月かかるわけで ここで、僕の好きじゃないスタイルの20%ルールは、金曜日は20%、他はメインのプロジェクト、というスタイルのやつに限定している 好きなスタイルとして、 http://shinh.hatenablog.com/entry/2016/03/11/142748 に書いた「半年メインプロジェクトに集中してた僕ですが、なんかやってみたいことができました、1ヶ月時間こ

シクシク素数列 Advent Calendar 2018 向けです。 ONNX はニューラルネットのモデルをエクスポートして、別の実装でインポートできたりする、相互運用のためのフォーマットです。複雑なモデルをサポートできるようにと、 Loop とか If とかがあるので、チューリング完全です。ただまあ実際にえぐい使われ方してる例は見たことがなかったので、やってみました。 https://github.com/shinh/test/blob/master/onnx_gen_4949_prime.py が、4か9を含む素数を出力する ONNX モデルを出力するプログラムで、 $ wget https://raw.githubusercontent.com/shinh/test/master/onnx_gen_4949_prime.py $ wget https://raw.githubuser

無職なこともあり、とても楽しい問題だったこともあり、久々にほぼガチで参加してる会になりました。いや楽しかった。順位表が凍結された段階での最終順位は2位で、1位は絶対に無理、その後にできた変更はしょうもないので、おそらく7位とかそのあたりの、5位強みたいなところに落ちついているのでないかと想像してます。暫定2位といっても特に良いところはなく、得点を決める式のおかげで、大幅なとりこぼしが無いだけで、推定1位のウナギに対して全順序がついて負けてる形のはずで、大変くやしい。が、まあ僕的には頑張ったとは思う。 初動 パーサやシミュレータを実装して、簡単なシングルスレッドAI、下から順に塗っていって、既にあるブロックとつながっていないところに置かざるを得なくなると、 Flip する、というものを Ruby で書く。デフォルトよりは大幅によくなることを確認して、いい問題だなあ……と思いつつ、寝る。 シミ

MJIT というのが Ruby に入ったのは聞いていて、すごいことするな、と思ってたんですが、実際に Ruby Kaigi で話を聞けて少し遊んでみたくなったのでした。そういえば https://turingcomplete.fm/5 の時に「MJITについてどう思うか聞いておいて下さい」とかリクエストしておいたのに聞いてくれなかったのであった。 https://k0kubun.hatenablog.com/entry/ruby26-jit すごいことするな、と思ったのはその手法で、 C 生成して dlopen という、よく雑談とかで言う話ではあるけど、実際広く使われる用途で使われたのは見たことが無かった(ICFPCとかでは見たことがある)ので、すごいなと。 一方で、 dlopen たくさんすると、いくつかの意味でオーバヘッドがかかると思われるため、あとでマイクロベンチに出ないところで大変

https://turingcomplete.fm/19#t=26:39 で僕のやったことに言及してくれて、「使ったスタックを消すなにかを浜地が作ったが、それは全く公開されていない」という趣旨の事が言われていました。でも実際のところなんか書いたけど、単に誰も興味を持たなかったというだけのことでした。 http://shinh.hatenablog.com/entry/20130728/1374990526 実際はclang pluginで、かつすごく適当にでっち上げただけで、効率は完全度外視だし正しく動いてるんだかもよくわからない、って感じでした。クラッシュはしなかったくらいの何か。当時の記述はすごい適当ぽいので、2点書いておきます。 当時のモチベーション 保守的GCが「やや病的なケースでポインタに見える整数値の参照先を残してしまう」てのはよく聞くわけですが、Rubyのバグかなんかで見たの

http://herumi.in.coocan.jp/diary/1804.html#13 を解いた時の話。光成さんは実験的に解かれたようだったんですが、割と理詰めで解けたので、思考過程をダンプしてみます。元のコードは int calc(int a, int b, int s) { const int Q = 1 << s, Q2 = Q * 2, Q3 = Q * 3; assert(0 <= s && s <= 16 && && 0 <= b && b < a && a < Q * 4); int n = 0; for (;;) { if (a < Q2) { // A n = n * 2; } else if (b >= Q2) { // B n = n * 2 + 1; a -= Q2; b -= Q2; } else if (b >= Q && a < Q3) { // C a

https://beta.atcoder.jp/contests/wn2017_1/standings むっちゃ僅差で2位。残念。この212点差がどのくらい僅差かというと、最後にいじってたところにもう2行変更を入れることを思いつけていれば、軽く2000点は差がついて勝ててたと思いますし、そうでなくても後30分もあれば実装できた細かいヘッダの圧縮で逆転できた量です。自分に悔しがる気持ちというのがこれほど残ってたのか、と驚くほど悔しいです。でも勉強になったし楽しかったです。 やったことを書きつつ、そもそも圧縮アルゴリズムについて、私としては感動的だった知見を得られたので、書いてみようかと思います。 今回のコンテストは、チャンネル1つの(RGBじゃなくてグレースケールだと思えば良い)画像を64枚を可逆圧縮するというものでした。その64枚の画像は同じ座標について光の波長と時間を変えて気象衛星が観測

https://connpass.com/event/64632/ すごく面白かった。最近こういう会に行って感心することは多いのだけど、しかしなんか書きたいと思うレベルになかなか来ない、まあそれなりに年喰ったしな、とか思ってたんですが。低レイヤとか、自分がある程度既に知ってるところの話を聞くのも楽しいけど、自分が最近勉強してて理解しはじめたことの話を見聞きする方が楽しいよねえということかと思いました。まさににわかほど語りたがる現象で、実際懇親会とかで間違ってること結構言ってそうな気がする。 ジャンルとして、他のCSのジャンルとかと違って、深層学習はとにかく論理的に確定できない話が多くて、あの論文はあやしいなあ、あれは説得力あるなあ、というような、口コミベースの情報が回してる面が、良くも悪くもあるのかなあ、という印象を持っています。 つーわけで口コミレベルの適当なことを、以下、書きます。(定

https://twitter.com/nalsh/status/869086098177146881 を見て、今ならどういうネタが書かれるかなぁとざっくり考えてみます。 perf @nlashさんに指摘されていた通り、perfは重要だと思うんですが、書かれていたperf_event_openはptraceなんか目じゃないくらい使いこなしがムズいと思うので、素直にperfそのまま使えって感が強い気がします ptrace PTRACE_SYSCALL以外はあまり変わってないと思うんですが、PTRACE_SYSCALLはPTRACE_O_TRACESECCOMPでやるとずいぶん速くなるのでオトク asan/tsan valgrindのbinary translationでのinstrumentationてのはカッコいいけど、普通に考えるとコンパイラに手を入れる方が常識的ですよね……という EL

だいぶ前に左右反転させてもだいたい同じに見えるコードを書いたのですが、もうちょっと進化させて、上下反転と、180度回転してもだいたい同じように見えるコードを書いてみました。 デモサイト: http://shinh.skr.jp/obf/very_symmetric_js.html コード: https://github.com/shinh/hack/blob/master/very_symmetric_js/very_symmetric.js 普通のJS記号ゴルフと比べるとクォートが無いのが多少めんどくさく、あとは左右は一行コメントがあるから簡単なんですが、上下反転と180度回転のコードをコメントですっとばすのがパズルという感じでした。何も考えずに実行するコードの最後に /* と入れただけだと、180度回転した部分に */ が現れてしまってコメントが終わってしまうという。

オレオレワークフローエンジン作りたくなる病というのがあって、例えば make 系なんかだと Wikipediaに色々書いてあったりします。ワークフローエンジンと総称するのが正しいのか知りませんが、依存グラフを順ぐりに並列に実行していくようなもの、色々あるわけですけど、目的も粒度もバラバラですが以下のようなものは割と似たようなものに見えてます。 thread pool Tensorflow make Digdag 閑話休題。なんか微妙に10秒程度待ち時間があるような処理があって(クラウドストレージに対する例えば ls とか)、その ls の結果全てに対してまた10秒程度時間がかかるコマンドをまとめて実行、終わったら結果を集計、みたいなことをしたりすることが最近多いです。1週間から1ヶ月ほど10回とか100回使うんだけど、でもそのうち捨てる系のコード。私の場合、よくやる解決と問題点は shel

最近、 tanlog というのを作って使っていて、割と便利なので紹介してみます。 https://github.com/shinh/test/blob/master/tanlog.rb 元々は同僚と、なんか端末に出たもの前もって lv とか tee に入れておくのって、忘れることあるし、 lv とか tee に流すと isatty が false になって色出ないのうざいよねえ…みたいな話をしてたように思います。 grep については fake_isatty とか作ったりしたんですが、この時 soda さんに仮想端末作ってやる方法があると教えてもらったのを思い出して、 script とかで記録しておいたら…とか話していました。 結果、その同僚は zenlog というのを作って便利になった、とか言ってたのですが、なんか Perl と bash 混じってるとか、コマンドの切れ目をプロンプトで教

はじめに 言語実装 Advent Calendar 2016 用です。 ELVMは、コンパイラをフロントエンドと中間言語とバックエンドにわけて、多言語多CPUに対応しよう……というようなLLVMの考え方を、パロディと言っていいレベルにまで単純化したものです。結果として実用性は全くないが、C言語から他言語へのトランスレータを極めて簡単に書け、 Brainfuck などのような難しい言語のコードもC言語を書くだけで生成できる、というようなことを主目的としています。 本当は ELVM のバックエンドを一つ足して、 Brainfuck とかのような難しいターゲットでなければ、こういう感じで手軽に足せますよーということを書こうかと思っていました。しかし、ありがたいことにそういう趣旨だったり、あるいはもっと難しいターゲットについても、既にあれこれと書いていただいたのでした。例えば Perl: http

最近作ってたオモチャがだいたいまとまってきました。 https://github.com/shinh/elvm 第12回 kernel/vm 勉強会で発表した時のスライド: http://shinh.skr.jp/slide/elvm/000.html これは何かというと、前作った bflisp を改良したり整理したりしたもので、 C 言語をシンプルな中間言語 (EIR) に変換する改造 8cc と、その中間言語を Brainfuck をはじめとした他言語に変換するバックエンドから成り立っています。 bflisp との差分は、 Brainfuck 以外のバックエンドを追加しやすくしたり、バックエンドを C で書いて、完全に Brainfuck だけで 8cc.bf を再現することができるようにしたり、という感じです。 特に興味深いであろうバックエンドとしては、 Brainfuck, Unl

Ruby の正規表現だけで Brainfuck インタプリタを作ることができました。正規表現の実行は =~ だけなので、ループなども正規表現の内部で実行してます。 https://github.com/shinh/hack/blob/master/bf_rb_reg/bf.rb つまりどういうことができるかというと、 BF_REG という Regexp と BF_SUFFIX という文字列定数があって、 bf という文字列に格納された Brainfuck のコードを BF_REG =~ bf + BF_SUFFIX で実行することができます。出力は $~['o0'], $~['o1'], ... に入っているので、 output = '' 256.times do |i| o = $~["o#{i}"] break if !o output += o end 的なコードで取り出すことができ

すごい久々にイベントの(共同)主催的なことをしました http://connpass.com/event/34995/ イメージとしては言語雑談会的な感じで、closedに人集めてウダウダやるつもりだったんですが、途中でPFNさんに場所貸していただけるということで、不特定な人を呼ぶことになって、当初想定してたより大袈裟な会になりました。適当に募集すると人が集まって自己顕示欲が満たされるとか、普段得られない種類のフィードバックが得られたり交流ができる、てのがあるわけですが、めんどくさいのとグダグダ雑談がしにくいのが難点ですね。まあ自分自身が一般的に募集されてる会で勉強した面もあるわけで、そういうのの恩返しになるかもという面もあり、まあ色々。 まとめとしてはkoieさんのブログやtogetterがまとまってそう http://blog.livedoor.jp/hkoie/archives/55

https://github.com/shinh/bflisp/blob/master/8cc.bf Brainfuckで動くCコンパイラができました。このコンパイラ自身で同じコンパイラをコンパイルすることも可能です(ただし5時間以上かかる)。前回との差分はレジスタの幅とデータメモリ空間を24bitに広げたことと、いくつかバグをつぶしたことです。 これまでわざわざ手書きで書いていたBrainfuckのプログラムを、Cのコードから生成することでお手軽に作れるようになりました…とさ。 sizeof(int)==1 で 1byte==24bits だったりする変なアーキテクチャな上に、ビット演算とかがないですけど。

転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い

https://github.com/shinh/bflisp Lisp インタプリタを作りました。 Brainfuck で。 だいたい sedlisp や beflisp や makelisp と似たようなことができます。ちょっとバグあるみたいですが。 Malbolge は実装不能だと思うので、これ以上なくキツいターゲットじゃないかと思っています、ので Lisp シリーズはこれで最後でないかと。というか現世的な速度で動くとは思ってなかった。月なみですが、今のパソコン速いですねー。 実現は簡単な 16bit ハーバードアーキの CPU を定義して、魔改造した 8cc で lisp.c をその CPU のアセンブリにコンパイル、そのアセンブリなどから Brainfuck を生成、という感じになってます。実行は最適化機能つきの 8bit Brainfuck インプリタでやってます。ある程度最適

C言語 Advent Calendar 2015 - Qiita 向け 15年ほどC++書いてるんですが、どんどん自分の書くコードがbetter Cになっていっているような気がしています。どんどん先進性みたいなのが劣化している気がするので、特に高度なことは書かない…というか書けないです。 で、なんか C++ でも printf を使ってしまう傾向にあります。 cerr だと endl 書かないといけないのがめんどくさいけど自動で改行足すようなやつ作るのは少しめんどくさい フォーマット指定子が思い出せない という2点が主な理由かなあと思います。あとなんか % で書いてある方が出力が予想しやすいことが多いような気がするんですよね。特に括弧とかがたくさん登場する場合。 LOG("setenv(%s, %s)", name, value); LOG << "setenv(" << name <<

https://github.com/google/kati kati について、ドキュメント書こう…と思っていたのですがなかなか進まないので、とりあえず日本語で書いてみることにしました。何書くかがあまり明確じゃないテーマなので、何書くか考えるのと英語考えるのを両方同時にやるのが少し大変で。 動機 kati は GNU make のクローンです。いずれ完全なコンパチになると嬉しいですが、なかなか難しいだろうと個人的には諦めています。用途に対して実用的ならば良いかなと。 動機としては、 Android platform のビルドシステムが、なかなかシュールな GNU make 黒魔術で構成されていて、 make が実際になんかしはじめるまでが遅かったので、そこを高速化したいというものでした。 ビルドシステムが遅いという時、まずだいたいヌルビルドとフルビルドの2点を考えます。ヌルビルドてのは生

奇書を頂きました。 一応レビュアーとして参加したことになっています…が、掲示板かなにかと勘違いした人が雑談をして邪魔をしているな、という感じでした。浜地慎一郎という文字列が10回くらい出てくる残念な本です。 もう少しマジメに説明すると、私がクソコードとか読んでいるような、トリッキーなコードの作品集兼使われているテクニックの解説などがなされています。読んでいてこの本面白いなーと思ったのは、関連する他の人が書いたコードも紹介されていますが、基本的に遠藤さんの作品が主人公ということでした。えっこの人本一冊書けるくらい Quine 書いてるんだ…という。 それと、クソコードコンテスト for Ruby であるところの、 TRICK 2015 が開催されますので、みなさん頑張ってクソコードを書いて、審査員をうならせて下さい。 https://github.com/tric/trick2015/blo

https://github.com/shinh/makelisp Lisp インタプリタを書きました。 GNU make で。 https://github.com/shinh/makelisp/blob/master/makelisp.mk もちろん $(shell) や $(guile) は使わない縛りです。 だいたい sedlisp や beflisp と似たようなことができます。 最近作ってる GNU make clone であるところの kati でもちゃんと動きます。というか fizzbuzz.l とかだと 50 倍以上速い。 実装はまあ、やるだけ…と言いたいところですが、加減乗除が無いとか、文字列演算も色々不便とかあったりはします。あと地味に引数以外にローカル変数が無いのもだるいですね。当初は lisp to make translator を実装する感じがラクかな…と思っ