はじめてのにき

_ 寝て起きて

割とびっくりしたね。 そいやスライド作ってない上に やる予定だった仕事もやってないなーと。

まぁもちろんそんなことに驚く僕様ではなく、 なんかベストなタイミングで起床した自分に驚いたのであった。

いやあ良かった

(08:43)

_ 続き

やるとしたら、

• 多相関数とかをちゃんとつくる。 SKK くらいは動くと良い。
• カリー化。まぁこれはすぐに作れると思う。
• IO で入力ができるように。
• リスト。

(01:29)

_ khc

いなばさんすごいなー。

あでも tarai は 122 52 10 では圧勝してるな。

(01:40)

_ まらそん

http://www.topcoder.com/contest/problem/MultiplayerReversi/vis.html

(12:15)

_ ひさびさに

チャンピオンとか見たらすごかった。 烈海王が喰われてた。

(15:05)

_ 昨日のできごと

• うわー俺 Haskell わかってねー
• (?-?)?
• なんか >> が正しいぞ?
• http://www.kmonos.net/wlog/83.html#_2255080301

よかった。

(15:41)

_ 何が起きてるのか

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)

_ 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)

_ 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)

_ なんか

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

(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)

_ DelegateExp

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

(15:38)

_ 部屋

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

(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)

_ む

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)

_ 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)

_ 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)

_ 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)

_ 四角い地球

http://fsokuvip.blog101.fc2.com/blog-entry-419.html

via http://d.hatena.ne.jp/niha/20080307#1204868032

山のてっぺんは地球中心から少し遠くて、 重力が少し弱い。 だから山のてっぺんはさらに中心から離れる傾向にあり、 次第に地球は四角くなっていくと予想されます。

いまいち

(17:35)

_ スケジューラ

今の発想は割とクソだったんじゃないかという 考えのもと書き直してみた。 二度目の書き直しであったけど ケースバイケースで良くなったり悪くなったり。 全体的に見るとちょっと良くなってそうだなぁ…

(01:00)

_ やった!

すごい適当に書き直したやつの方がはるかに点数いいぞ!

かなしいね☆

(01:05)

_ 24B

http://twitter.com/smly/statuses/773412912

やりかたはわかってたつもりだったんだけど、 なんか25Bになってしまっておかしいな。 もう少し考える必要がある

(01:50)

_ processor scheduling

なんか点数が大幅に落ちたのは タイムアウトのせいだろうと推測して 適当に高速化してみた。 strtol とか sprintf とかやっぱ遅いなー。

(17:23)

_ あーうー

オーバーフローか！と思ったけどあやしいかなぁ。

はてさてよくわからんなという一日であった。ゴミ。

(23:09)

_ ふう

やはしオーバーフローだった。 予想よりはるかにデカい問題がありえるんだな。

とりあえず修正したので良しとする。 今日の思いつきはほぼ全て役立たずだったな。

(00:16)

_ priority_queue

#include <vector>
#include <set>
#include <queue>
#include <iostream>
#include <iterator>
#include <algorithm>
#include <functional>
using namespace std;
int main() {
    cout << "vec\n";
    vector<int> v;
    v.push_back(3);
    v.push_back(2);
    v.push_back(4);
    sort(v.begin(), v.end());
    copy(v.begin(), v.end(), ostream_iterator<int>(cout, "\n"));

    cout << "set\n";
    set<int> s;
    s.insert(3);
    s.insert(2);
    s.insert(4);
    copy(s.begin(), s.end(), ostream_iterator<int>(cout, "\n"));

    cout << "pq\n";
    priority_queue<int> q;
    q.push(3);
    q.push(2);
    q.push(4);
    while (!q.empty()) {
        cout << q.top() << endl;
        q.pop();
    }
}

実行結果

vec
2
3
4
set
2
3
4
pq
4
3
2

わからんでもないけど、 priority_queue だけ逆か…

(00:34)

_ りすぷ

soiya

(defun delete-line (&optional arg)

 (interactive "P")
 (progn
   (kill-line arg)
   (pop kill-ring)
   (if (not (= (point) (save-excursion (end-of-buffer) (point))))
       (delete-char 1)
      )))

こういうかんじで emacs-lisp 書いてたら、 死ねとかアホとかいう趣旨のことを言われた。

なんか最後の ))) のは後ろのにひっつけないといけないらしい。

まぁその方が美的に良さそうかなぁとは同意できるんだけど、 書いてる最中に括弧閉じてテストしてみて うまく動いたら再開…とかやってる時に、 括弧の対応的に適切な場所探すのめどいじゃん とか思ったのだった。

それと同様なのかはわからんけど、 Python で if とかが並んだ後に 一気にネスト戻す時に、 どこまで空白消せばいいのかイマイチわからん。

(01:49)

_ ほえー

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

なんじゃこの圧倒的な差は

(01:42)

_ そうか

この圧差はたぶん全部でトップ取ってるってことか。 つまり100点なのね。 てことは 252518ms くらい無駄があるってことかな。 んーそんな僅差とは思えないから 全部トップってことじゃないのか。

(02:36)

_ そいや

海腹川背は極めて残念なことになってるみたいだね…

http://www32.atwiki.jp/kawasepsp/

僕自身はこう、思い入れを汚された！的な感覚は 理解はできるものの、自分では感じないので、 まぁ別に買わないだけで問題ない。 サイキックフォース2012は たぶんEX入れて3回買った気がするけど、 2は一度も買ってないとかそんな感じで。

ただまぁ理解できるのでこう悲しむ人が多いのは悲しいことだねぇ。 特にオリジナル作者の酒井さんが辛そうとか勝手に想像して 少し悲しくなるのであった。

(03:03)

_ ぬかしておいた

http://d.hatena.ne.jp/yshl/20080321#1206098637

http://golf.shinh.org/p.rb?Fibonacci+Numbers#D-compile-time

まだなんかあるかな。

それはそうと delete blank lines はつまり kurimura さんは天才という話です。 全然説明になってない。

(13:20)

_ C++ そんなにややこしくない話

http://www.kmonos.net/wlog/83.html#_1721080322

ぶっちゃけ仕様のあるプログラム言語の実装なんて かなり簡単な言語でも難しいから個人、というか僕の手に負えないのは まぁそれはそうなんだけど、 C++ が特別難しいかというとそうじゃない、 ってのはなんとなく同意するところではある、かな。 一方 C の3倍なんてもんじゃない、 ってのはたぶんそれはそれでそうなのかなぁとは。

http://d.hatena.ne.jp/higepon/20080320/1206023186#c1206064805

でも template template とかなんかややこしそうなんだけどな。 あと a<3> b; が式なのか宣言なのかわからんとかは 特に難しいポイントではないのだろうか。

namespace は何も難しいことは無さそうに思うんだけど、 なんかあるのかな？

まぁなんにせよ C++ コンパイラを新しい OS や CPU に移植する、 なんてのは Java とか C# に比べりゃ簡単なのは まぁ間違いなさそうに思うところではある。

要はこう言語をフロントエンド部分とバックエンド部分に すごいおおざっぱにわけて考えるとこう、 C++ はバックエンド側は特に難しい部分が無い (try にコストが無い例外は難しいか。でも sjlj でいいじゃんね) というような話なのかなと思う。

で、フロントエンド部分を考えると、 まぁとにもかくも考えることがえらい多い、 ってのはまぁ間違いないところではあるかな… でも構文はたぶん Ruby とか Perl とか Haskell の方が 大変そうに思うから、 要は型かねぇ。

バックエンドとフロントエンド部分、 どっちが一般的に大変さのボトルネックになるのかは知らないけど、 higepon さんとか natsutan さんは間違いなく バックエンド側の方が強い方々なので、 フロントエンド部分がなんかややこしい C++ が ひょえーという感じになるのはまぁそうなんじゃないかなぁとも。

結局何が書きたかったかというと、 別に何も無い。

(18:23)

_ ああそうそう

http://d.hatena.ne.jp/odz/20080322/1206180371

テンプレートクラスの中のテンプレートクラスの中の テンプレートメンバとかは なんかこうよくわからんけど実装大変そうかも。

や、まぁそうでもないか。わからんけどなんかできなくはなさそう。

特殊化はオーバーロードの解決とか OCaml とかのパターンマッチと 変わらんのじゃないですかね知らんけど。

まぁ C++ コンパイラ実装 hackathon でしょうか。

ちなみにネイチブは hackathon をハッカタンと発音したりしてた気がします。

ハッカたん！！萌え！！！ハッカたん！！！！

(19:39)

_ 今晩は SRM

1時からなので暇な子はやるといいですよ。

と書いておくと相手ができていいかもと思った。

(22:13)

_ 本読み始めたら

バグ埋めたと気付く。

example で再現しないとかうざいな。

(00:06)

_ うーん…

かなり長い時間考えたけど、 未だに600点問題の意味さえわかっていない。

900点問題は意味はわかったがこんなもん解けるか と思った。 うちの部屋の人のコードはこれ たぶんデカいテストケース入れれば 理由はわからんけど精度とかで死ぬぜきっと とか思って適当な値を入れようと思ったんだけど、 適当なテストケースを作ることさえできなかった！ アホか！

でまぁ他の子のメモ化してない 250を落として現状135+50。 今回難しそうだったし system test 通れば レーティングは現状維持はできるんじゃないかなぁと予想。 通るかどうかはイマイチ自信ない。 まぁしかし毎度毎度250は最初の方針が間違ってると気付いて 実装しなおすので時間が無駄になりまくってるなぁ…

(02:42)

_ おや

レート増えたわ。 challenge させてくれてありがたう。

(02:58)

_ む

gus さん 250 解くの速いなというのと、 gus さんでも 600 も 900 も解けてないのかーというのと。 600 はともかく 900 はなんか通ってるコード見るに よくある DP ってやつなんだよねたぶん知らんけど。 僕は DP というのが未だかつて topcoder の期間中に書けたことがないので、 なんか練習してもいいかなぁと。

(03:05)

_ うーむ

scheduling 、やる気も時間もまぁそれなりにあるんだけど、 いいアイデアが思いつかないなぁ。 情けない状態である

(14:52)

_ うーむ

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

こんなもんで終わりか… 今日ちょっと思いついたアイデアで少し点数増えたみたいだし、 他にも細かい改善は結構あるんだけど、 いずれにせよ上の人1人抜かすだけの変更はもう思いつかんなぁ。

(00:12)

_ そいや

マラソンは最後に大失敗をやらかしたのだった。 なんか悪くなりそうなのを submit して、 やっぱ悪くなったかーと思って rollback したヤツを save して example test 通したところで、 花見で酔っ払ってたので寝てしまって、 full submission はできなかったのであった。

加えた変更は、schedule をやってみた後に、 もし時間が十分に余ってるのなら 他のパラメータでもやってみる、 っていうアドホックなもの。 基本的には時間が余ってるかの判定は かなり安全側に倒してあるから、 なんか本番の system test だけ通ってくれたりすると嬉しいけど、 期待はできないかなぁ…

10日間の努力が水泡です。

それはそうとオセロの方はよく見ると9位とかだったんですね。 なんか system test で結構順位増えてたわけだ。

(04:19)

_ authorized_keys

なんでログインできないかな…と ずっと悩んでいたのだけど、 authrized_keys になっていました。

(20:58)

_ ドラクエ

http://esupa.xrea.jp/dq/1000000/

via http://twitter.com/hogelog/statuses/777533406

すばらしかった。

(22:01)

_ て

あのひとか。

(22:04)

_ だるいなぁ

4ヶ月ごしのTODOをだるっとね。

(22:07)

_ てすと

(15:25)