浮動小数点数のビットレベル表現を print する
浮動小数点数は IEEE-754 という規格で標準化されている。たとえば32ビットで表現するとき、上位1ビットが符号に、次の8ビットが指数部に、残りの下位23ビットは仮数部として割り当てられ、これら3つのフィールドが合同してひとつの浮動小数点数を表現する。
あるいはこの図をみると「ああ、あれね」と思い出すこともあろうかとおもう。
32ビットの整数値を浮動小数点のフォーマットに変換するエクササイズをやっていて、困ったことがあった。それは IEEE-754 に準拠したビット表現を手軽に print する手段が提供されていないことである。たとえばこれは動かない例である。気軽に %x で16進数を書き出そうとしている。
float f = 1.0; printf("%x\n", f); // warning: format specifies type 'unsigned int' but the argument has type 'float' [-Wformat]
実に、 printf の %x オプションは unsigned int を要求していて1、何も考えずに float を突っ込んで魔法のようにうまくいくことはない。
かといって、 IEEE-754 に準拠した print を自力で実装することはできない。そもそも標準規格への理解が足らないがゆえに print を欲しているわけで、何かしらうまく動くプログラムを他力本願に望むほかなにもできない。
で、 StackOverflow にてそれに近いものを発見した。リンクはこれである。あらかじめ告白すると、いったいなにをやっているコードなのかはわからない。わからないながらに、少なくとも便利に使えるとは判断できるため、いまの未熟な理解度を記録する目的も込めて書く。
それがこんな関数である。
void print_i3_754(float r) { union { float f; unsigned int u; } f2u = { .f = r }; printf("0x%.8x\n", n); }
使ってみよう。
int main() { int x = 3'510'593; float y = x; printf("0x%.8x\n", x); print_i3_754(y); return 0; } // x = 0x00359141 // y = 0x4a564504
と、期待通りの表現が得られた。
整数オーバーフローをコントロールすることの難しさ
C++ で競技プログラミングをやっていて、整数オーバーフローに泣かされたことのない者はいないだろう。僕とてそうである。ちょっとしたケアレスミスにすぎないのだが、些細なミスであるからこそ、それを繰り返してしまうとことさら不甲斐なく感じる。
オーバーフローを機械的に防ぐ方法はないだろうか？「気をつける」以上のシステマチックなやり方で回避することはできないか？ と、まるで障害報告書を書くような気持ちで何度も振り返るも、いつも結論はでないままだった。
いま、 CS:APP を読んでいて、いまいっぽぼんやりしたまま寝かせていた考えに光が当てられた気がするので、今回はそれをまとめようと筆をとった。
あらかじめ述べておくと、結論としてはありきたりな表現にすぎない。クサいところはより大きい幅を表現できる整数型を使おう、というところに着地している。それ以上でもそれ以下でもない。
たとえば愚直に書いたこんな計算を考えてみよう。
int main() { int x, y; cin >> x >> y; int answer = x * y; cout << answer << endl; return 0; }
「x と y の定義域をはっきりさせろ！」とみずから苦情を出したくなりつつも、いったんそれはおいておく。いかにもオーバーフローしそうではある。
多くの場合、プログラマを困らせるのは「オーバーフローが起こる」という事象そのものよりも「オーバーフローが起こってもプログラムが止まらないこと」だったりする。オーバーフローが発生するときはランタイムエラーが起こるようになっていれば、見当違いのデバッグ方針を携えて右往左往することもない。
int safe_mult(int x, int y) { int p = x * y; if (x != 0) { assert(y, p / x); } return p; } int main() { int x, y; cin >> s >> y; int answer = safe_mult(x, y); cout << answer << endl; return 0; }
この関数をライブラリとして持っておいて、乗算をしたいときはいつでもこれを呼び出すか？ いや、それも片手落ちである。なぜなら結局のところ、ランタイムエラーは出てしまうわけで、それによって誤答ペナルティが与えられてしまう。オーバーフロー時にエラーを吐いて緊急停止するのは、そうでないよりはマシではあるものの、本当にほしいものはこれではない。
となると、結局のところは最初から64ビットを使ってこう書いてしまうのが手堅い。オーバーフローが起こったとして、まず考えられるのはこうして幅を広げることであるから、最初からクサイところはこう書くのが合理的か。逃げの一手でしかないが、僕程度の水準の競技プログラマにとってはこれで十分そうに思える。
int main() { long long x, y; cin >> x >> y; long long answer = x * y; cout << answer << endl; return 0; }
64ビットを使ってもなおオーバーフローするような入力が与えられるときはどうしようか？ そういうケースに遭遇したことはいまだないような気がするが、そのときこそこうなるか。
long long safe_mult(long long x, long long y) { long long p = x * y; if (x != 0) { assert(y, p / x); } return p; } int main() { long long x, y; cin >> x >> y; long long answer = x * y; cout << answer << endl; return 0; }
64ビットを費やしてもなおオーバーフローが発生する計算をするなら、このときこそエラーを投げて異常終了する。計算の仕方を見直すべきである。どうしても大きな整数を扱うのであれば、可変長の幅を表現できるライブラリなり言語を使わなければならない。しかし繰り返すが、そんなユースケースは滅多にあるものだろうか？
というわけで、なにか新しいインサイトを提供することはできず、ありきたりな議論に終始した。しかしこれまで書かずにいたものをこうして言語化したことの背後には、僕のなかでの学びがある。それはこういうことである。
整数オーバーフローに関するこの問題意識は、以前は単なる個人的なフラストレーションを動機づけとしていた。それ以上のものではなかったので、表立って公開しようとも思いはしなかった。しかしいま CS:APP を読むことを通して、これが実に普遍的な脆弱性の問題と直結していることを手応えとして知った。
たとえば FreeBSD の getpeername() が持っていた、符号付き整数と符号なし整数のキャスト時のオーバーフローによって、プログラムが不正なメモリ領域を読み取ることができる状態となっていた脆弱性 CVE-2002-0973。あるいはサンマイクロシステムズの XDR ライブラリが持っていた、同じく整数オーバーフローによって悪意をもってメモリ領域を破壊しうる状態になっていた脆弱性 CA-2002-25。
いずれをとっても、有力な C プログラマをもってすら、整数オーバーフローを排除するのは困難であるし、またそれが単なるバグではなく深刻な脆弱性を生むという観点を得られたのは、怖いながらもおおいに学びとなった。
僕はといえば、競技プログラミングをするだけの気楽な用途であるから、こう考えている。たとえば非負整数であっても int 型で宣言するのと同じような乱暴さで、 long long 型を多用して恥ずかしいことはない。実際、そのやりかたに一抹の恥ずかしさを覚えていたからこそ、 int と long long を使い分けようとしながらもうまく制御できず、不要なオーバーフローを引き起こしてフラストレーションを抱えていたわけである。恥ずかしさでいいプログラムが書けるわけではないから、合理でもって long long 型に活路を見出そうと思っている。
大型連休の振り返り (2021)
2021年の大型連休が終わった。いやすでにこどもの日でもって終わっているという向きもあるが、僕のなかでは今日の日曜日をもって「終わったなあ」という情緒であるので、振り返っておく。
arduino で遊んだ
LED をチカチカさせたり、電圧計の使い方を覚えたりした。
電子工作はまったく初心者だし、電気の知識さえ中学レベルで止まっているあたりが引け目になっていた。
『みんなの Arduino 入門』をウォームアップとして一周した。半日で終わるくらいのちょうどいいボリュームだった。大型連休の初日を楽しませてくれた。
本当は『CPUの創りかた』を読みたかったところ、秋葉原に部品を買いにいくというところがネックになり止めている。そもそも祝日に営業しているものかわからないし、それでも平時であればとりあえず出かけてみるのだが、どうせどこにいってもどこも臨時休業だろうし、と萎縮して出かけるのをやめた。
そのおかげで、これから書く別のトピックにも時間を割くことができたわけでもあるので、怪我の功名というか塞翁が馬というか、まあなるようにしかならない、という気分であった。
Leetcode で連結リストと木構造のレッスンをした
僕がいまの会社の入社面接を受けたときにはコーディング試験というものはなかったのだが、近頃になって導入を図っているらしい。Leetcode の適当な問題を指定して解いてもらう形式と聞いて、自分でもアカウントを取得してやってみることにした。
日曜日の週次コンテストに数回参加した。しかしコンテストというよりはむしろ教育コンテンツがメインのサービスだということがだんだんわかり始めた。
で、連休には Introduction to Data Structure というシリーズをやってみていた。やったのは Arrays 101 と Linked List そして Binary Tree である。
実をいうと、連結リストを自前で実装するのは初めてだった。競技プログラミングであればキューとかスタックを呼び出すだけの話なので、考えてみればそれはそうでしかない。やってみるとまあバグること。思わぬ無限ループをやたらに発生させていた。でも、うまくいかなくてイラつくというよりも、着実にエッセンスを学びとることができているという興奮の方が大きかった。その意味で、練習問題の質はとてもよいと感じた。
Linus が言っていた センスのいい単方向連結リスト のセンスのよさがわかるようになった。僕自身はというとセンスが悪いほうのコーディングをするのがまだ精一杯だが、少なくとも Linus が何を言っているのかがわかったことが嬉しい。
AtCoder で初めて水色パフォーマンスを出した
4月の最後のコンテストで レーティングが緑になった 。
たぶん三日天下で終わるんじゃないかと思っていたのだが、続けて出た5月最初のコンテストでは初めての 水色パフォーマンスを出すことができた 。まあこれも速解きの産物でしかなく、あまり実感はわかないのだが、結果は結果として喜んでいる。
しばらくレーティングが伸び悩んでいたので、このあたりが自分の実力の相場なのだろう、と卑下してしまっていたところがあったが、まだ伸び代はあるなと感じている。おりしも 典型90問 という企画も提供されていて、これも学びになっている。なかなか難しくはあるが、難しくてこそ学びがいがある。
そういう気分であるから、緑色になったことに満足して参加を止めるなんてつまらないことは言わないで、腕試しの参加はまだまだ続けたいとおもう。
DDIA を読了した
昨年末に着手した Designing Data-Intensive Applications を読了した。これは 別のエントリ として投稿した。
消費サイクルが激しい世の中にあって、ひとつの重要な本をじっくり読むというのは贅沢な経験だった。トレンドやマーケティングの波に振り回されずに、自分が重要と信じるものに粘り強く、真面目に向き合おうとする態度は忘れないようにしたい。
放送大学に行ってみようと決めた
これも別エントリにすでに書いているが、大事なことなので再訪する。
どこにも出かけられずに過ごす連休の真ん中あたりで、世の中の息苦しさにあてられていた。海外にでもいきたいなと随筆をした。これを呼水にして、いつかやりたいことと、なりたい自分の像、そしてそのためにいまできること、といった具合に考えが膨らんだのだった。
「理工系の大学で勉強したい」という願望のようなものは以前からぼんやりあったが、学位がほしいわけではないことははっきりとわかった。それよりも、いま仕事でも趣味でも眺めているコンピュータとプログラミングのパラダイムを、いまよりも高い解像度で捉えられるようになりたい、そのための勉強がしたい、という願望に言い換えられるようになった。
コンピュータの勉強であれば自走するだけの体力はすでにあるが、基礎科学的な勉強は独学するよりもまずはレールに乗って学ぶべし。そしてそのニーズを埋める場所として、放送大学はうってつけの環境である。そういう気持ちになっている。
まあ、これは向こう数ヶ月でまたアップデートするトピックではあろうが、いまのアティチュードとしてはこんなところである。
社内勉強会の予習をした
新しい会社にはいり、読書会という（僕にとっては）新しい形態での勉強会に参加することになった。『アルゴリズムとデータ構造』と『マイクロサービスアーキテクチャ』をそれぞれ読むふたつの会にサインアップした。
どちらも自分ひとりで勉強するのであれば手にとることはない本であったようにおもう。そもそも 「新刊本は買わない」というポリシー を掲げているわけで、あるいは書店で見かけていたのかもしれないが、基本的に見向きもしない部類の本である。
「新刊本は買わない」という2021年の目標には反する形になるが、まあこれは別として自分に許してしまうことにする。どちらもそこまで難解な本ではないし、週にそれぞれ1-2時間ほどを割り振ってやる計画で十分読める。
とりあえずは勉強会という新しい学びの形式を楽しめたらなと思っている。
指輪物語を読んでいる
現実に向き合うのがつらいのでフィクションばかり読むようになっている。このあいだまでは SF を多めに読んでいたのだが、だんだん科学よりもファンタジーを求めるようになった。「じゃあやっぱりここからでしょ」と言わんばかりに大古典を 全巻セット で購入し、読み始めた。
映画シリーズはひととおりみているが、原典を読むのは初めてである。しかし読み始めてみると、映画のイメージとは関係なく、とても新鮮な気持ちで読める。いい年してワクワクドキドキしながらページを繰っている。
なにせ壮大な設定が背後に控えているので、読むのも楽しいけど読み終わったら解説やら考察やらを知らずにはおけなくなりそうだし、映画も見直したいし、ホビットの冒険も読み直さなきゃいけないし、ととめどなくなりそうである。
これだけ楽しめるのは幸せとしかいいようがないはずなのだが、そうなるといよいよ時間のやりくりがたいへんになるなあとうれしい悲鳴をあげざるをえない。あのとき買ったビットコインを売らずに握っておけばいまごろはそれを換金してもう1年くらいは無職で好きなことだけやれたのかな...という現実逃避が頭をもたげるが、そういう空想にふけることができるのもファンタジー世界に心を半分持っていかれているからだろうか。ある意味で幸せなことではあるが、お花畑と揶揄されない程度には注意しておきたい。
CS:APP を読みはじめる
Computer Systems: A Programmer's Perspective の日本語訳、『コンピュータ・システム — プログラマの視点から』を購入した。通称は CS:APP というらしい。
値段、重量、厚みすべてにおいてヘビー級の一冊である。16000円だった。消費税で本が一冊買える。
しかしこうやって専門書を買う選択肢を持てるのが社会人のいいところであるよ、と感慨をもつ。しょっちゅうこんな買い物をしたいとはさすがに思わないが、必要を吟味していよいよ心を決めたときには、資本主義的自由の味がした。
情報処理学会の監修というから内容には全幅の信頼がおける。丸善出版というのもいい。この出版社の専門書を買うのは Effective C++ を読んだとき以来となるが、これもいい本であったのを懐かしく思い出している。
英語版にトライすることも検討した。しかしいずれ値段は大きく変わらないこと、加えてその厚み（日本語ですら800ページ超！）をおもうと、いよいよ英語では一年かけてなお通読できるかどうか自信がなかった。とはいえ結局のところ、学会の監修がついているという信頼がここでも効いてくる。翻訳のクオリティが最低であるということはまずないだろう、と安心して訳書を選ぶことができた。
これも teachyourselfcs.com の推薦である。職業プログラマがコンピュータ・アーキテクチャを学びはじめるのにうってつけの一冊とのことである。
これだけのボリュームを読み通して、やっとスタート地点に立てるようになる、というような紹介のされ方であった。「これさえ読めば」式の宣伝文よりはよほど誠実な推薦だとおもう。真実を言っているな、という確信がある。これを推薦してくれる人たちと、これを訳してくれたアカデミズムの人たちの助力のもとに、僕はまだまだ進歩できるという前向きな気持ちで取り組んでいこうとおもう。
Designing Data-Intensive Applications を読み終わった
昨年末に着手して、足掛け5ヶ月で読了した。
5ヶ月というとあまりに時間がかかりすぎているように聞こえる。実際には年末年始とこの GW で集中的に読んだ。しかも、後者の連休ではメモを取りながら読み進めることをやめて、読み終えることそのものを目標化して無理やり終わらせたきらいさえあるので、時間を尺度とすることには（そうでなくても意味はないが）ここではあまり意味はない。
分散システムにおけるデータの流れにフォーカスした著作である。どの章をとっても含蓄ある文章しかないので、要約するには僕の手に余る。無理に一般化して語るよりも、序説を概観した5ヶ月前のエントリをみてもらうほうが話は早そうである。
それから、いくつかのチャプターについては個別のエントリとして要約をポストしている。
- 信頼性、保守性、スケーラビリティ: Designing Data-Intensive Applications 第1章より
- データベースを支えるデータ構造: Designing Data-Intensive Applications 第3章より
- 分散データベースのレプリケーション: Designing Data-Intensive Applications 第5章より
12の章立てのうち3章のみかいつまんだ形である。もちろんこれらのほかの章もとても興味深い話のオンパレードである。本当はすべてを紹介したい、なんなら理解を含める目的で私家版の翻訳すら作成してもよい、というくらいに全編にわたって秀でた情報量をほこっているが、そうまではしなかった。
「なんとなく聞いたことがあるようで、実はよくわかっていない」というあたりの知識領域を包括的に扱って、体系的な知識としてまとめてくれている稀有な本である。僕にとってはデータベースのインデックスアルゴリズムがそうで、ここで B-tree が何者であるのかわかったし、 LSM-tree という新しいデータ構造も知ることができた。
第二部 "Distributed Data" では分散データベースの設計・運用上のプロ・コンおよび落とし穴がこれでもかとカタログ化されていて、大規模分散データベースなんて人類には早すぎるのではないか...と暗澹たる気分になかばされつつも、これを読んだおかげでどれだけの新しい視点を得られたかとおもうとずいぶん成長した気がしている。
末尾を飾る第三部も、つい先ほどまで読んでいたこともあるものの、忘れがたい視点であることは疑いない。とりわけ、非同期のイベントによって派生データを適切に制御するという案件をちょうど業務で扱っているところであったので、示唆を与えられるパッセージはあまりにも多かった。それがいかに難しいトピックであるかを痛いほど知ることになり、これらの知見を持たないまま進めてしまっていたらどうなってしまっていたかをおもうとゾッとする。もっとも、これらを知った上でなお難しい問題であることには変わりがないのだが、学んだことをただちに活かせるかもしれないというのは幸せなことである。
読み始めたときのエントリで、本書が teachyourselfcs.com で強く推薦されていたことを紹介した。それに加えて、ハッカーニュースで見かけた フェイスブックの面接対策の記事 でもやっぱり本書が紹介されていた。いわく、上級エンジニア面接ではコーディング試験と同じくらいかそれ以上にシステム設計の知識が求められ、それの足掛かりとするのにちょうどいい本であるそう。僕自身はいまのところビックテック企業の規模のプロジェクトを遂行するような経験はまだないけれど、そうしたレベルを求める人々にとってさえもこの本が有用なリソースであるというのは心強く感じる。つまり、それだけ信頼のおける本であるということ。
反省点としては、ノートのとり方が非常に乱暴だったところか。重要そうな箇所を適当にピックアップして入念に整理することができず、「やたらにひたすらメモをとる」か「ほとんどメモもとらずに読みすすむ」のいずれかに陥りがちであった。これは仕方のないところもあるとおもう。というのは、前提知識の弱さから、書かれてあることすべてが真新しいパースペクティブと映りがちであったため、「重要でないところを読み飛ばす」ということが原理上不可能であったためである。いちどザッと通読してから、重要なところをインデックスしていく戦略で読んでおけば、より効率的にインプットできたかもしれないが、その読み方ではいま受けているほどの感銘は受けなかったかもしれない。いずれにせよ、高い確率で向こう数年中に再読する予感はあるため、なにも悲観すべきことはない。
英語で通読することができたことも誇らしくおもう。日本語と同等の速度で読み進めることはできないが、そのぶんだけ丁寧に読み進められた。スルスルと読んでいるつもりが、ある箇所で突然読めなくなることがあった。そういうときは、それまでスルスルと読んできた前提を正しく読めていなかったというだけにすぎない。実際、すこし前に戻って読みなおすだけで、たいていの難所は突破できる。この点、日本語で読んでいると、わからないことを翻訳のせいにして放置してしまうところがある。まあ、実際に翻訳が悪いこともあるとはおもうが、せっかくいいことが書いてあっても正しく読めないのは申し訳がない。結局のところ、原典にあたるというのはどこまでいっても有効であるという思いを深めている。
放送大学に入学してみよう
連休の終わりに、大学にいこうかな？ とカジュアルに思いついたのが昨日のこと。それからいちにち考えてみて、基礎的なことを体系的に「お勉強」するのなら放送大学の教養学部に入るのがうってつけという結論にいきついた。教養学部というから、学部1-2年生の気分で自由に学問ができるイメージでいる。
モチベーションの管理が厳しいという独学特有の問題も放送大学にはつきまとうようだが、まあいままでもそうやって独学してきたのだから、これはなんとでもなる自信はある。仕事を辞めて4年生大学に編入するくらいの覚悟さえ持つほど思いつめかねなかったところ、二足のわらじになるとはいえ仕事と両立させられるパスがあるのは嬉しいことこの上ない。
ここで微積、線形代数、解析なんかを1年かけてじっくりお勉強しようという気持ちが育っている。そのさきでなにをしたいかはわからない。なぜならまだ知らないことが多すぎて、自分にどんな可能性があるのかすらわかっていないのだ。ただ、少なくともここでの学びの先に新しいパースペクティブが広がっているだろうという昂揚感はたしかにある。導入科目群をきちんと追えられたら、物理ほか自然科学の世界にもそのままアクセスできそうだったり、はたまた芸術と哲学の方面に趣味の勉強の食指を伸ばしてもいいわけだ。まさに新大学生のようにワクワクしている。そしてこうしてワクワクできる対象があることこそ、暗い世界にあって何より幸せなことだとおもう。
大学であるので、入学時期は4月と10月に限られている。そしていまちょうど5月がはじまったところである。10月入学が許可されるという新しい文化に感謝しつつも、あと半年弱は手も足もでない。ただ入学の準備をするだけである。まあとりあえずということで、資料は請求してある。そしてもう数ヶ月はいままで通りの独学に集中しよう。厚めの専門書をもう一冊読むくらいの時間はあがなえる。
以下は補足として、「放送大学とはこういうものか」という見取り図を与えてくれたのはこちらの記事。とりわけ後者の講義レビューは履修イメージも含めてなんとなくの手触りをえた。これだけのことができるなら十分満足できるだろうとおもうことができた。
それから、「社会人の学び直し」という観点ではこれらのエントリも拝見させていただいた。年齢がひとまわり離れていたり、子供も配偶者もいない気楽さもこちらにはあるけれど、だからこそいまいっそう頑張るぞと熱い気持ちは与えられている。
- 37歳で大学生になりました - Gosuke Miyashita
- JAISTの博士前期課程に進学します - 怠惰を求めて勤勉に行き着く
- 文系パパエンジニアが放送大学等でコンピュータサイエンス・数学を学んで理系学士を取りに行く話 - とあるCS学徒のブログ
上のエントリはいずれも学位取得をゴールにおいていたが、僕はあくまで学位は追いかけない。別にすぐに学士が欲しいわけでないし、必要になれば取りにいけばいいというだけの単純な皮算用である。海外の修士コースで勉強するという選択肢もあるようだし、いろんな選択肢があることをありがたく思う。あくまでこの先の僕自身が自分から何を引き出せるかによって道は変わるはずだから、まずは地に足をつけて知るべきことを知るべしというスタンスでいる。
大学にいこうかな？
世界がいまより平和になったらやりたいことがある。それはそうとして、いますべきことはなにか？
大学にはいりなおすということを考えたことがある。ベルリンから帰国して、途方にくれながら次になにをしようか考えていた頃のことである。直接的な刺激になったのはこの記事だったかとおもう。
僕の会社のとあるプロジェクトで、スケジュール管理を扱う新サービスの検討が始まったとき、CTOを含む複数のエンジニアが即座にホワイトボードでアルゴリズムの議論を始めました。スケジュール管理は複雑な組み合わせ問題になることが多く、また我々が考えていたシステムが少し特殊な制約を持っていたので、計算結果の単純なキャッシュがしづらい難問であることは明白でした。 複雑な現実課題を解決するソリューションには、ありもののライブラリやフレームワークなどというものは存在しません。それぞれが自分の中に持った基礎的な道具を持ち寄って、その場でしか使えない「特別な鍵」を作り出す必要があります。基礎力のない応用はありえないのです。
「ありもののライブラリやフレームワーク」を使うのが仕事であると言わざるをえない自分自身の無力と向き合っていた時期であったので、とかく深く心に刺さったのだとおもう。
その後、 Nand2Tetris とか DDIA を読んだり、競技プログラミングもたしなむようになり、いくらか視野は広がった。しかし一年でこれしか進歩していないとおもうと、もっと頑張れるはずとも思っている。
仕事では「ありもののライブラリやフレームワーク」を使った仕事をあいかわらずやっているわけで、そこに物足りなさを感じる瞬間がないとはいえない。とはいえ霞を食べながら勉強するだけの覚悟はなかったわけで、そこを嘆いても仕方がない。
こうして言い訳めいた言葉が出てくるということ自体からして、勉強がしたいという熱情は否定しがたいのだとおもう。知識に投資するのであれば早いに越したことがないのは真理である。
もう少しお金がたまったら...とか、先延ばしにする理由づけには事欠かないのだが、それではいけないだろうと自分を戒める。大学に再入学するプランを立ててみよう。実際に入学に漕ぎつけられるかどうかは別として（入試をパスできるかどうかすらもわからないのだし！）、どうやって学校選びをして、どうやってその後の進路をデザインするか、まで考えてみよう。考えるだけなら無料であるわけだし、それによってやることがはっきりすれば、いまなにを勉強すべきなのかもよりクリアにみえ始めるはず。
