2007年11月

ちゃんと資料を追わなかったので分からんのだけど，元の式の対称性を使って変数を減らしたときに正定値条件は必要十分でカバーできるけど目的関数の最適性って保存されるのだろうか？　変数を減らすプロセスに目的関数の係数行列ってでてきてたっけ？　気になってきたのでそのうち確認しよう．

もう少し頭使えよと言いたくなる結果．まあいいだろうとか考えて放っておいた部分が響いて正解なしに…

250点問題： price を最大までインクリメントしながらチェックしてたら時間オーバーだった．五千万位のループは大丈夫かと思ったけどだめみたい．馬鹿なことせずに与えられた配列内の値だけチェックすれば通っていたものを（誰かの max までは単調増加なので）．

500点問題：図形っぽいからパスした．直方体を２の冪のサイズの立方体で埋める問題．正解を見てわかったけど，２の冪しかないのでな 1x1 で埋めなければならない部分を埋めて再帰的に1/2サイズにした問題を解けばよかったらしい．

1000点問題：結局のところ行列式に (-1)^(N-1) を掛けたものが答えになる．理由は以下のとおり．まず，行列に吐き出し操作をしても答えは変わらない（自明）．そして，吐き出し後には，積が非ゼロになるドミノの選択は全てが対角要素である場合しかなく，その積は行列式に等しい．同時に，ドミノの連結グループ数は行列の大きさである N に等くなっているので，答えは行列式に(-1)^(N-1) を掛けたものに等しい（偶数なら符号反転）．ということで，行列式を求めればおわる．幸いなことに modulo 121547 の答えでよく 121547 が素数で有限体上の計算になるので普通のLU分解とかが使える．

以上を踏まえ，有限体の逆元を求めるための拡張ユークリッドの互除法を実装し，演算を有限体の演算に置換したピボットつき LU 分解を実装して提出したのだが…　正規化のためのルーチンを次のように書いていたため TLE 喰らった．

    int norm(long a) {
        while(a < 0) a+=P;
        return (int)(a % P);
    }

掛け算してんだから数万回ループすることもあるよなぁ．もう少し進化して下のように書いたら普通に通ったし．

    int norm(long a) {
        if(a<0) a -= (a/P-1)*P;
        return (int)(a % P);
    }

あー，もったいねぇ．解けてたのに…

別に痛くないけど気になる部分があるのでいってみた．とりあえず気になった部分は虫歯＋前の詰め物が少しとがっていたと判明．そして余計なものもいくつか見つかった．一番面倒そうなのが左上親知らずの外側の生え際の虫歯．なんとなく前からなんか違和感あると思っていたら虫歯だったと．とりあえずどうなるかわからんけど全部片付けるのに一ヶ月～一ヵ月半くらいらしい．

EuroPar2007で発表のあった The Multi-Core Standard Template Library (MCSTL) が GCC に統合されている（されつつある？）らしいので，セミナーのネタにと試用してみた．GCCのオフィシャルページを見ると libstdc++ parallel mode という名前で統合中らしい．こいつは既存の STL を OpenMP による並列実装の STL に置換しましょうというもので，既存の STL で書かれたコードがそのままで並列プログラムになってくれる．

んで，試そうと思ったら最新のGCCリリースであるところの 4.2.2 にも入っていないということに GCC4.2.2 のビルドが終わった時点で気づき…　しょうがないので svn のリポジトリから最新のソースを落としてきて GCC をビルドした（８コアくらいあるマシンで make -j8 とかやるとビルドがとても速い）．とりあえずソースの状態で libstdc++-v3/include/parallel というディレクトリがあれば parallel mode が使える．

準備できたので次の std::sort を使ったプログラムを試してみた．

#include <iostream>
#include <algorithm>
#include <vector>
const int count = 1000000, num_tests = 10;
int main(int argc, char **argv)
{
    std::vector<int> v(count);
    for (int i = 0; i < num_tests; i++)
    {
        std::generate(v.begin(), v.end(), rand);
        std::sort(v.begin(), v.end());
        std::cout << "." << std::flush;
    }
}

コンパイルは parallel mode 用のフラグ（-D_GLIBCXX_PARALLEL -fopenmp）を立てればよいらしい．

 g++-XXX test.cpp -o testS -march=native  # sequential mode
 g++-XXX test.cpp -o testP -march=native -D_GLIBCXX_PARALLEL -fopenmp  # parallel mode

Quad の Xeon x2 という８コアで動かした結果は以下のとおり．

> OMP_NUM_THREADS=8 time ./testS   # sequential mode
..........        6.26 real         6.24 user         0.01 sys
> OMP_NUM_THREADS=8 time ./testP   # parallel mode
..........        1.39 real         5.66 user         0.75 sys

普通に４～５倍速くなってるのを確認．すげー．並列プログラミング簡単．とりあえず sort は簡単に並列に動いてくれた．

ついでに， parallel mode は他にも並列実装を持っているらしいので試してみた．

まず std::partial_sum．4.51秒が1.65秒になった．８コアで約四倍．

#include <iostream>
#include <algorithm>
#include <vector>
#include <numeric>
struct one {
  int operator()() const {
    return 1;
  }
};
const int count = 10000000, num_tests = 10;
int main(int argc, char **argv)
{
    std::vector<int> v(count);
    std::vector<int> r(count);
    std::generate(v.begin(), v.end(), one());
    for (int i = 0; i < num_tests; i++)
    {
        std::partial_sum(v.begin(), v.end(), r.begin());
        std::cout << "." << std::flush;
    }
}

次は std::accumulate．3.20秒が3.79秒に増えた．全要素の和をとるだけなので普通に考えると８コアで８倍いきそうだけど…　速くならない理由は不明．

#include <iostream>
#include <algorithm>
#include <vector>
#include <numeric>
struct one {
  int operator()() const {
    return 1;
  }
};
const int count = 10000000, num_tests = 10;
int main(int argc, char **argv)
{
    std::vector<int> v(count);
    std::generate(v.begin(), v.end(), one());
    for (int i = 0; i < num_tests; i++)
    {
        int sum = std::accumulate(v.begin(), v.end(), 0);
        std::cout << "." << std::flush;
    }
}

最後に試したのは std::for_each．3.81秒が3.75秒．全要素に独立に関数適用するだけなので８コアで８倍いきそうだけど…　速くならない理由は不明．

#include <iostream>
#include <algorithm>
#include <vector>
#include <numeric>
struct f {
  void operator()(int &x) const {
    x = x + 1;
  }
};
struct one {
  int operator()() const {
    return 1;
  }
};
const int count = 10000000, num_tests = 10;
int main(int argc, char **argv)
{
    std::vector<int> v(count);
    std::generate(v.begin(), v.end(), one());
    for (int i = 0; i < num_tests; i++)
    {
        std::for_each(v.begin(), v.end(), f());
        std::cout << "." << std::flush;
    }
}

ということで，簡単に並列化できそうな部分でいろいろと失敗した模様．使い方が悪いのか実装途中なのか？　よくわからんけどうまく動いた部分に関しては効果が確認できたのでよし．

うまく使えずにごちゃごちゃやってたけど最終的に落ち着いた方法：

(setq tramp-default-method "sshx")

を .emacs に追加して ssh 経由をデフォルトにしつつ， cygwin の ssh-agent でキー認証をかけておいて meadow をそのコマンドラインから起動．

落ちとしては，HOME の設定が meadow 用と cygwin 用で別々になっているため .emacs がうまく読まれなかったり，同じく HOME のせいで known_hosts へのキーの追加に失敗したり，キー追加確認用の YES/NO 選択で応答不能になったりと．

とりあえず HOME の設定を整理しようかなと思う．

管理者権限での実行は runas コマンドで実行アカウントを切り換えればできるらしい．でも，Administrator アカウント自体が有効にされていなかったために何度試しても失敗しまくった．

ということで，Administrator アカウントの有効化：スタートメニューとかのコンピュータの右クリックメニューの管理（コンパネからコンピュータの管理でも可）→ システムツールの下のローカルユーザとグループ → ユーザ → Administrator を選択してプロパティ開いて無効化のチェックをはずして閉じる → Administrator を選択してパスワード設定．これでやりたい放題．

本棚の整理をして邪魔になった本を一週間ほど前に宅本便で売りに出していたのだけどその結果が今日来てた．ラノベと漫画が半々くらいで結果は以下のとおり．

種類                                        計算金額      商品数
__________________________________________________________________
本                                            4420円      106冊
お値段がつかなかった本                                      0冊
ソフト                                           0円        0点
お値段がつかなかったソフト                                  0点
__________________________________________________________________
商品数合計                                                106点
お値段がつかなかった商品数合計                              0点
お支払金額合計                    5304円(うち割増分       884円)

２割り増しのキャンペーンも入って一冊あたり50円なり．ゴミよりは高いが安いよなぁ．全巻セットとか限定版とかならオークションで売ったほうが手間はかかるけど還元率は高そう．

Vista でうまくできない．どういう管理になってるんだ？　管理者権限のアカウントだけど管理者権限でプログラムを動かすにはどうすればいいんだろう？　いろいろと書込み禁止で作業できん…

何ヘルツの音まで聞こえるかを tone generator のソフトで試してみた．テレビの音 15kHz は普通に聞こえる．しばらく上げて 17kHz は聞こえる．18kHz くらいから怪しくなる．19kHzになるとある特定の角度に頭を傾けたときに感じるていど（聞くというレベルでなく）．20kHz も19kHzと同じ方向のみ頭を振れば変化が感じられる程度．まあ，スピーカの音を最大に引き上げれば聞こえなくもないけど体に悪そう．

「レッツノート プレミアム ファンブック」だそうで．モバイルNo.1予約宣言のキャンペーンの先着2000人に入ってたらしく送られてきた．今年がLet'snoteの10周年とのことで，そのための記念ファンブックらしい．とりあえず一通り読んでみたけど技術的なことはあまり詳しく載ってないので面白みにかけるような…．もう少し分解図とか載せてほしかった．あと軽量化のために苦労した点とかもっと詳しく．まあ，普通の人向けにはどうでもよいことだろうけど．

はてなっぽくかけるという NP_HatenaLike というプラグインを入れてみたのだけど， <pre> タグ内に空行（空白のみを含む）があるとその行で <pre> タグの効果を切られてしまう．でも &nbsp; を書き込んでおけば切られることはない．ということで，ソースを <pre> で囲むときに空行があるときは &nbsp; を書くようにした．

もうひとつ．Nucleus のDBバックアップを行うと，行頭に # がある行はバックアップ用スクリプト中のコメントとして扱われてしまい，データが吹き飛ぶことになる．Cのソースとかの場合 #include とかで先頭に # が来るため結構きつい．そこで，# を &#35; という風に文字参照に置き換えて書くようにした．

これらの条件の下，NP_SyntaxHighlighter を有効にしてみた．その結果，&#35; が # にならずに &#35; のままハイライティングされるようになってしまった．当然 &nbsp; もそのまま残って & だけに色がつくとかいう状況になった．原因は NP_SyntaxHighlighter がこれらの参照をうまく扱えないことにある．

ということで，NP_SyntaxHighlighter を少々書き換え． highlight_code の先頭付近で参照の置換をしている部分に必要な置換を追加．さらに， <pre> タグ直後に入ってしまう改行を回避．

$string = str_replace ( array ( '&quot;', '&apos;' , '&lt;' , '&gt;', '&apos;', '&#35;', '&nbsp;', '&amp;' ), array ( '"', "'", '<', '>', '?', '#', ' ', '&' ), $string );
$string = preg_replace('/^[ ]*[\n\r]/','', $string);

んで，重要なのが NP_SyntaxHighlighter の前に NP_HatenaLike を置くこと．NP_SyntaxHighlighter が &nbsp; を空白にしてしまうので逆向きだと <pre> が切れる．

とりあえずこれで大きく変な部分が解消された．あとはバックスラッシュが消えてしまう部分をどうにかすれば…

前の実験に使った TeX ソースでは，ソースが HDD にある場合と RAMDisk にある場合とで特に実行時間の差は見られなかった．そのため，前回の実験はソースを HDD において実行時間を計っていた．でも，ひょっとしたらソースが小さかったから差がなかったのかもしれない．ということで，もう少し大きなソースを持ってきて，pTeX のインストール先とソースの保存先とを変えつつ再実験してみた．

使った pTeX は角藤版の 2007/11/12 時点での最新バイナリ．余計なパッケージはインストールせず，ほぼ標準インストールの構成．

コンパイル対象のソースにはとある博士論文を使用．ソースは15分割くらいで，eps系の画像を55個くらいとリファレンスを250個くらい含む．コンパイル時間の計測は，metapost 9回，platex，jbibtex，platex，platex というコマンド列を全部実行した時間を計測．参考までに，TeX ソースの合計サイズが 700KB くらいで，metapost ソースの合計サイズが 160KB くらい．コンパイル時に生成されるファイル総数は75個で，内 68個が metapostの生成するファイルである．

まず，メインマシンでの結果は次のとおり（Core 2 Duo 2.4GHz, 4GB dualchannel memory (PC-6400), SATA 7200rpm HDD，Vista Business 32bit．pTeX と TeX ソースは別々のHDDにある）．

pTeX を RAMディスク上においた場合，ソースも RAMDsik に置いたほうが 0.1 ～ 0.2 秒程度速いかもしれない．逆に，pTeX を HDD に置いたときには RAMDisk にソース置いたほうがほんの僅かに遅くなるのかもしれない．でも，いずれの場合も意識するほど意味のある差とはいえないでしょう．

続いてW7Bでの実験結果は次のとおり（Core 2 Duo 1.06GHz, 2GB dualchannel memory (PC-4200), SATA 5400rpm HDD，Vista Business 32bit．pTeX と TeX ソースは同じHDDにある）．

こちらも傾向としては同じ．意識するほど意味のある差は見られない．残念．

結論：TeXソースをどこに置くかはどうでもいいんじゃないかと．

環境が変わるとどうなるかわからないけど，少なくとも自分の環境では RAMDisk においても HDD においてもコンパイル時間は変わらない．ただ，RAMDisk のほうが情報をロストする可能性が高いので，安全を考えると HDD に置いといたほうが良さげではある．

RAMDisk 上に pTeX をインストールして，HDDにインストールしたものとコンパイル時間を比較してみた．

コンパイルに使ったTeXソースは９分割されており，64KBくらいでA4に１４ページ（英語）ほど．ドキュメントクラスは article で，パッケージはfullpage, color, graphicx, amssymb, amsmath, cite を使用．画像は eps を６枚くらい．

コンパイル時間は，中間ファイルをすべて削除した状態から platex を３回かけた時間を time コマンドで測定（real）．ls-R データベースを作った場合と作らない場合とで測定．各セットについて１０回くらい走らせて平均を取った．

結果は以下のとおり．マシンはW7Bを使用（Core 2 Duo 1.06GHz, 2GB dualchannel memory (PC-4200), SATA 5400rpm HDD）．

とりあえず ls-R のあるなしにかかわらず RAMDisk のほうが速い．ls-R データベースがないときはRAMDiskのほうが30%程度速くそれなりに大きな差がついた気がする．でも，ls-R データベースがあると6%程度しか差が出ない上に絶対値も小さくなっているのでほとんど無視できる程度の差しか出なかった．

ちなみに，メインマシン（Core 2 Duo 2.4GHz, 4GB dualchannel memory (PC-6400), SATA 7200rpm HDD）だとRAMDisk と HDD で有意な差が出なかった．OSのディスクキャッシュが効いたのかHDDが速かったのかそれ以外なのかは不明．

結論：RAMDisk上にpTeXをインストールしてもあんまり特にならない．ls-Rデータベースを mktexlsr とかで作るほうが手間も要らずに速くなる．

まあ，OSのディスクキャッシュもあるのでリードアクセスだけのファイルを RAMDisk 上においておく事の意義はそれほどない気もする（RAMDiskのキャッシュをとられるとアホだ）．やっぱ書込みの激しいキャッシュとかに使うのが正しいのでしょう．

比較的近いけど入ったことなかったので散歩ついでに入ってきた．とりあえず東大関係者は身分証を見せれば入園料タダらしい．なんかいい写真でも取れるかと思ったけど時期的に無理っぽかった．というより，この時期にきれいなものが少なかったのと曇りかつ日が傾きすぎてたのとでだめだこりゃと．それでも利用者結構いたのは驚いた．

PlexTools Professional の Vista 対応が未だに行われないので PlexTools Professional LE をダウンロードして使うことにした．どこら辺が Limited Edition なのか全くわからないのだけど．とりあえずデータの読み書きが普通にできるらしいので今のところ LE で問題なさげ．

注文しておいた今日発売の Let'snote W7B が午後二時ごろ届いた．佐川急便で朝一で持ち出されたのに午後二時まで待たされるのはいつものこと．三時から秋葉原で輪講なのでセットアップは帰宅後までお預けになってしまった．で，以下セットアップして使ってみた感想．

まず気になるところ．ファンがうるさいときはうるさい．小型のファンなので高速回転し始めると高めの音が結構気になる．問答無用で低速回転設定にしたくなる．あと，W2 に比べてディスプレイ部分の外枠がやわらかくなっているので開くときの手の位置を気にしないと怖い．端を持ったときには結構ぐにゃりとする．

そんで以下はいいところ．まず，有線の Gigabit Ether 対応がうれしい．データの転送が速くて環境を移すのに助かる．Windowsのファイル共有での転送速度で 23MB/s まで出たので十分でしょう．そしてグラフィックの性能も W2 に比べたらものすごくよくなった．風神録が普通に動いてくれる．あとは処理速度自体が上がったのは当たり前として，メモリに SO-DIMM が使える&Dualchannelで動くようになったのもうれしい．まだ増設してないけどそのうち増やしましょう．

ところで，HDDのリカバリ用データの領域には具体的に何に関するデータが入っているのだろう？リカバリディスク自体は別に用意されているのだけど…　容量の関係なのだろうか？　とりあえず 2GB ほどなので気にしなければ気にならないけど HDD 換装時にどうなるのかが気になるところ．

Thunderbird のアップデートが出たので更新実行したら何故か失敗しまくる．そして Thunderbird のアップデータはあきらめることを知らないのでキャンセルができない．おかげですぐに来るであろう大事なメールの返信を受信できない状態に…

何が悪いのかと原因を探ってみると mozMapi32.dll が消せないとのこと．で，このファイルを誰が読み込んでるのかと思ったら Qcam.exe であったと．（こういう時 ProcessExplorer はとても便利だなぁ）ということで，とりあえず Qcam をアンインストールすることに決定．ただ，Qcam のアンインストールが途中で止まって何もできなくなってしまい…　結局は Vista ごと再インストールすることになった．

さて，悪いのは誰だろう？

Fortress のプログラムでインデントに TAB 使ってたら Parse エラーが出まくった．そして原因が TAB であることに気づくまでプログラムを何度も書き直す羽目に．Spec のどこかに TAB に意味があるって書いてあったっけかな？

フォント周りで Error: /rangecheck in --string-- とか言って怒られまくり…　色々試したけど原因わかんないなぁと思って検索かけてたら次の書き込みに行き着いた．

http://oku.edu.mie-u.ac.jp/~okumura/texfaq/qa/47672.html

どうやら XP あたりからフォントを持ってこないとだめらしい．んで gs/lib/cidfmap も書き換えてやると．何が直接の原因なんだかわからないけどとりあえずこれで日本語が通るようになった．

ところで texインストーラ3 なんてものがあったんだなぁ．微妙にインストールが楽になった気がする．

pTeX をフルインストールしたら 500M 超えた．これをRAMDisk上にそのまま置くのは馬鹿だよなぁ．標準インストールでも 260M らしい．インストールするパッケージをちゃんと選ぶとするか…

HDDがガリガリうるさい＆遅いので，QSoft の RAMDisk "Enterprise (full)" Version 5.3.1.* を導入．ドライバのロード＆アンロード時にイメージの読込＆保存をしてくれる設定もあるので色々楽そう．

そんで，FireFox のキャッシュやら環境変数の TEMP＆TMP を全部 RAMDisk に指定．とりあえずガリガリうるさかったのが大分静かになってくれた＆所々速くなってくれた（気がする）．

この調子で TeX 関係も突っ込んでしまえばコンパイルが早くなってうれしそう．ところで TeX ってどれくらい容量食うんだ？

Vista のエクスプローラでジャンクションをクリックしてもアクセスできないといわれる．普通にリンク先にいってくれるものもあるけどほとんどがアクセス拒否．さてどうしたものか？

とりあえず FireFox やら Thunderbird やらの設定は C:\Users\XXXX\AppData\Roaming とかにあることだけは見つけたけた．そしてNICのIP固定とかどこでできるんだ？

MSDN AA で借りてきたのだけどプロダクトキー違うし…　また月曜日にもらってくるか．とりあえずプロダクトキーなしでも30日間動くらしいのでソフトの動作テストだけしよう．

WindowsVistaを試そうと思いパーティションのきりなおしも面倒なのでHDD買ってきた．HITACH のひとつ前の世代の 500G を 12k円 にて．で，ついでだからと既存のパーティションをいろいろと丸ごと移動してたら時間が…　Vista のインストールは明日の朝かな．

家から70mほどの所に９９イチバなるコンビニがオープンしたので覗いてきた．基本的に商品は９９円（税抜き）．時々フェイントで１９９円とか２９９円とかが混ざる．９９円に縛られず，下二桁が９９なら良いというコンセプトらしい．

まあ，９９円で売れる商品しか揃ってないけどお菓子を買うにはちょうどいいかもしれない．あと，ちょっと離れたスーパーにしか置いてなかった納豆が置いてあるのは好得点．

Windows の cmd.exe の次のシェルらしいので面白そうだからダウンロードしてみた．だいぶ前からあったらしいけどコードネームが Monad だったのは何か数学的意味が…？

それはさておきちょっと使って嫌だった部分を上げる．

第一にバックが黒くないところ．微妙に紺色なので黒くしてしまった．

第二に ls が内部コマンド（alias）で定義されてること．ls -al と書いて怒られた．

第三に man も内部コマンドで定義されてること．まあ，内部コマンドの説明見るには便利だけど．

第四に sl が内部コマンドで…　　第五に cpp が…

ということで，Alias: に移って rm ls にて偽物の ls には消えていただいた．んで，このまま Alias: で ls したらどうなるかと思って試してみたら元のディレクトリの一覧が出た．まあ，当然といえば当然だけど Alias: という位置は PowerShell が適当に作った場所であって他のプログラムからみたらカレントディレクトリの移動はしていないと．

ついでに，PowerShell 起動しなおしたら元に戻った．Export-Alias, Import-Alias 使わないとダメみたい．

落とし穴： ls と rm の alias を消そうとして順番間違うと危ない．

touch ls
cd alias:
rm rm
rm ls

とかやると alias の ls は消えずに touch で作った ls が消える．まあ，最初の rm が Remove-Item の alias で二つ目が /bin/rm なだけだけど．

結局，プロバイダとして物理的なドライブ以外の物の場合カレントディレクトリの齟齬があると．で，この状態で PowerShell 外のコマンドを読んでしまうとある意味変なことが起きると．sshfs みたいなのをプロバイダにするとリモートのファイルを消したつもりが手元のを消すことに？　結構危なそう…

BSP実装がなんか変な挙動を示すなぁ．AlltoAllで書きなおした方がいいのだろうか？とりあえずもう一セットやってみっか．

寝付けないので自前で考えた解き方を試しに実装してみた．解説聞いてないので合ってるかどうかは知らんけど．

A: LinkedList で普通に要素を抜いてくだけ．最大サイズでも一瞬で終わるのでこれで問題なさそう．

B: エラトステネスのふるいで素数求めたら終わり．与えられた数から前後の素数を探索するのは前後を順に見てくだけでいい．

どうせすぐ近くに素数があるだろうから．

C: 状態遷移行列を T乗すると考えるかT回の状態遷移を計算すると考えるか…　状態遷移行列が疎なのでグラフ上で状態遷移をシミュレートするイメージの実装．スタートに戻るマスへの遷移はスタートへ足しこむ．一回休みは一回休み用のノードを作って一度そのノードへ遷移するようにする．計算量は O((N+L)T) なので時間も問題ないでしょう．

D: 面倒なので考えてない．一つの三角形を決めたら他も決まるから全部の点を試せばいいのかな？

E: これもグラフを作るまでが面倒．グラフさえできれば最短路なので楽．

F: ソートした辺のリスト上で最大重み用のポインタと最小重み用のポインタをスライドさせてく．二つのポインタの間にある辺集合で全域木が作れるなら最小のポインタを進める．作れないときは最大側のポインタをするめる．全域木ができるかの判定は連結しているかの判定でできるので適当に Unon/Find でやった．これで全体としては O(E^2) だけど…　手元では最大サイズが一秒以内なのでギリギリオッケー．

G: 状態空間のサイズが 2^24 程度なので普通に幅優先でいい気がする．ただ最大サイズのサンプル入力で４秒かかるのでもう少しコードを特化した方がいいかもしれない．

H: 再帰下降で Exception なげて帰ってくる．Hashtable とか使わないとインデックスで困るけどそれだけだと思う．

I: 面倒なのでパス．多角形を周りから削っていって最後に残ったところか？何となく島が海に沈んでくイメージ…

J: 連立方程式立てて解けば終わりなのだけど…　有理数で一次方程式を解かねばならないし（doubleとかでもいいのかな？），そもそも方程式の係数を求めるのも面倒．コード書きたくないから二乗根の場合に関して手で解いてみただけ．久々に 4x4 の一次式を解いた．

とりあえず，ABCFGH の実装に（テレビ見をながらではあるけど）５時間ほど．やっぱ９問解いたチームってのはすごいなぁ．

風船運びと後片付けがメインの仕事．今年の問題はA, B が異常に簡単だったので開始直後はこれらが出まくって忙しかった．でもこのスタートのラッシュを過ぎたあとはゆったりと風船を補給してただけ．ついでに途中で元気のなくなった風船の交換もあったけど　（例年こんなのあったっけ？）

あとは飾りのための風船を大量に膨らませたのは面白い仕事だった．というか他の人の仕事を奪ってしまったのだけど．とりあえず遅めの作業を見ていたら思わず手を出していた…

そういやコーチと選手が廊下やトイレで接触しないように見張る仕事もあったなぁ．もう少し場所のアレンジを考えてほしいと思う．コーチは二階席から見るようにするとか．そもそも仕事マニュアルに書かれてなかったなので接触の可能性に後で気づいたんでしょう．今回の大会は全体的にスタッフ陣のアレンジが甘い印象を受けた．まあ大変なんだろうけど．

裏方の仕事って結構大変（面倒）だったんだなぁと実感．英語の受け付けも結構あたふたしてた気がする．シーツ配りもそれなりに重労働だったかな．

それはさておき，色々な部分でスタッフの準備というか対応が甘い点が多かった気がする．案内が無くて分かりにくい，効率の悪い作業をする，ジャッジとの間のプロトコルがおかしい，とか．ついでに名札にチーム番号書いといてほしい．変な札にだけ番号書いて渡すってのはどうかと．とにかく色々な部分の情報を取っといてマニュアルにできるものはしてしまえと思う．そうすりゃ回を重ねるごとに改善されていくだろうから．とくにＰＣの用意の仕方とか受付とかの対応とか風船の用意の仕方とかどうにかしてほしい．

頭をぶつけたら血が…　　蛇口ごときに負けるとは情けない．