ToDo:
http://icfpcontest2012.wordpress.com/2012/09/11/winners-announced/
でたらしい。
動画: http://www.youtube.com/watch?v=5TCqUU3-GT0
Judge's prize 取れなかったけど honourable mentions (イギリススペル!) の一人だったようだ。まぁ発表で紹介されてたから良いとしよう。
ちなみにアホほどビール飲んだ人が Judge's prize らしい。たしかに 44 リットル / 6人日 はすごいな…
(12:16)
というゲームがあることを知った。
でそのせいで、その派生で使われてるらしいこの曲が思い出せなくて寝れない
http://www.youtube.com/watch?v=RYO3fIc4xk0
思い出せない理由がない気がするんだけどな…
(06:08)
僕の記憶がスクエアのアクションゲームで聖剣だと言ってるけど、聖剣だとすると2しかこの音は無い感じで2はたぶん全部戦闘曲思い出せる気がするから違っていて、スクエアのアクションゲームってあとフロントミッションとトバルくらいしか思いつかんが、どっちも思い出せない理由がない気がするようなゲームじゃない…
根本的に僕の記憶が全部間違ってる気がする
(06:31)
「AB-AC-BC イヤじゃないですか」みたいな会話をするわけだけど、実際ふってきてるのは赤とか緑なので、最初の方に多く降ってきたものから順に ABCD …と割り当てていかないといけない。これって人間は一瞬でやる気がするけど、実装するのは実は結構めんどくさくないですか…こう可能性を削っていくみたいな。みたいな話をしてたら、つまりユニフィケーションですよねと言われた。なるほど。
んで C++ で書いてみたら 130 行くらいになった。やはりそれなりに面倒な気がする…そして全然綺麗に書けてる感じがしないな。
(06:08)
よく考えるともっとラクそうな方法があるような。
最初に出てきたのが AA だったら A 確定。 AB だったら次を読んでいって、 AB 以外で A か B が出てくるのが先に出てきた方が A でそうじゃない方が B 。
こっちの方がどう考えても短くなりそうだ…
(06:18)
はなんだろうとかいう話をした。
正直よくわからんなっていう感じだった。1990年代とかに比べてたいしたことが起きてない気がするんだけど、すごいことが起きてても評価されるのに一定の時間がかかるとかで、単に物を知らんだけかもしれない…
(01:01)
水曜から毎日飲んでて、しんどい…
水曜も予定があったぽいけどさすがにしんどいのでやめておこうと思った…
(23:57)
http://golf.shinh.org/p.rb?Hello+broken+keyboard
文字種ゴルフ問題を増やしてみた。 hello だと自明な答えばっかになるのかなぁ…と思っていたけど、全然わからんものばかりな気がする…週末マジメに考えるか。
「文字種ゴルフ」って英語で簡潔に表現しにくい気がした (というか character とか alphabet とか長いよね…というのもあり) ので、わかりにくいけど壊れたキーボード使ってるという謎設定になった
(00:10)
http://www.reddit.com/r/IAmA/comments/z1c9z/i_am_barack_obama_president_of_the_united_states/
hoe-
(05:45)
プロシン前半は NaCl とたわむれながら話を聞いていた。
竹内先生はテーマがテーマだけに、いつも以上に良い意味でヨタ話としか言えないような。面白いヨタ話できるのはいいことだなぁと思う。
エラー話はエラーに他のコードが混じってくると型とかややこしいことになる気がするんだけどなぁ…と思ったんだけど、後で雑談で他の人に聞いたり、本人に質問したところ、僕の Haskell レベルが解答の意味がわかるレベルに達してないということがわかった。 Haskell ちゃんと勉強しないと話についていけないな…
指針はこう、唯一ビューティフルに真っ向勝負という感じで、しかし真っ向勝負するとええそうですよねーというだけという感が。あとああいう話ってプラクティカルな感じがあまりしないような。発表じゃないけど、関数が長くなるなんてことはありえない、っていう質問は、複数人開発してると自然と長くなる気がするけどな…とそいう意味であまりプラクティカルでない気もした。片方が短い if else はさっさと if continue すると良い、っていうのは webkit とかでもなんとなくそんなルールがしかれてたりする。まぁ良いと思う。
Ruby がこう、 Quine はまぁやればできる感じなんだけど、小文字しばりは個人的にすごいヒットだった。と言ってもすぐにこれはすげーと思った感じではなくて、自分で説明されてるテクニックを書き写してみてはじめてすげーと気付いた感じだったんだけど。
このへんで NaCl でハマってたので、 Ruby いじりにスイッチした。 1.9 では String#each が存在してなくて助かった、ってのと rescue ensure による値の一時退避は、どっちも大変素晴らしいテクニックだと思う。 1.8 でなんとかならんか…ってのと rescue ensure が直感的に一つで良いのではないか…ってのはずっと考えてるけど今のところ思いついていない。ゴルフ場の Quine のところにぜひ欲しい解答なんだけど、 1.8 とサイズの両方がネックになる感じ。 1.8 さえなんとかなればサイズはなんとでもなる気がするんだけどね…
x86/64 は str 命令相変わらずすごいなって感じだったけど、まぁ正直 Ruby のこと考えすぎてて途中ついてけてなかった感が。
ビスケットはかっこよかった。なにか色んなことを考えさせられる感じの。いよいよビューティフルかどうかは知らないけど…近いものとしてはメイドイン俺なんだろうけど、あれよりシンプルにできてる気がしたなぁ。任天堂から出せば良いんじゃ。 http://www.viscuit.com/
kinaba さんの話はあいかわらず面白かった。面白いもの見た時に、すぐに自分で今度使ってみよう…となりにくいのは反省しないとなぁと思わされた。1個目と3個目はたぶん見たことある感じの話で、2個目はなるほどこういうことするのかと。
@_ko1 さんが twitter に functional data structure が何故重要か聞いてわかった、とか書いてて、それはどういう話だったんですか、と今日聞いたら、 map とかだと変数テーブルみたいなやつがスコープ出る時にスタック巻戻せば自動的に元の変数テーブルに戻るとか言ってて、なるほどなぁと感心した。 node を reference count してやれば C++ でも同じもの実現できる？と質問したら yes とのこと。 parent ポインタいらなくなるからメモリ消費も安い、とのこと。でももう少し議論しててスコープ出る時に map 全部なめて reference count 減らさないといけないかな…という話になってダメっぽい気がした。なんかまた考えるとなんとかならんのかな…という感もあるんだけど。あと queue は別に実用性は無いとのこと。
和田先生の話は、この人いつもゴルフの話に聞こえるな…と思ってました。結論がゴルファー向けのアドバイスとして秀逸。
全体的に話が詰め込みすぎに感じるのは、やはりこういうテーマだとみんな語ることが多すぎるんかな…とか思った。
僕が美的なものを感じるのは…と考えていくと、だいたい
http://shinh.skr.jp/slide/mederu/000.html
に書いたな…とか思いました。
あと、久野先生的な意味でないビューティフルはたいていトリッキーなコードと紙一重なのが多くて、例えば free list とかかっこいいけど、久野先生的な意味ではかなりダメだよね…とか。まぁなんかトリッキーなコードは避けた方がいいと言うのはそうなんだろうけど、こう重要なとこで光るのはかっこいいよね…
あと、 STM はこう議論というか、実装のタイプが僕の中で整理できてなくて、相手と前提を共有するのにいつも時間かかってよくないな…と思う。 Haskell もそうなんだけど、自分があんま信用してない技術だけに、時間かけて勉強する気があまり起きなくて困る…
(01:35)
とりあえず mame さん的なやりかたで hello は ruby 1.8 でできたけど…
http://shinh.skr.jp/dat_dir/downcase_hello.rb
(03:15)
入ったらしいからぱらぱら読んでた。コメントが直感的にこれでいいのかな、って感じ。
b0 b1 がタグ、 b2 が sign bit 、 b63 が 1 なら exponent の先頭が 011 で 0 なら 100 、ってエンコードか。コメントに sign bit が書いてないから混乱したっぽい。
exponent の値域が +-256 くらいで、これが 10 進数だとざっくり +-77 と。
これ rotate とかやるより手で書いた方が速くね…と思ったけど速くならなかった。アセンブリ見ないとなんとも言えないけど。
見た。 rot の方が短い。 gcc ちゃんと rot を検知してくれるんだなえらい…
(08:58)
あと
t.v = RUBY_BIT_ROTR(2 - b63 | (v & ~0x03), 3);
の方が速くね? と思った。実際短くなるし、ほんの少しはやくなってるような
(09:04)
いかにも & 0x7 がいらない
bits = (int)((VALUE)(t.v >> 60)); /* bits contains 3 bits of b62..b60. */ /* bits - 3 = */ /* b011 -> b000 */ /* b100 -> b001 */
if (t.v != 0x3000000000000000 /* 1.72723e-77 */ &&
!((bits-3) & 6)) {
return (RUBY_BIT_ROTL(t.v, 3) & ~(VALUE)0x01) | 0x02;
}
どっちも動作確認してないけど…
(10:31)
via https://twitter.com/otsune/status/239359956174913537
こういうの見ると、みんな人狼やればいいよと思いますね…
ウソついて信じてもらうのがどれだけ難しいかってこと、信用される人がどういう挙動をしているかということ、真実を言ってたとしても信じられない挙動が存在すること、などなど、いろいろ学べると思うんだ…あとウソを信じられることはそれはそれでしんどいこととか、正しいことを主張する時にもウソが便利な時すらあることとか…
この件がホントかウソかは知らんですが、なんにせよ全く信じてもらえない種類の言動をしていることは間違いないと思う。
(23:42)
| 前 | 2025年 7月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。