はじめてのにき

_ うーむ

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

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

(00:12)

_ 本読み始めたら

バグ埋めたと気付く。

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

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

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

_ ふう

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

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

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

_ 24B

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

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

(01:50)

_ processor scheduling

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

(17:23)

_ あーうー

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

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

(23:09)

_ スケジューラ

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

(01:00)

_ やった!

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

かなしいね☆

(01:05)

_ 四角い地球

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

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

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

いまいち

(17:35)

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