はじめてのにき

_ mlterm

なんかそれなりに需要あるのか…

http://garakuta.homelinux.org/~nosuke/diary/diary.html?y=2008&m=3&d=12&n=1#12-1

http://d.hatena.ne.jp/sasakyh/20080314

ちゃんとメモリ無駄使いしないようにいじって 今週末中に ML に投げ…れるといいかと思う。 たぶん 256 色系の命令来たら multi_ch[0] に fg_color と bg_color を詰め込んで multi_ch[1] に実体詰めこむとかでいいんだろうけど… でもね僕 combine される文字列とかよくわからんのだよね。 なんか右から読む文字列とかそんなんですかね。

というか

http://garakuta.homelinux.org/~nosuke/diary/diary.html?y=2008&m=3&d=11&n=1#11-1

が無ければ放棄してた気がするのでありがとうございます。

(01:16)

_ FSIJ

「Google SoC: 「夏休みコード道場」とかいうありえないほど
恥ずかしい名前になっていたものを 2,3 年前にやった」

引用個所はそこでいいんですか。

http://www.fsij.org/homepage/wiki/GSoC2008

(01:19)

_ わびさび

http://b.hatena.ne.jp/entry/http://shinh.skr.jp/m/?date=20080312%23p01

http://gusmachine.blog49.fc2.com/blog-entry-312.html

説明適当ですいませんという感じですが。

つまるところ gus さんがやってるような定義をして、 かつこれをラクに作れる notation があったとしたら、 それは実際のところ明示的に型推論を弱くしてることに他ならなくて、 gus さんの最初に言ってたリストのリストが 無意識に作れちゃう問題が復活してるよなーというような。

僕の言った「強い型があるとキツいよな」 というようなアレはそういうアレだったという。

一方 Python で型に厳しくするとかもできんわけではなくて、 例えば

def strict_list(t):
    class l(list):
        def append(self, v):
            if type(v) is not t:
                raise TypeError('%s expected, but comes %s' % (t, type(v)))
            list.append(self, v)
    return l

l = strict_list(int)()
l.append(3)
l.append([3,4])  # TypeError will be thrown

こんな感じでやれば全然 Python way って感じじゃないけど、 まぁ。 でもこいうのがあるのはあるのでいいのかもね。 さらにこれ専用で最適化とかかかるとすばらしい。

(01:36)

_ shiro さんに

サインもらたー

Programming Gauche にももらっていたんだけど、 もらうべきはこっちだと気付いた俺は神。

(01:41)

_ はかー

http://homepage1.nifty.com/herumi/diary/latest.html#14

東京であったら行くな…

(01:52)

_ しあわせの理由

面白かった。 やっぱイーガンは短編の方が好みなのかもな。

なんか狂信的キリスト教者がエイズウィルスからインスパイアされて 二人以上の異性か同性と性交したら死ぬウィルスみたいなのを 作ってばらまいて、これで世界は清くなる、みたいなのがあったんだけど、 普通に他人の飲み物に自分の血を混ぜるだけで 殺せるとかはやばいんじゃないかなーとか思った。

(17:25)

_ duck

http://gusmachine.blog49.fc2.com/blog-entry-311.html

なるほど。

でも一方で tree がさっくり作れる、 っていうメリットと見ることもできるって話か。 わびさび記法とか強い型あると結構大変そうだしな。

(16:18)

_ willty

http://pc11.2ch.net/test/read.cgi/tech/1191860116/

で見た willty ってソフトがすごいみたいだ。

http://itpro.nikkeibp.co.jp/article/NEWS/20070223/263149/

なんか電子の不審な動きを察知して コンセントからの情報漏洩を防ぐとか。

しかしこれが何故ダメであるかを 両親に説明できる自信は無いので難しい

(21:41)

_ bk

http://twitter.com/alohakun/statuses/769209497

将来研究することが前提ならわからないけど、 会社とかなら真逆の意見だな。

bk 超重要。

(00:13)

_ mlterm 256

適当に 256 色化してみたけどなんか微妙だな…

まぁ一応完成させてから放置しよう…

(01:36)

_ じゃあ

natsutan さんも

http://twitter.com/natsutan/statuses/769366466

(12:53)

_ GDC

来たのでコンパイルした。 closure がうまいこと実装できんくて あれこれしてる間に david さんが降臨してしまったのであった。 後で実装読もう。 とりあえず TupleExpr は空 tuple 忘れてたのか。

でまぁ当初の目的である tarai ですよ。

> time ./tarai  # DMD
1220
./tarai  1.20s user 0.04s system 99% cpu 1.250 total
> time ./a.out  # GDC
1220
./a.out  0.61s user 0.00s system 96% cpu 0.638 total

ううむやはり GDC の方が速かった。

(13:03)

_ む

ed があまりに素晴らしいから訳そうかとしてたら 既にあることに気付いた

http://www.unixuser.org/~euske/offline/memo/2001/3.html

If you are an idiot, you should use Emacs.
If you are an Emacs, you should not be vi.

ここだけよくわからんのだよな。 2文目は ed >>>>>>>>>>> emacs >>>>>>> vi という論調で 「お前が Emacs なら、 vi にだけはなってくれるな」 って感じなのかなーと思ったんだけど全然しっくりこない

あとその後は

いわゆる「ビヅュアル」エディタは 不実への誘惑をもたらすために ED の前にあるのです。

とかなのかなーと思ったんだけど自信はなす。

(00:25)

_ ed

コード短い…!

http://www.gnu.org/fun/jokes/ed.html

(00:35)

_ hoge

http://d.hatena.ne.jp/masa_edw/20080310/1205121122

たぶんあの時はオセロのこと考えてたから SDL はこうなんか喋ってるなーとは思ってたけど そんなにうずうずはしてなかったかもしれない。

away なとこ行って特に話す相手いない時は、 寂しくない処世術として たいてい他のこと考えながら回りの話を 漠然と全部聞くことになってます。

http://d.hatena.ne.jp/hogelog/20080309/p1

ぶった切りは確かに好きだなーと思います。 あんまり自信ないことでも適当なこと言っておいて、 アタリハズレはっきりさせることによって物覚えるというか。 間違える時は壮大に間違える方が良いという処世術。

(23:08)

_ ああでも

特定の文脈で言うなら、 俺も昔はそうだった系の話は議論をする系の人は お話にならないので 何を言われても反論したくなるというだけかもしれない。

まぁその手の話がしたくなる気持ちはわからんでもないけど、 全く説得力が無いのに反論はできない どうしようもない種類の議論だからなー。 せめて何故今は考えを変えたか言ってくれればなんとかなるだろうか。

あと僕は個人的に俺も昔はそうだった系の話を 後になって納得したことが無い気がする。 死ぬまでガキの発想でいいじゃんね。

(23:20)

_ ato

もう一つ思い出したけど自動再接続欲しい気がするから mirc.nb 使ってみようかと考えてたんだった。

(23:21)

_ 部屋

俺の部屋が汚ないのは熱力学第二法則のせいだということにすれば 広い心で受け入れられると気付いた

(18:40)

_ +=

http://arton.no-ip.info/diary/20080309.html#p05

は後者じゃないかなと思った。

irb(main):006:0> str='hoge'; ref=str; str+='hige'; ref
=> "hoge"
irb(main):007:0> str='hoge'; ref=str; str<<'hige'; ref
=> "hogehige"

ゴルフ的には

irb(main):013:0> $*+=['hoge']
NameError: $* is a read-only variable
        from (irb):13
        from :0
irb(main):014:0> $*<<'hoge'
=> ["hoge"]

などでおなじみ。

(18:57)

_ ぶろくす

http://hp.vector.co.jp/authors/VA003988/gpcc/gpcc08.htm

今年もやるらしいと教えてもらった。

(21:46)

_ ed - the standard editor

http://www.gnu.org/fun/jokes/ed.msg.html

会社で教えてもらったんだけど、 何度読み返しても面白いなー

(23:43)

_ DelegateExp

見てたんだけど、なんかどう見てもこれ違うなーと思ったらやはり FuncExp の方見るべきみたいだった。

(15:38)

_ なんか

こう体調わるいね。 早起きと規則正しい生活は健康を損ねるという人体実験

(20:58)

_ しょぼーん

250をたっぷり時間かけて解いて 相変わらず500時間切れとかいう状態な上に challenge しっぱいした。

(22:37)

_ むー

無茶苦茶なコードだったというか 問題の制約見落としてて えらいややこしいコード書いた割には イマイチ自信が無いという状態だったので、 250も落ちてると思ってたけど通ってた。

にんとも…

(22:53)

_ オートペディア

おもしろいなー

via http://d.hatena.ne.jp/dropdb/20080306/1204800742

http://crocro.com/auto_pedia/?nm0=%C9%CD%C3%CF&nm1=%BF%B5%B0%EC%CF%BA&nm_fms=&q=

浜地慎一郎は佐藤祐介や鵜飼文敏について多くの洞察を示しており

らしい。

洞察しないと!

(23:52)

_ haskell

http://kurusugawa.jp/blog/archives/528/

初めて Haskell 書いたと Lingr で見たので 初 Haskell で Haskell 書いたのかとびびってたのだけど 初 Haskell をコンパイルしたってことだった。 なるほど。

にしてもこうなんか計画的に進めてる感じがプロっぽいな…

(08:32)

_ リスコフ

の置換原則ってヤツは 通常の名前重複は禁止&& ダイヤの時はおけ、っていうルールにしたら いいんじゃないのかなと思ってたんだけど違うのかな。

http://d.hatena.ne.jp/m-hiyama/20080304/1204615775

(08:51)

_ 相変わらず

スコア読めん、っていうか まともなアルゴリズム書く時間がないのがだるいな…

http://www.topcoder.com/longcontest/?module=ViewStandings&rd=11136

(08:54)

_ まらそん

なんかアルゴリズムいじるより 単にパラメータいじる方が得点増えるというのはなかなか萎えますね。 ていうか timeout してるぽかったから 探索しすぎてる場合は脱出するように、とか仕込んだんだけど それ外したら点数増えた。 まぁ高速化したのが効いたのか…

(23:11)

_ まぁそんなことより

働きすぎですよ。 そして別に仕事が進んでるわけではない。 たぶん体調悪いからだ。 極めてよくない。

(23:12)

_ GHC

速いな! 見直したよ。

GHC:

./a.out  0.02s user 0.00s system 100% cpu 0.024 total

俺コンパイラ:

./tarai  1.11s user 0.00s system 98% cpu 1.133 total

tarai 1220 520 100 にて

(01:14)

_ む

GDC のクロージャの扱いがおかしい気がする。 なんとなくスタックフレームが GC されてるとか そんな感じな気がするけどすぐにはわからない

ん。あーこの GDC はそもそも real closure 入ってるバージョン以前か…

(01:39)

_ あへー

たぶん全然違ってるなぁ…

http://pc11.2ch.net/test/read.cgi/tech/1202623572/509

うーん。 まず一応じゃなくて立派にチューリング完全じゃないかなぁ。 CCNOT で即座に NAND 作れるよね。

可逆性については古典コンピュータの演算ってたぶん 全部可逆なんじゃないかなぁ。 たぶんそのへんは真逆というか。

あと任意のユニタリ変換とかいうヤツができるんで よろしこというか NOT と CNOT と CCNOT と SWAP って 全部 CCNOT で即座に作れるんじゃないの。 (CCNOT の入力を A,B,C として A = B = 1 で NOT, A=1 で CNOT, CNOT*3 で SWAP)

そっからは微妙にたぶん正しくて、 こうなんていうか量子コンピュータ屋が 「量子コンピュータ」と言う時に意味するものと 量子コンピュータって単語聞いた時の語感がたぶんズレてるんじゃないかな。 単に量子的なふるまいをするものを構成要素として コンピュータ作ってもそれは量子コンピュータとは呼ばないし、 つまり量子的なふるまいをするものを使って (量子は単に工学的な意味で色々扱いにくい特徴があるので大変だろうけど) 普通の古典コンピュータを作ることは全然できるし。

んで量子コンピュータ屋が量子計算って言う時は、 量子的なふるまいをうまく利用して高速に計算をすることを指しているので、 「量子コンピュータは速い、すごい」なんてのは まぁほとんど定義みたいなもんと言っていいんじゃないかなと思う。

だからまあ古典でできて量子コンピュータでできないことがある、 とかいう主張はこう C でできて C++ でできないことがある、 みたいな主張に近く感じられている。

でまぁ「その性質をフルに発揮する」ことを量子計算と呼んでるとして、 その量子計算に古典コンピュータ用の言語が向いてない、 っていうのは非常に正しいと思う。 「アセンブリは並列計算に向いてない」みたいな感じだけど、 まぁもっと向いてない感じだと思えばそんなに間違ってないと思う。

量子計算がどんなもんかを想像するのは 分子計算とかを知るとイメージが捕みやすい気がする。 分子計算つーのは別に量子計算とはなんも関係ない 古典計算なんだけど、ただ並列度が半端ないとされている。 具体的にどうするかつーとランダムな DNA を大量に用意して、 ばらまく。 んで解答の条件に合致するとひっつく棒をつっこんで ふりまわして、ひっついてきた DNA を見れば解答が判明するというもの。 たぶん性質上解答の成否が確認できないといけないので NP までが解ける感じじゃないかな。 ただアボガドロ数とかって案外少ないので 解空間の DNA を全部作るのが困難な感じの、 ものごっつい複雑な問題は解けないよねーという。

量子計算も同じ感じで答え候補をぐわーと作るってのは同じなんだけど、 作る場所がこうよくわからんくて、 重ねあわせとかいうものでもにょーんと作るってのが違うところ。 多世界解釈とかいうアレだ。

違いはというと、 量子ビットの数 N に対して 2^N とかで解候補を 用意できるから難しい問題に余裕でスケールするってのがメリットで、 2^N 個の解候補を全部なめるようなことは 大人の事情でできなくて、 2^N 個になんらかの演算かました後に、 正しいものだけひきずり出してくるような とても賢いアルゴリズムを考えないといけないというのがデメリット。 このデメリットは案外重要で、現在まででアルゴリズムは えらいちょっとしか見つかってない。 あともう一つのデカいデメリットは量子ビットを たくさん使うのはえらい大変でこう10qubitとかできたら すげーみたいな感じだとかそんな話で、 まぁ正直できそうもないんじゃないかというような。 あとエラーがたくさん起きるので エラーコレクションしなきゃいけないんだけど 1qubit に 7qubit で EC するとかアリエネーというか。

そいや SIGGRAPH のやつみないと。

(22:25)

_ 日本語

http://d.hatena.ne.jp/mr_konn/20080304/1204632557

http://d.hatena.ne.jp/sumim/20080303/p1

を見て、んじゃ mecab で分解すればいいじゃなーいと思ったんだけど、 そういえば Io の UTF8 対応は色々と腐っているのであったと断念した。

Number の := method(
  write(self)
)
100の平方根の逆数を表示する

で 100 とか出ちゃダメだろう!

Io における正しい DSL のありかたとしては 以下のようなものがあるとは思う。

Number k := method(*1024)
Number M := method(k k)
Number G := method(k M)
write(1G,"\n")

(23:11)

_ 何が起きてるのか

http://www.topcoder.com/longcontest/?module=ViewStandings&rd=11136

読めん。 timeout してるんじゃないか疑惑があって困る。

53.41てんだった時はexampleの方は22.08てんで だいたい30問あるんじゃないかなというペースだったんだけど、 今は25問程度が想定される比になってる。

(08:08)

_ しょぼーん

問題文にボードサイズ書いてあるじゃんねー。

それに従うと30回テスト行われてるのね。 それなら手元の example に対するスコアと単純な比を取れば 67てんくらいあるはずなんだけど全然そんなにない。

つまりこれ example のは弱く作ってあるとかなのかな。

(23:25)