凄腕すぎたカウンセラーのはなし ——または、カウンセラーのパラドックス
ある街に、凄腕のカウンセラーが住んでいました。
その街に住む、自分のことがよくわからないぞー、ってなってしまった人が、カウンセラーのところに相談にいくと、たちどころに問題を見抜いて、解決してくれるのです。
なんでそんなことが出来るのかと云うと、そのカウンセラーさんは「自分のことがよくわからないひとリスト」と云うのをもっていて、そのひとたちのことを既に徹底的に調べていて、よくわかっているからなのでした。
プライバシーの侵害だ！と云う声もあるかもしれません。でも、そこはカウンセラーさんも職業人で、カウンセリング以外には使いませんし、だいいち自分のことをよくわからないひとは遅かれ早かれカウンセラーさんのところに来るので、結局は自分の患者であるのと同じことです。
それだけ情報収集能力があると不安かもしれません。しかし、自分のことをよくわかっている人達は満ちたりている人達で、カウンセラーさんのところに相談しにくる必要がないのでそもそもカウンセラーさんも集めません。自分の仕事で手一杯です。それに、自分のことをよくわかっているのだから、カウンセラーさんが自分のことを調べていたらすぐにわかって、提訴されてしまいます。あぁこわいこわい。だからそんなひとのことは何も知りません。
そんな訳で、カウンセラーさんは自分の特技を上手く生かして、街の人達を助けて今日も繁盛しているのでした。
そんなある日。ひとりの患者さんがいいました：
「いやあ、先生は本当に何でもわかってるんですねえ。御自分のこともよぉくご存知なんでしょう？凄いなあ……」
その場では「いえいえ、それほどでもないですよ……」と流したカウンセラーさんでしたが、後で思い返してみて困ったことになってしまいました。「はて、本当に私は自分のことをよくわかっているのだろうか？」
「もし、私が自分のことを良くわかっているとすると、ポリシーから私は自分のことをよくわからない筈だ。じっさい、今もよくわかっているかこうして考えている。しかし、これは矛盾だ！自分のことを知っている筈なのに知らないことになってしまった。と云うことは良くわかっていないんだな……」
カウンセラーさんはこの悲しい現実を受け止めつつも、まあ、仕方ないか、と思おうとしました。しかし、ここでまた引っ掛かってしまいました。
「では、私は自分のことを良くわかっていないんだな。とすると、またポリシーより私は既に自分のことを徹底的に調べてよくわかっていないといけない。おかしい、これはこまったぞ……」
そんなこんなで、カウンセラーさんは苦悩のドン底に落ちてしまいました。いったいこのジレンマをどう解消すればいいのか……。
こんなことをずっと考えている内に、段々と眠れない夜が続き、遂には診療所をお休みにしてしまう始末です。
そうこうしている内にも、悩める人達はまだそこら中にいます。かつて治療してもらった患者さんたちは、少しでも早い恢復を祈って花や差し入れを診療所の前に差し入れていきます。「はやく元気になってください」と手紙を認めるひとも多かったようです。
しかし、幾ら励ましの声を聞き、幾ら差し入れの山を見ても、カウンセラーさんの悩みは解決しません。嗚呼、どうすれば……。
後日談
それから更に何日かが過ぎ、カウンセラーさんは思い付きました。「そうだ！都会のカウンセラーに相談にいこう！」
都会のカウンセラーはカウンセラーさんの師匠に当たる人です。長いこと会っていませんが、腕は確かで、修行時代はいつも的確なアドバイスをくれていました。
あのひとならきっと、この状況を打破してくれる！その希望を胸に、カウンセラーさんは師匠に会いに遠路はるばる都会へと向かいました。
＊ ＊ ＊
「……と云う訳なんです。師匠、何か素晴しい解決はないものでしょうか」
「ああ、それなら簡単だよ。」
「えっ、本当ですか？」
「ああ。君は自分のことをよくわかっているか、わかっていないんだろう？」
「ええ、そのとおりです。」
「じゃあ、君は自分のことをよくわかっていないことになるね。だって、そんなこともわかってないんだから・・・。」
OS X で早稲田学内ネットワークから SSH & GitHub を使用する方法
早稲田学内ネットワークから GitHub に接続したり SSH 使ったりするには汎用プロクシを使う必要がある訳ですが、汎用プロクシは Snow Leopard に対応していませんね。これはひどい！
メールはまあ Gmail とかを使っていればブラウザから確認出来る訳ですが、 ssh や Git はそういう訳にもいきません。
自分なりにその解決策を見付けたので、ここにメモしておきます。
Proxy のアドレスなどは早稲田のものに準拠して書いてますが、多分他の大学やらなんやらの環境の人もその辺りを弄れば使えるのではないでしょうか。
まず connect を入れる
よくわかんないんですが、connect.c と云うのを入れると、 SOCKS Proxy 越しに ssh に繋げるみたいです。やったね！
Homebrew を使っているひとは簡単に、
$ brew install connect
で入ります。使っていないひとは connect.c を直接落としてきて、指示に従って
$ gcc connect.c -o connect -lresolv
でコンパイル出来るので、パス通ってるところに置けばよいです。
PFIサマーインターンに参加していました
8/1〜9/30 の二ヶ月間、株式会社プリファードインフラストラクチャー(通称 PFI)でインターンに参加して来ました。
報告記事を書かなくては……と考えている内に大分時間が経ってしまってこんな時期になってしまいました。
採用まで
夏休み特に予定がなかったので、何か今までとは違ったことに挑戦しようと思っていたところ、Twitter上で id:pi8027 さんが言及しているのを見掛けて、面白そうだと思って応募したのでした。
履歴書を埋めるのが中々の一苦労で、プログラミングコンテストなども余り実績がないし、開発したものもそんなに大規模なものはない。特に苦労したのが『受賞歴』の欄で、仕方がないので高校時代の演劇での受賞歴とTOEICの点数を書くと云う暴挙に。昔現実逃避に問題を解きまくっていた名残かHaskell ゴルフのランキングで4位だったので、ちゃんと書けた実績としてはそれぐらい。
せめて、と思って志望動機の欄に Haskell への愛を書き連ねて、送信。何かが間違っている気がする。
その後、書類審査は奇跡的に通過していたので、面接へ。
ちょっと書類で Haskell 愛を強調しすぎて居たので、志望動機を真面目に答えようとする……も、気付くと「一番大きいのは Haskell が開発で使えること」「Haskellは使えないという固定観念を打ち殺してやりたい」などと力説している。「他の人達とは別の言語でやりとりすることになりますが、どうですか？」と問われ「ええと……C++は出来ませんが Ruby なら出来ます……」と自分の失言に気付き何とか軌道修正を図ろうとする。だって好きなんだもん……
その後、問題へ。fmfm、花札シャッフルか……と、素直に Haskell で書く。しっかり動いている様に見える……あれ？テストケースを通過していない！？
余裕があった筈が焦る。結果的には返す値を間違えていたと云うショーモナイバグで、何とか時間内に修正出来たものの、やっちまったなぁ……という感じである。
その後、「数学科に行きたいと云うことでしたが、それじゃあこの発展問題を考えてみてください」と、カードの枚数が何万枚に増える、と云う条件での出題。飽く迄参考で解けなくても構わない、と云うことだったんですが、ここでもテンパってしまう。取り敢えず漸化式で考えるんだろうなあ、と云うことはわかる。もうその時点で解けている様なものなんですが、何故か一般項を出そうと考えて泥沼に嵌りタイムアウト。
この分じゃあ多分落ちてるだろうなぁ……などと思いつつ帰途についたのでした。夏休みなにしよう……
……と思っていたら、
この度は、ご面談に来ていただきありがとうございました。
選考の結果、「採用」と決まりました。よろしくお願いします。
何故か採用！！
奇蹟は重なるものだなぁ……と。これはきっと Haskell 枠で合格したんだ！と前向きに捉えることにしました。 Haskellばんざい！！！
インターン前半
最初の週は大学の講義があったため、初日の顔合せは午前中だけ参加、と云う形に。
会議室で自己紹介。他のインターン参加者は T京大学やT島大学の修士課程・博士課程であることが早晩明らかになり、大学一年の自分が参加してしまって良かったのだろうか……明らかに場違いだどうしよう……などと恐れ戦く。
しかし、ここで引いてしまっては意味がない！！と「Haskell を使っています」「メタがすき」「実際の開発に触れてみたい」「分散処理と自然言語処理に興味があります」「Haskell は unemployed *1 じゃない、私は採用された、 I employed だ！！！」と良くわからないことを喋くり散らす。
なんとかその場を乗り切った後は、環境の setup をして、お昼ごろにやってきたメンターの id:tanakh さんとインターンの課題について打ち合わせをする。
自然言語処理・分散処理、と云うことを考えると、膨大なデータ量があって解析のしがいがありそうな Twitter をテーマに何かサービスをつくろう、と云うことになる。その後二、三日程度の話し合いの結果、「樹形な tweet の自動まとめ生成サービス」をつくろう、と云うことに決定。
インターン同期生の大野さんもついったー関連のサービスを作ろうとしているようだったので、今後の方針についてメンターの方々も交えて話し合い。結果、当面の間僕は Twitter のクローラを作成し、大野さんは in_reply_to で接続されたグラフを生成する方法を模索することに。
あとの資料に書きましたが、中々沢山のついーとを一気に取得すると云うのは大変で、大量のデータを分担して取得して、それを同時に処理しなくてはいけないので、なかなか良い経験になりました。
Haskell はこの辺りの並行処理の機構が充実していて非常に書き易かったです。部分的に Ruby で書かれている部分があるのですが、 MessagePack-RPC を使うことで簡単に Haskell - Ruby 間でも通信することが出来てとても便利でした。MessagePack ++
PFIセミナー
インターン参加者はどんな話題でも良いのでセミナーで発表をすることになっています。
色々迷った挙げ句、僕は "Metaprogramming in Haskell" と云う題目で発表することにしました。下がその発表資料。
Metaprogramming in Haskell
View more presentations from Hiromi Ishii.
スライド中で使われた例は GitHub にあります。コンパイルタイム『交響曲第五番 運命*2』など斬新な試みが沢山！
しかし、PFI でHaskell を使っている方は tanakh さんと nushio さんくらいだったので、もう少し基本的な説明をしてからでないとわかり辛かったかもしれません……。反省です。
一週間近く関連する論文などを読み耽ってスライドを書いていたので作業が滞ってしまう事態に……力を入れすぎましたね……。
後半
クローラはひとまず完成と云うことで、後半は自動まとめ生成サービス logtter の制作に。
Haskell には fgl と云う優れたグラフ用ライブラリがあって、辺や連結部の抽出は割と楽に出来ました。
問題は、どうやって発言同士を繋げるかで、なかなか難しい。単語抽出も、MeCab などを使うより、単語辞書を用意して trie 木に突っ込み、連続最大一致部分を探すのが効率が良かったりして、この辺りは色々と相談に乗っていただきました。
この辺のヒューリスティックスは単純でも思ったより効果があったりするんだなぁ……と感心すること頻り。まだまだ全然初歩だけですが、こういったアルゴリズムやデータ構造をもっと勉強せねば……と。trie 木が本当に速くてびっくりしました。
ところが、終盤に差し掛かったときから クローラ が暴走する様に。その原因究明と解決の模索に一週間半ほど費してしまって、予定が押してしまい、logtter の方に殆んど時間が割けず……
とりあえず、それなりに繋がったグラフが吐ける状態までもっていき、HTML出力部を大急ぎで作成して最終発表と云う運びになりました。
最終発表 & 総括
そうこうしている内最終発表。緊張の余り RedBull を三本も呑んでしまう。日頃でも最大二本くらいまでだったのですが、これで僕も一人前かもしれません。
以下が最終発表資料。
最終発表
View more presentations from Hiromi Ishii.
最終発表の模様は PFI Intern 2010 Final Presentation 1 、 PFI Intern Final Presentation 2 にあるようです。
資料でも再三再四強調していますが、今回のインターンを通して『Haskell は実用言語である』と云う仮説は真実である、という確信が持てました。その証拠に、logtterの 実に95%は Haskell (残りは Ruby) で書かれていますし、近々100%になる予定です。
今後もPFIでアルバイトさせて頂けることになったので、logtter をひとまず完成させてデプロイするところまで行く予定です。Twitter でも思った以上の方々に logtter に興味を持って頂けたようで、大変嬉しい限りです。
今回のインターンを通して、プログラマとして大きな成長をすることが出来たと思います。Haskell での開発ノウハウもそうですし、プロの現場に触れてプログラマとしての考え方、ソフトウェアを売るということ、そう云ったものを少しでも学ぶことが出来ました。
今回のインターンで学んだもうひとつのことは、RedBull の偉大さです。僕は、炭酸が飲めません。苦手というのではなく、飲めないんです。小さいころから。ですから RedBull にははじめ大きな抵抗感があったのですが、飲んでいる内に、RedBull は違う、これは素晴しい飲み物である、と云うことが段々と腑に落ちて来ました。はじめの内は一日一缶程度と云う入門者でしたが、後半では一日に二缶飲む様になり、多い時で漸く三本飲むようになってきました。これは偏に今回のインターンのお陰です。もしインターンに参加しなければ、また、インターンの職場がPFIの様な常に冷蔵庫に RedBull が二十本以上常備されているような環境でなければ、僕は RedBull の素晴しさに触れることもなく一生を終えていたに違いありません。炭酸が飲めなかった僕が「こいつ酒の前にRedBullの味覚えやがった」と CTO ことちくわさんに云われるまでになることはなかったのではないでしょうか。RedBull gokgok!
そんなこんなで、最初は長く感じられた PFI サマーインターンでしたが、実際はあっと云う間で、足りないくらいでした。同時に、これだけ中身の詰まった二ヶ月間はなかなか無かったです。
来年以降もインターンは行われる様ですので、気になる人は是非是非参加しましょう！
他の参加者の報告記事
変数凍結のしかたがわからない
Prologの技芸第二版を片手にPrologの勉強をしているのだけど、
P.197 で紹介されている
% occurs_in(Sub, Term) :- Sub は項 Term の部分項である. occurs_in(X, Term) :- freeze(X, Xf), freeze(Term, Termf), subterm(Xf, Termf).
のプログラムが動かない。処理系はSWI-Prologをつかっている。
エラーを見たところ、freezeの挙動が、TAOP で紹介されているものと違うっぽい。
TAOP では、『freeze(X,Xf)は変数Xの凍結されたものXfを生成する』みたいなことを書いてあって、でも調べると今のfreezeはfutureみたいなことをやってるようで、TAOPの freezeに代わるものってあるんですかね……
ICFP 2010 競技説明
ICFP 2010 Task description の非公式日本語訳を置いておきます。非公式でやっつけ仕事なので、誤訳などがあるかもしれません。見付けたらご指摘おねがいします。
また、訳文中の誤りによって何らかの損害を被っても何ら責任は負えませんので、悪しからず。
原文：http://icfpcontest.org/2010/task/
翻訳：石井大海
ICFP Contest 競技説明
今年のコンテストの目的は単純です：金を沢山儲けるのだ
国際的な自動車・燃料製造(International Car and Fuel Production)で！
自動車と燃料の市場
あなたは自動車産業に従事し、日々自動車と燃料の設計・製造を行っています。各自動車は微妙に仕様が異なり、それぞれ適合する燃料が異ります。燃料が自動車に合うかどうかは、コンテストサーバを利用して簡単に判定出来ます。自動車だけから最適な燃料を探しだすのは簡単なことではないでしょう。これこそがあなたの仕事です。自動車の仕様はオープンソースで誰でも読むことが出来ますが、燃料の調合は非公開なので、独力で考えなくてはなりません。
コンテストであなたが行うべきことは二つあります。即ち、
- 自動車に合う燃料を計算・送信すること
- 新車を専用の燃料と共に送信すること
です。
これがあなたの収入源です。得点は自動的に計算されすぐに表示されます。
すべての自動車は常に利益を産みます。それぞれの自動車から発生した利潤は、その自動車用の燃料を製造している全員で共有されます。勿論、自動車の製造者も含まれます。利益の配分は平等ではなく、より効率的な燃料を製造した人に多く配分されます。
つまり、あなたの目標は、他の参加者の自動車に適合する燃料を設計し、また、なるべく他の参加者が燃料を設計しにくい自動車を設計することにあります。
はじめの内から、既に何台かの自動車が既に市場に出回っています。コンテスト中、参加者・主催者の双方により沢山の自動車が製造され、出荷されるでしょう。
自分が燃料を設計した自動車の数より多くの自動車を製造することは出来ません。
最大で72台(コンテストの開催時間と同じです)の自動車を製造することが出来ます。
この制限は、あなたがどの部門に参加していても適用されます。特に、Lightning部門参加中に上限一杯まで製造してしまった場合、後のコンテストに参加することは出来ますが、もう製造できるのは燃料だけになります。
採点
どの車に対しても、配当はその自動車の燃料を供給したチームすべてに支給されます。燃料はサイズ順にソートされ、サイズが同じ場合は提出された時間の早い方が優先されます。つまり、サイズが小さく提出が早いほど良く、特に小さいことが重要になります。ひとつの車に対して nチーム が燃料を提出した場合、順に 1/n, 1/(n+1), ... 1/(2*n-1) 点をそれぞれ獲得します。
自動車を設計したチームが最初に提出した燃料も、この評価の対象になります。これは、自動車の設計者がより多くの利益を得られるための措置です。
配当は一定の期間ごとに支払われ、チームの口座に貯蓄されます。しかし悲しいことに、所得税が課せられています。どの期間も、一定割合の税金を払う必要があり、一日の間で50%を失う様になっています。
新車は提出された後、すぐに公開されます。利益が発生するのは、公開されてからちょうど一期間後からです。
各チームの得点は公開され、各期間の終了と同時に更新されます。しかし、上位5位までの得点はハイスコアの一覧から除かれています。上位者は点検のためソースコードを提出する様に要請され、勝者は9月のICFPカンファレンスで発表されます。
自動車の仕様
自動車のエンジンは燃焼室(chamber)の一覧によって与えられ、各燃焼室はアッパー・パイプ(Upper pipe)とロワー・パイプ(Lower Pipe)と云う二つのパイプを搭載しています。パイプは幾つかの区域(section)が並んだものです。パイプは外気を吸い込む機関です。外気は自由に使うことが出来、実際には何種類かの物質の混合気体です。
各区間内では、左隣の区間からの物質と燃料タンクから直接供給される燃料による化学反応が起きていて、生成物は右隣の区間に供給されます。最終的に、両パイプの生成物は差動機関(Difference Engine)に運ばれ、機械の動力に変換されます。タンクから各区間への配管は自動車の製造者が設計したものになっています。
下の図を例にとると、ある自動車が0番, 1番の二つの燃料タンクを搭載していて、ただ一つの燃焼室だけから成ってい、パイプは二本あります。アッパーパイプは二つの区間から成り、両方ともタンク0と接続されていて、ロワーパイプは三つの区間から成っていて最初と最後の区間はタンク0、真ん中の区間はタンク1と接続されています。
upper pipe: -> section -> section ------------.
/ / / \
/ fuel 0 --<----------'--------. difference positive
air \ \ engine ---> energy
\ \ \ /
\ lower pipe: -> section -> section -> section -'
/
fuel 1 ---------------'
正規の自動車
自動車は次の条件を満たす時だけ、公道を走ることが出来ます。
- 燃料タンクの数は最大6つ
- 標準化されている(normalized)こと
- 結合的である(connected)こと
ある自動車を、燃焼室の順番の入れ替え・燃焼室の複製・燃料タンクの順番の入れ替えを経て別の自動車に変形出来た場合、その二つの自動車は等価(equivalent)なものであると見做します。自動車が『標準化されている(normalized)』とは、その三進表現(ternary encoding;下記参照)が、他の等価な自動車のものの中で最も小さい(辞書順で)ものである、と云う事です。
結合性(connectedness)の定義は次の通りです。
今、ある燃焼室Cのいずれかの区間(section)のアッパーパイプにタンクs が接続され、またある区間のロワーパイプにタンクt が接続されているとき(訳註：同じ区間でも違う区間でもいい)、タンクt は タンクs に依存している(depends on tank s)と云うことにします。また、s から依存性を辿っていって t へと辿り着けるとき、s は t に間接的に依存している(indirectly depends on t)と云うことにしましょう。
自動車が結合的(connected)である、とは、どんなタンクの組(s,t)についても、t が s に依存していると云うことです。上の節で例示した車は、タンク1からタンク0への依存性がないため、結合的ではありません。
燃料
どの区間でも、燃料は気体と反応し、それによって次の区間への気体の成分が変化します。この変化は線型です。つまり、タンクc と接続されている区間から出力される気体成分 k の量は、次の式で与えられます。
out(k) = c(1,k) * in(1) + .. + c(n,k) * in(n) ただし、 in(i) は入力気体中の 気体成分 i の量
自動車に燃料を供給するにあたって、製造者は各タンクc について、中身の燃料を特徴づける c(i, k)の値を決定しなくてはなりません。
気体は多くの成分から成っていますが、そのタンクが扱う成分の数 n を選ぶことが出来ます。
各成分k について、アッパーパイプの出力に含まれるkの量が、ロワーパイプのそれと同じか上回ったときに限り、差動機関は作動します(訳註：駄洒落ではない)。この条件は、気体の状態に依らず、つまり吸入される気体の物質構成に依らず、常に成立していなくてはいけません。
気体の一番目の成分は特殊な役割を果します。吸入気体は常にその成分を含み、燃料との反応でその量が減少することはなく(つまり c(1,1)の係数は常に正であり)、そうでなければ差動機関は動作しません。
製造者は、燃焼室のうち幾つかをメイン燃焼室 (Main chamber)として指定します。メイン燃焼室のアッパーパイプから排出される第一成分の量は、ロワーパイプの排出量を厳格に上回っていなくてはいけません。それ以外の燃焼室は補助燃焼室となります。
三進ストリーム(Ternary Streams)
ICFPコンテストは、そんなに生易しいもんじゃありませんよ。
自動車も燃料も、その説明は構造的データとして与えられます。実際には、自然数のリスト(複数)、自然数のリストのタプルのタプルの…のタプルのリスト(複数)、そして自然数のタプル(複数)です。
自動車・燃料のデータは両方ともにトリット(trits; 三進数のビット)のストリームで表されます。さて、もう皆さんうすうすおわかりと思いますが、データについてはこれ以上の解説はここではしません。ストリームパーサのエラーメッセージから頑張って類推してください。
幾つかヒントを出しましょう。コードはどんなに大きな自然数も、どんな長さのリストも扱えます。リストはそれ自身境界を持ち(!!FIXME!! 原文：code is self-delimiting)、実際、燃料のデータのあとのゴミデータは無視しますが、自動車の後のゴミデータは無視しません。また、コードには冗長性(redundancy)がありますが(つまり全てのトリット列がコードの語(word)とは限りませんが)、そんなに多くはありません。
例えば、以下はある自動車を表わす三進コードです。
221022000022010112201010022001122011110220010
回路
まだ簡単そうだとおっしゃる？大丈夫！まだ他にも障害はあります。燃料のデータをそのまま数字で送信することは出来ません。その代わりに我々の与えるある入力列から目的のストリームに変換する工場(factory)の仕様書を与えなくてはいけないのです。
工場は、ゲートと導線から成る回路です。どのゲートも二つの入力と二つの出力を持ち、導線は出力と入力を繋ぎます。どの入出力端子とも、ちょうど一つだけの導線で繋がれていなくてはいけません。"前むきな(goes forward)"導線は情報を即座に伝達し、"後ろむきな(goes backward)"導線は遅れて伝達します。
また、外界とのやりとりのために、どの回路も入出力端子をひとつずつ持つ "外部(external)"ゲートを含んでいなくてはいけません。回路の入力ストリームは外部ゲートの出力から現れ、回路からの出力は外部ゲートの入力端子に送信します。
こうして、工場は燃料を表わすストリームを生成することになります。工場のサイズは内部のゲートの数であり、小さい工場ほどより効率的です。(これは採点に重要な点です。)
もうわかってると思いますけど、ゲートの意味論も回路の構文もここには書きませんよ。その代わり、鍵回路の例をここに書いておきますか。
19L: 12R13R0#1R12R, 14R0L0#4R9L, 9R10R0#3L8L, 2L17R0#5L9R, 15R1L0#10R13R, 3L18R0#6L15L, 5L11R0#13L12L, 19R16R0#11R8R, 2R7R0#11L10L, 1R3R0#18L2L, 8R4L0#16L2R, 8L7L0#15R6R, 6R0R0#14L0L, 6L4R0#14R0R, 12L13L0#17L1L, 5R11L0#16R4L, 10L15L0#17R7R, 14L16L0#18R3R, 9L17L0#19R5R, X18L0#X7L: 19L
そして入力は：
[0,2,2,2,2,2,2,0,2,1,0,1,1,0,0,1,1]
出力に関しては、自分で頑張って見付けて下さい。最初の17個の出力は「鍵」と呼ばれ、解答をエンコードした三進ストリームの冒頭に必ずついていなければダメです。
どんな回路でもサーバに送信して、出力の最初のトリットを見ることが出来ます。
サーバーは上のストリームとは違う入力ストリームを使っているので、「鍵回路」をそのまま送信しても、直接的には役に立ちませんよ。
戦略上の注意
コンテストの初期には、回路を 自動車#0 (三進コードで "0")の解答として送信しましょう。この自動車は、燃焼室もなければ特別な燃料も必要としないという、一風変わった自動車です。この自動車は鍵接頭辞を特定するためだけにあります。
鍵接頭辞を出力する回路を送信した瞬間、最初の配当が支払われます。もちろん遅くなれば、取り分は小さくなるでしょう。
自動車を72台送信し終えても、他の自動車用の燃料を作ることで、よい利益を得ることが出来るでしょう。
Lightning部門での得点は、ちょうど24時間後に採点されます。
