してみた、というのが本記事の趣旨ですが、この記事はtwitterにフィードとして流れる予定です。ややこしいな。

mastodonについて

このブログの投稿はwordpressの連携機能でtwitterに流していたし、そこ経由で読みたい人もたくさんいると思うしまぁそれはいいか、とは思ってた。んだけど、なにか反応があったりするとそのために読むのはかったるいし、あんまり考えたくないなという気持ちになってきた。なのでいったん止めることにします。というか前回の投稿で止めてたのでシェアされてないんだけど、止めたことをお知らせする必要はあるんじゃないかと改めて思ってこんな記事を書いています。

twitterで出てきたときだけ読んでいたという奇特なお方は、RSSリーダなどで読むか、またはmastodonではシェアしたりするかもしれないのでそっちをご覧ください。あるいはなんだろうな……wordpress.comがactivitypubに対応してくれたらいいんですけど。Automatticがんばれ。というかtumblrがActivitypub対応するって話はどうなったんだ。

3月14日に嵐がサウスベイを襲った。雨はそれほどでもなかったが風が強くてどうかなあと思っていたら家のインターネットが落ちてしまった。数時間で復旧するかなと思っていたら、24時間たってもまだ落ちている。

調べてみたら偶然うちは大丈夫だったが近所に停電が広がっているらしい。その停電も続いていて、たぶんインターネットの設備が停電エリアにあるので落ちたままなんではないか、という気がする。なかなかのおおごとである。今回はベイエリア全体で15万世帯とか停電しているらしい。

https://chihouban.com/?p=13694

停電しなかったのはよかったがしかし、インターネットがないと本当の意味で仕事にならないので、今日は回線を探し求めて外出した。ノマドワーカーだ。

最初に向かったのは図書館で、ここはけっこうよかった。同じような境遇の人々がいて混雑していたがなんとか空き席を確保して仕事ができた。インターネット回線も速くはないがふつうに安定している。ありがたい。

昼食を食べるために離席して、ついでに移動もするかとRed Rockカフェに行ったが、ここは停電で閉店していた。ダウンタウンはおおむね停電の影響がなくてみな営業していたけど、ここの区画だけ停電があったらしい。

そこからは新しい場所をさがしてすこしさまよい、カフェに行ったりして仕事をしていた。図書館もカフェもどこもそれなりに賑わっていた。平日ふだんどれくらいの賑わいなのかは知らんけど、やはり自分と同じような境遇の人が多いからだと思う。

学校も閉鎖していたりするので子連れの人たちもよくみかけた。子供を座らせて宿題をやらせているな……という母親をみかけたりした。

ちなみに台風一過かどうなのか、今日は素晴らしい天気で青空が広がり、すこし暑いくらい。ぽかぽかとしたいい一日だった。これほどいい天気だがしかし停電トラブル、という対比はなかなかにシュールであった。

それにしても停電もインターネット断もなかなかのおおごとである。強風や大雨で落ちるのはめずらしいが、このへんだとまあ、たまにあるなという感じ（こんなに長期なのははじめて体験したけど）。一方、これくらいの強風は日本のほうがおおそうなものだが、倒木やそれにまつわる停電とかはあまり聞いたことがない。なんでなんだろうな、というのは気にはなる。

首都圏はそこまで木が多くなくよく管理されているので、強風で被害がおきそうなやつは切っちゃったりするが、このへんはそういうのを放置しがちだし巨木も多くてそういう管理が大変だからではないか、というのが妻の説。このへんは人口が東京みたいに密ではないので送電網もsparseになっていてresilienceが低いんじゃないか、というのが友人の説。どっちもありそう。両方の組み合わせだったりするのかもね。

明日もまだ断線していそうだ。明日はどこに出かけるかな……

前回の記事を書いてから、考えてるだけじゃだめだなとすこし書いてみたところいろいろわかった。

Rcによるリスト

Rcはリファレンスカウントで管理できる。RcはWeakをつくれるので、たとえばnext方向にRcをつなげておき(先頭ノードはリスト本体が保持)、prev方向へはWeakを持たせればいいのではないか？　と考えてみたのだった。

やってみたところこの方針では書けないということがわかった。Rcの参照先は基本的には更新ができない。ノードを追加したらprevやnextを書き換えないといけないけど、書き換えができない。書き換えをするには mutable なリファレンスを一時的に獲得する必要があるが、weakも含めたリファレンスカウンタが1でないといけない(これは安全性のためだろう)。prevとnextで基本的にノードにはstrongが1つとweakが1つ常にあるので、mutableなリファレンスを獲得できない。

なのでこの方針で書くことはできないのだった。マジで？

Arc / mutex によるリスト

ArcはRcのようなリファレンスカウンタだが非同期でアクセスできるようになっている。mutexと組み合わせると一時的に書き換えができたりする。どう考えてもオーバーヘッドが大きいから現実的じゃないけど、これならRcの問題は解決されるんじゃないだろうか？

解決される、というふうには思う。だが問題があった。要素の参照を返せないのだ。

たとえば、先頭要素を返す front() メソッドを書いてみたとする。こんな感じになる。

pub fn front(&self) -> Option<T> {
    if let Some(n) = &self.head {
        let node = n.lock().unwrap();
        Some(node.element.clone())
    } else {
        None
    }
}

このコードでは結果の値を clone して返している。単純に&node.elementとする場合、そのライフタイムはnodeのライフタイムに縛られる(Mutexのlockというのはそういうものだ)。なので返される値はifの中が終わった瞬間に無効になるのでコンパイルできない。

こういうインタフェースを実装していくのは可能だが、cloneできるものに限定するのもイマイチだし、要素アクセスのたびにcloneされるのはまったく現実的ではなさそうだし、要素を書き換えたいときのイディオムが変わってしまう(front_mutみたいなものは書けない)。イテレータのインタフェースも標準的なものとは変わってしまう。

というわけで、やはり現実的ではなさそうだ。

他の誰かに所有してもらう

ノード間でオーナーシップを持つのはおかしいんじゃないかという気がする。ノードのオーナーはリスト本体であってそいつが所有していればいい。あとは適当にリファレンスを持てばいいんじゃないか。こんな感じ。

struct Node<'a, T> {
  element: T,
  next: Option<&'a Node<'a, T>>,
  prev: Option<&'a Node<'a, T>>,
}

struct LinkedListVec<'a, T> {
  nodes: Vec<Node<'a, T>>,
  head: Option<&'a Node<'a, T>>,
  tail: Option<&'a Node<'a, T>>,
}

ノードをベクタで管理していて連結リストとは……という気持になるが、適切にreservedなサイズを増やしていけば追記するだけならamortized costはO(1)なのでいいんじゃないか。本気でやるなら削除したノードを管理しないといけないが……。

だがどうもライフタイム解析で失敗してしまい、うまくいかない。リストがノードを保有していてその生存範囲では有効ではあるが、そのようなことをうまく表現できていないような気がする。

というわけでこの方向性もうまくいかなさそうだ。

ちなみにだが、next/prevをusizeにしてしまい、nodesの中の場所をインデックスで指定する、という方法ならたぶん大丈夫だと思う。しかしそれはなんというかもはや、nodesをメモリ領域にしてインデックスをポインタがわりにしているのとほぼ同じことである。そりゃまぁ unsafe という言語機能は使わないが、インデックスの先がほんとうに生きているものかの保証があやういので(途中でノードを破棄したときとか)、ぜんぜん安全な感じがしない。さすがにアホっぽい気がするのでこれは試していません。

まとめ

というわけで、double-linked-listをsafe Rustの範囲内で作るのはどうも無理っぽいというので正解という気がする。raw pointerとunsafeバリバリなstdのリスト実装が一番現実的なのであった。そこまで複雑じゃないからね、という話なのかもしれない。

しかし、linked listていどのことすら適切に表現できないような言語仕様というのはどうなんだろうか。どうも自分は不思議な気持ちになるんだよな。なにかもっとうまい仕組みがあったりしないんだろうか？

ところで single-linked-list なら、まぁ Box とかを使えばいけそうな気がする。双方向イテレータも zipper とかを使えば実現できるんじゃないかな。でも実際にやってみたらいろいろ罠があるんだろうか。

なんかそろそろまた入門してみるか、という気持ちになったので勉強してみることに。

なにかしらちょっとしたものを作ってみるぐらいがいいかなと思うが、プロジェクトアイディアをさがしていても進まないのでまずなにかを読んでみることにした。とりあえず std にある linked list のコードを読んでみた。あと deque と binary heap。このへんは単純。 B-tree も読んでみようかなという気がするが格段に複雑になるね。

linked list はつくりは単純なので理解はできるが、わからないこともあったので疑問を書いておく。

linked list は基本的に NotNil (ほぼ raw pointer のラッパ)を使っていて、unsafeだらけだ。なぜだろうか？

第一に std の linked list は double-linked list で、各ノードはバックリンクを持つ(リスト本体も先頭と同時に末尾へのポインタをもち、push backがO(1)でできるようになっている)。single-linked listならオーナーシップを連結させればよさそうな気がする。

2つのオブジェクトが相互にリファレンスを持っているというのは単純な循環リンクなので、たとえば単純なリファレンスカウント (Rcなど)では適切に管理できない。drop時に適切にリファレンスカウントを減らすようなコードを書かないといけないが、それならraw pointerを開放していっても手間がいっしょ。ただRcからweakをつくれるようだ。それならできる？

そもそも単純に、あるノードが次のノードの所有権を持つとすると、そのノードのライフタイムは確定できるので、次のノードが前のノードへのポインタを持っていても安全性は保証できそうな気がする。安全なweakポインタというか。そういうのってないんだっけ？　あったらこんな仕組みになってないとおもうので、ないんじゃないかという気がするけど、どうして存在しないんだろう。こんな単純な例ならいいけど現実的にうまく解析できないとか、そういう理由なんだろうけども……。

疑問の2。raw pointerを使えばいいような気もするけど Option と NonNil を組み合わせているのはなぜ？

これは単純で、raw pointerはnilかどうかをチェックするのもunsafeになってしまうから、かなぁ。

https://zenn.dev/anatoo/articles/14612f027194e5

なんか「詰められている」ように受け取られてしまう、というのはちょっと日本文化的な気もするが(というかコードレビューで詰めたりするなという気がするが)、質問だけだと意図が伝わらないということはまあよくあるという気がする。

でも自分はタグみたいなものは使わないかな。「これなんでですか?」みたいなコメントは、そのコメントで解決したいことが明らかではない気がするから。もうすこし言葉を増やして解決可能なコメントにするのが良いと思う。

たとえば「この行、必要なんでしょうか。上のほうでこういうことをしているから、これなくてもいいと思うんですが何か見落しているんでしょうか」とか。あるいは「この部分はデバッグ用のやつでは」とか。または「メインの変更と関係ないので別PRに分けてください」と言ってみたり。

「本当に意図がわからないので教えてください」ということはあるけど、「なぜこの変更が必要なのかコメントも書いてください」というお願いをしてみたり。

まあだんだん簡潔になりがちなんだけど、なぜ?というコメントはそもそもよくないものなので、自分がなにを解決したいのかに沿ってコメント内容を変えるべきなんじゃないか、ということを思った。

……と思ったけど、タグ、まあ使うこともあるな。主に nit: というやつ。これは nitpicking の略で、重箱の隅をつつくようなタイプのコメントを意味する。本質的ではないのでどうでもいいっちゃいいんだけどいちおう指摘します、みたいなときによく使う。たとえば変数名がミススペルしてるよとか。

定型的な書き出しでコメントの意図を制御することもある。just curious / out of curiosity というのは変更してほしいわけではなくて教えてほしいんですが……という意図だし、you don’t need to change this PR but … みたいに「いまやる必要はないと思うけどこういう問題が起こることもあると思います」みたいなことを言うことはある(後者はだいたいTODOコメントするかバグをファイルしてあとでやりましょう、みたいな方向にもっていく)。

でもまあ、タグみたいなものよりは全体的にコメントは長めにしておくことで意図を伝えるほうが一般的には良い方向性だと思う。

クリアした。

なかなかよかった。雰囲気ゲーム。寂寥感のある雰囲気がいい。盛り上がりもなにもない、ひたすらチルなゲームだ。

村の住人のひとりが不思議な悪夢をみた。長老によると「季節」の終わりが近づいているのだという。主人公はいまの世界のありさまと「季節」のおわりを記録するために村を出て旅に出ることにする……といった設定。プロモーションではあんまりはっきり書かれていなかった気がするが異世界が舞台で、この世界はどうも「季節」というものが移りかわることで世界がはっきり変化してしまうようだ。繁栄していた黄金の季節、戦争の季節、そしてまだ名前のついていない今の季節……。

ゲームプレイは、舞台となる世界のあちこちを行って、いろんなものを観察したり、写真に収めたり、レコーダーで録音したり。そういう素材を、もっているノートにまとめていく。それだけ。まとめるのもいろいろ凝ってデザインしてもいいし、雑にペタペタ貼るだけでもいいし、まあべつに何もしなくたっていい。基本的なことだけでストーリーは進んでいく。

ゲームとしては小規模のゲームで、数時間もやっていれば終わる。もうすぐ世界が終わる(変わる)というぼんやりとした寂寥感と終末感を味わうようなゲームだ。内省的なモノローグ、思わせぶりな台詞や世界観がなかなかいい。

クリアしたのでレビューを読んでいたらkotakuのレビューではコテンパンに批判していたが、あまり納得のいく批判には思えなかった。が、このレビュアーのような期待感をもってプレイする人というのはいるだろうし、そこには向いていないだろう。まぁ内容こんだけかとか、これで終わりなのか、ってなるもんな。

Season

唐突に手元のゲーム機でプレイできることに気づいてやってた。2021年にいきなり発売されたロードス島戦記のゲーム新作。ディードリットが主人公のメトロイドヴァニア。

https://en.wikipedia.org/wiki/Record_of_Lodoss_War:_Deedlit_in_Wonder_Labyrinth

自分程度でもクリアできるぐらいの難易度で、かと言って簡単すぎるということもなくて割といい塩梅でよかった。ただ歯車に矢を当てて回すギミックが苦手で、かなりうんざりというところが途中に何度かあったけど。

ストーリーは、まあそういうんだろうなという展開でしかないが、良かったんじゃないでしょうか。知ってるキャラが出てくるだけでなんだか懐かしい、というのもあるがそれを通り越してもう何十年も触れていないコンテンツなので単語は知ってるけどどういうんだったっけみたいになってしまっていた。

非常におっさん向けなコンテンツという気がするけど、ターゲットな人たちはプレイすると楽しいんじゃないでしょうか。

https://us.macmillan.com/series/monkrobot

なんとなく本屋で見かけて手に取った本だけどかなり面白かった。『銀河核へ』の邦訳もあるベッキー・チェンバースのシリーズで、中編2本で構成されている。一本目のタイトルは A psalm for the wild-built、二本目のタイトルは A prayer for the crown-shy。

パンガという世界が舞台で、そこではロボットたちが自意識に目覚め、人間と別れて生きることを決めた。それから時は流れ、人類はAIや知的なロボットといった存在とは無縁の生活をしてきた。人類の住むべき領域と、ロボットたちの領域である Wild が分かれ、人間たちは自分たちの領域で生きてきた。時は流れ、ロボットたちの存在はもはや神話のようになっていた。

主人公のデックスは tea monk という、悩みを持った人に茶を提供しつつ話を聞くといった仕事をする人間。 tea monk としては成功を収めたデックスだが、人生に思い悩み、本当にちょっとした理由から禁断の Wild に踏み込んでしまう。そこで出会ったのがロボットのモスカップ。モスカップもモスカップで、長い時をへて改めて人間と接触しようとしていたロボットだった。ロボットたちの質問は一つ — 人類は何が必要なのか？ (what do people need?)

デックスとモスカップはそれから Wild を少し探索し、そして次に人間社会に出ていく。一作目は主にロボットたちの生態（というのかなんというのか）やあり方が詳しく描かれ、二作目は人間社会が詳しく描写されている。どちらもそれなりにユニークで興味深い。デックスとモスカップのユニークなキャラクターも味わいがあり、二人の対話も飽きさせない。どちらの作品ともちょっと癒やしっぽいオチがついていて読後感も悪くない。いや面白かった。正直なところ、『銀河核へ』は翻訳で読んでいて途中でダレてしまって投げ出したのだけど、英語で読み直そうかなと思ったぐらい。

本作は「ソーラーパンク」として書かれたと言われていて、自分にはあまり詳しくない用語だった。サステナブルエナジーとかエコみたいなテーマを扱った作品ということで、2009年に提唱されたものらしく、作例はそれほど多くはないようだった。事後的にル=グウィンの『オールウェイズ・カミング・ホーム』や『所有せざる人々』がソーラーパンク作品ということにされているらしい。なるほどそれでこういう人類社会なのかね、と腑に落ちるところもあったりした。

そういうわけでなかなか良かったのだけど、本作は邦訳は非常に難しいんじゃないかなという気がする。それは主人公であるデックスの性別に起因する。デックスは男性でも女性でもなく、作中では常に singular-they が使われている。修道僧（モンク）なので敬称がつけられるが Sibling と呼ばれている（Sibling Dexという表記が多い）。が、すべての人がそうなのではなく、男性なら僧なら Brother がつけられるし、でなければ Mr. がついたり he で呼ばれる人もいるし、女性なら Sister / Ms. / she が使われている。デックスは特別な存在ではなく、ほかにも Sibling や Mx. のついた登場人物は普通に出てくる（ちなみにロボットには it が使われている。モスカップ自身がそうしろというくだりもある）。

この人類社会の性別はどのようになっているんだろうか、というのは興味の一つでもあったし、これが解決しないと翻訳は難しいだろうなという気もする（解決してもぎこちない翻訳になりそうでそれはそれで興をそぐ気がする）。が、2作で終わりだということだがその辺はあまりはっきりとは説明されなかった。単に自己の決定によって Sibling / Mx. / they を選択するのか生まれながらそうなのか、外見だけでわかるような違いがあるのか、みたいなことが気になっている。LGBTQテーマのSFとしてはそこは追求するべきではないような気もするし、だからこそちょっと曖昧なところで終わらせてるような気もするけど、翻訳するとしたら大変そうだなと思った。

短いしそれほど難解な話ではないので、英語で読んでも大丈夫な人は読んでみてください。おすすめ。

年末年始にかけて日本に2週間ほど滞在していた。といっても主に親戚との年末イベントがメインで、あまり人にあったりしなかった。子がまだ小さいこともあり、映画を見たりといった余暇もなし。本はちょっとだけ買ったが子供の絵本が多かった。

日本の生活

今回はairbnbで部屋を借りた。子供が小さいので、家具や食器・台所付きで寝室が分かれている部屋というのが助かる。都内ということで蒲田近郊に滞在していた。外食はそこまでせず、基本的には部屋で自炊。それか親戚の家にいくか。

前回に帰った時も思ったけど、「まいばすけっと」がそこらじゅうにあってとにかくびびる。なんなんだろうあれ。東京で一番店舗数のあるのまいばすけっとなんじゃないか。あんなに店舗があって利用客がいるものなんだろうか。こちらもある程度は自炊するのであると安心感はある。が、結局は普通のスーパーマーケットの利用がメインでまいばすけっとはそこまで使わなかった。

パンデミックの影響なのかどうかは定かではないけど、クレジットカードやコンタクトレスな支払いのオプションはかなり充実してきたと思う。現金の利用は結構減ってきたなという感じがある。まだ必要ではあるけれど。

zipair

行き帰りの飛行機にはzipair Tokyoを使った。zipairはLLCで、とにかく安かった。サンノゼ-成田便は就航してすぐということでご祝儀価格で割引だったのかね。あそこまで安いなら仕方ないというぐらいの安さ。

ただ安かろう悪かろうということはなく、体験はかなり良かった。まず機体はBoeing 787なので広く快適だった（zipair全体で787しか使わないことでコストを削減するということもあるらしい）。フルフラットシートもあるが、6歳以下の人は使えないという制限があり、そちらは使わず。職員やCAの人当たりも日本らしく丁寧。

一方で予定変更が一切できず、様々なものが有料化している。例えば預け入れ荷物も有料で、重さによって値段が変わる。機内食も有料で事前に頼んでおく必要がある。水すら有料なのはちょっと困った（水筒を持って行って入場後の空港で汲んだりしたけど足りなくなったりした）。また席にはディスプレイが付いていないので、機内で暇つぶしをするには自分の携帯電話かタブレットを利用しないといけない。

とはいえ実際には機内食そんなに美味くなくて微妙な気持ちにもなるからなくてもいいや、子供向け機内食もほとんどベビーフードみたいになっていて自分の子にはそぐわない、といったこともあるから、機内食がオプショナルなのは意味があった。今回行きは（自分用には）smash burgerを買って、帰りには寿司岩の鯖棒鮨を買っておいた。子供にも子供用の食事を持っていくことにした。

席にはディスプレイは付いていないが、実は機内エンターテイメントシステムが存在しているというのも面白かった。機内wifiが完備されていて（インターネットにも繋げるという話だったがこれはほとんど使えなかった）、機内wifiから機内サービスに色々アクセスできる。食べ物の注文や現在位置の表示のほか、機内wifiからだけ見える映像コンテンツ（映画とか）もあった。事前にNETFLIXとかでデータをダウンロードしておいたんだけど、そこまでする必要は実はあんまりなかった。なので意外と機内の体験は悪くない。

天候の問題で欠航になったりするとかなり困る気がするが、そういうリスクを除いてはzipairかなりいいという印象。

wingz

空港と自宅の行き来にはwingzというアプリを使った。Uberみたいな配車サービスだが空港送迎に特化していて、皆の車がデカかったり、チャイルドシートを指定できたり、航空便の予定に合わせて予約できたりする。子供が小さいので（この記事そればっかりだが）チャイルドシートがあるというのが大きい。普通の配車サービスやタクシーでは対応できないからね。従来型のシャトルサービスでも良かったが、アプリというだけあって体験は色々良かった。担当してくれたドライバーの人も感じがよく良い体験だった。

その他の事柄

時差ボケ。一般にアメリカから日本への方向の時差ボケは楽で日本からアメリカの方向はきついということが言われている気がするが、今回は日本の最初の数日の時差ボケがひどかった。夜中の1時に爽快な感覚で目覚めてしまい、同じ頃に起きてしまった子と「もう朝かね、おきますか」と起きてから時間を確認したら深夜でびっくりしながら慌ててふたたび寝かしつけるという失態を犯したくらい。逆に日本からアメリカの方向では、夕方に乗ると朝に着く時間帯の便だったことと、子供の世話のサイクルに気を取られたからか、今のところそれほどキツさを感じない。もっとも妻はアメリカに戻ってからの時差ボケがかなりキツそうなので人によるとしか言いようがない。

上野の科学博物館に行った。特別展（毒展）は並んでたので常設展のみだったけど、よく考えてみると常設展をじっくりみたのは初めてかもしれない。フタバスズキリュウの展示とか見応えがあって良かった。

川崎水族館にも行った。カピバラに餌をやったりした。あとしながわ水族館（品川駅近くにあるやつではなく大森海岸にあるやつ）にも行ってイルカのショーを見たりした。多摩動物公園にも行った（坂がすごくて子供を抱えての移動が結構な運動になった）。子供にこういう体験がよかったのかどうかはよくわからない。子供はグッズ販売エリアのガシャポンのレバーをガチャガチャ動かすのが楽しいようでそこでずっと遊んでいたような気がするが、まあそれでよし。

https://anond.hatelabo.jp/20221129085814

なかなか面白いテーマだと思った。実際のところ、平常の仕事で必要かどうかでいうと全然必要ないんだよね。知っておく必要は特にない。もちろんフレームワークを作ったりプログラミング言語を作ったり、いろいろ必要な局面がありうるとは思うけど、たいていのソフトウェア技術者のたいていの仕事には必要な局面はごく稀。それは別にbigtechの従業員でも同じと思う。

そういえば圏論についてこんなことを書いたことがあった。これは今でも間違っていないと思う。https://qr.ae/pr7ITC

なのでまあ必要に応じて学んでいけばいいし、永遠に必要にならないこともたくさんある。そもそも学部レベルで学ぶような内容は（大学にもよるでしょうが）そこまで広い範囲でもなくカバーしていない分野も多いし、一方ですごく深く理解できるようになるかというとそこまででもないという気もする。

けど実際のところ体系的に学んでいないと必要に応じて学ぶというアクションを取ることができないというか、そのような選択肢に思い至らなくていろいろおかしくなってしまうということがあるんじゃないかなぁ。という気がする。

そういえば昔こんなことがあった。Google日本語入力チームで働いていたとき、軽く雑談しましょうとのちのPFNの人たち（当時PFI？設立前？どっちだったか）と話したことがあった。その雑談の中で、こんなふうに辞書データを圧縮していてこういうデータ構造を使ってるんですよね、まあこれが最適かどうかはわからないんですけど……みたいな話をちょっと話したところ、岡野原さんがさっと立ち上がって、軽く計算してみましょうか、とホワイトボードにざっくりとした概算を計算しはじめ、理論的な下限がこのくらいだからかなりいいんじゃないですか、みたいなことをパッと言ったのだった。

CSの学位があればこういうことができるかというとそれだけではないわけだけど（こちらもCS系の学位を持っている人はたくさんいた）、ないとできないようなタイプの議論とか考え方というものはあるのだと思った。