ToDo:
水曜から毎日飲んでて、しんどい…
水曜も予定があったぽいけどさすがにしんどいのでやめておこうと思った…
(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)
http://d.hatena.ne.jp/isshiki/20120821/p1
その通りだなあ…と思う。
僕の場合はむしろ既にあるもの使いこなせないからかわりのもの作ったケースも結構ある気がしていて、技術系じゃない知人とかに「ケータイよくわからん」「プログラム書けるのにまた冗談を」「いやこういうの使いこなせないから作る側にまわったんじゃないかな…」みたいなことをよく言ってる気がします。
関連研究
https://twitter.com/ksknac/status/233398630697037825
(07:15)
なんか1年に1度くらい april fool じゃないタイミングで april fool ネタに騙される。
今回はコレ。
http://www.infoworld.com/t/misadventures/oracle-sues-starbucks-over-java-trademark-176
オラクルがジャワティーフラペチーノだかなんだかでオラクルの商標を使ってるスターバックスを訴えた、っていう記事。一瞬商標ってジャンルごとに取る必要ある感じだよね…? とかいう疑問が浮かんだんだけど、そんなことより、なんとなくやりかねない感じがしてしまって綺麗に騙された。
なんかこれを見つけた理由が他でオラクルがスターバックスを訴えた、っていうネタを見て、ホンマかいな、とぐぐったらこの記事が出てきたっていう流れも悪かった…と信じたい。
しかしなんかプログラマと道歩いてたりすると、紅茶の Java はたまにネタになるし、やりかねん感といい、なんかいい感じのネタだなぁと思った。綺麗に騙されたからそう信じたいだけなのかもしれないけど…
(07:16)
なんか珍しく色々読んでる気がする。
盤上の夜。 @kinaba さんの tweet 見て面白そうだったので衝動買い。ちょうど発熱してたのもあり一気に読んだ面白かった。
https://twitter.com/kinaba/status/236463520093462530
https://twitter.com/kinaba/status/236463520093462530
コードの未来。だいたい半分くらい読んだのかな。 matz さんの文章ってまあまあ読んでる気がするんで、わりと知ってる話も多いんだけど、なんかこの人簡潔な説明うまいなーと思った。 go とか dart とかを、他の言語結構知ってる人でざっくり面白ポイント把握したい人にはいい気がする。言語の話じゃなくなると、こうなんか色々書いてて依然としてうまい説明だけど、まあちょっと面白さ減ってる気がしてきて、読むのが遅くなっていってる感じ。
ビューティフルコード。あまりしっかり読んでないけど、美ってやつは人によって感じるとこ違うなあっていう。これもまだ半分くらいしか読んでない気がする。
レッド1-6。いつか読みたいなーと思ってたけど、読む機会があんま無いので買った。まあもともと面白い話だから面白い。番号以外の工夫が無いので普通といえば普通…人の対応を取るのが大変なんで対応表とか作りはじめた…
ありがとうコンビニ再販の全2冊。山本直樹の今までのやつって、どれ読んだかわからんなーと思いつつ、読んでなさげだったので読んだ。なんかまあ面白かったとしか言えない感じの。
あとは同僚の奥さんがマンガ家だっていうことでイヤがらせを兼ねてそれを読んだり。
(00:56)
上がってた。
http://www.youtube.com/watch?v=fEkz-7dS-c0
これはなんかこれしなきゃもうちょっと勝負になった気がするから、ちょっと感じわるいな…
(02:33)
@hirose_golf さんが面白げなものを作っておられた
http://appotiud.appspot.com/anarchygame/
でまあ Circle Packing は自分がどんなコード書くか予想できる感じなんで、 collatz 予想の方を考えてたけど、なんかみんな長いなって感じで、あまし追いつけそうな気がしないね…
http://appotiud.appspot.com/anarchygame/p.py?problem!341096573325343693
これを会社の人に説明してて、なんかみんな普通に collatz 予想とか知ってて感心した。僕が collatz 予想を知ったというかそれまでも聞いたことあったかもだけど、覚えたのって、たぶんコレで、たまたま目に入ってたから知ってただけにすぎない気がするんだけど、習ったりする知識じゃないよねたぶん…
http://ll.jus.or.jp/2006/blog/doukaku2/
このどう書く見てて思い出したんだけど、なんか当時色んな言語、特に自分が好きな言語を紹介する感じでみんながこれをたどってくプログラム書いてたと思う。こういう自明な問題を色んな言語で解いても全然つまらないっていうか、似たりよったりの結果しか出ないわけで、むしろ長い collatz 予想のシーケンスを探しましょーっていう今回みたいなやつの方が言語の宣伝とかにはなりそうだなぁとか思った。
わかりやすいところではとりあえず bignum ないとしんどいとか。
(13:05)
あいかわらずいい金の使いかたしてるよなあ。
http://www.abc.net.au/news/2012-08-15/bill-gates-on-quest-to-reinvent-the-toilet/4199962
と思ったらこんな話が
http://tamekiyo.com/documents/W_Engdahl/gates.php
でもこれ今回下水にも使いはじめたんじゃってのと、そもそも文章が陰謀論ぽいなあということで
http://www44.atwiki.jp/cervarix/pages/98.html?guid=on
も見つけた。根拠はないけどビルゲイツはこのへんの意味で悪役なキャラじゃないと思うんだよな…
(14:48)
なにやら gg が多い。
一番やばいと思ったのは MC の 4 carrier all in...
http://www.youtube.com/watch?v=fCSQ9eK5mog
あと Z が marine を作るという事件が起きたらしいけど、寝てた。
http://www.reddit.com/r/starcraft/comments/yfrno/slivko_makes_a_command_center_with_neural/
これ見てるとこの人前科があるらしく、なんだこれ… probe が hatch にミネラル運んでる
http://www.youtube.com/watch?v=jlDg9KFdj84
(15:45)
プログラムマンガがあっていいだろうみたいな話をよく聞いて、その通りだと思うんだけど、既存のよくできたマンガでプログラム化するとどうなるだろうとか考えた。
デスノート。このノートに書かれたプログラムは指定された通りに死ぬ。死因を指定しなかった場合は SEGV する。
だけ考えてあんまり面白くならなかった… VC6 IE6 procmail などと書いてあるデスノートをばっとリュークに見せるライトを想像しましたね…
(01:15)
今回のプロシンのテーマであるということで、件の本を買って半分くらい読んでみたり、あれこれ考えてみたりしたけど、あんまりコレだってのが無いよなぁとか思った。あまり悲観的なわけじゃなくて、割と神は細部に宿る的な話があるのかなぁとか純朴に思ってたりする。自分が書いたコードですごくコレだーてのもあんま思いつかんけど、書いてる最中は、あ、俺にしては綺麗におさまってるな、みたいなこともたまにはある気がする。具体例全く思い出せないってことは、たいしたことないわけだけど。
綺麗におさまってる系で言うと、圧縮系のコードとかって、なんか全然メモリ使わんで綺麗に書けてるなーとか思うことが多い気がする。まーあたりまえちゃあたりまえなんだけど、ハフマン木みたいな二分木を1次元配列に作ってく時のコードとか、ちょっといいよね。
あとは kinaba さんがどっかで書いてた気がするけど quick sort かなぁ。僕は自分で C で quick sort 書いてみた時に、 glibc のやつが妙に速いなあと思って、その時は int 決め打ちなコード書いて速度負けてたんで、 glibc すごすぎねーとか思ってコード読んで、 inplace な quick sort ってこういうもんなのか、と知ったんで、そういうバイアスもある気がする。
コード読んでて感心したのは TCC とかのするっと C が機械語に落ちるさまとかもあるんだけど、あれって C の歴史考えるときっと昔は当たり前だったんだよな…とか。
(01:49)
http://itpro.nikkeibp.co.jp/article/NEWS/20120815/416081/?SS=imgview&FD=-2096679071&ST=system
なんかこういうのってもちょいなんとかならんのかね。21世紀なんだし…
(17:05)
前 | 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。