はじめに
駆け出しソフトウェアエンジニアがソフトウェア開発と集合について大切にしなきゃなと気づいたことをメモしました。
簡単すぎることですが気づけば忘れてしまいそうなのでメモしました。
集合と条件
集合とソフトウェア開発が密接に関係していることは有名だと思います。
なんせ駆け出しの自分がすぐにたどり着いたのですから、、、
簡単なことは中学高校で学んだことですので詳細は省きます。
集合の分野には色々な定理がありますが個人的にソフトウェアエンジニアとして常に心掛けたい関係式がこちら
p=>q \equiv \lnot(p \land \lnot q)
何をいまさらと思うでしょうが一応簡単な説明を拙い図でします。
まず「pならばq」ということは、「pは必ずqに含まれる」ということ。この式が真であるということは、左図での赤い部分が存在してはいけないことになるので右図のようになります。
一方、上のような関係は「pであって、かつqでないものは存在しない」とも言えます。
この図(絵心がなさ過ぎてOneNote with Surface PenからPaintに切り替えました)
左図の黄色の部分が$p$、水色の部分が$\lnot q$を示しています。そして$(p \land \lnot q)$が右図の緑色の部分です。
この緑色が常に存在しないとき$p\Rightarrow q$が常に真となります。
かなりいい加減な説明ですが今回は厳密に証明することではなくイメージを掴むことが目的なので許してください。
これで上の関係式の内容がなんとなくイメージできるようになりました。
具体的な理解
この関係式はとある問題を考えているときに別の視点を与えてくれます。
p=>q \equiv \lnot(p \land \lnot q)
「$p\Rightarrow q$」は様々な場面で出てきますがこのpとqを漏れなくダブりなく(MECE)とらえるのは難しいです。
「ならば」というのがp、qそれぞれの全体像、またpとqの関係性をとらえにくくしているのだと思います。
一方右辺は否定文であることが特徴としてあります。つまり()内のことがあってはいけない=禁止されていると考えることができます。
より分かりやすく言うと
pであって、なおかつ qではないという条件(ルール)が禁止されていると考えます。
この手の問題でよくある例が「p=運転手、q=免許証がある」とした日本の交通ルールについての問答。
左辺：運転手ならば、免許証がある
これは日本の法律上、真でなければいけません。
また「運転手じゃないならば、免許証がある」も真です。別に運転していないならば免許証を持っていようがいまいが違反ではありません。
ということで「運転手じゃないならば、免許証がない」も真です。
表にすると以下のようになります(1:真 0:偽)
| p | q | p=>q |
|---|---|---|
| 1 | 1 | 1 |
| 1 | 0 | 0 |
| 0 | 1 | 1 |
| 0 | 0 | 1 |
上2つはわかりやすいですが下二つは直感的にはわかりにくいです。
一方、右辺：「運転手であって、かつ、免許証がない」ことを禁止する
となり、このルールに違反したものを選ぶ問題と考えることができます。2つの要素が満たされているかどうかをチェックするだけでいいのでかなり扱いやすくなった印象です。
ここでは「運転者である」「免許をもっていない」の2つの条件が同時に成り立った場合のみ偽、あと残りはすべて真とすればいい。
| p | q | $\lnot q$ | $p \land \lnot q$ | $\lnot(p \land \lnot q)$ |
|---|---|---|---|---|
| 1 | 1 | 0 | 0 | 1 |
| 1 | 0 | 1 | 1 | 0 |
| 0 | 1 | 0 | 0 | 1 |
| 0 | 0 | 1 | 0 | 1 |
左辺と右辺の違いは「真を探しだすか」、「偽を探しだすか」の違いなだけに見える。どちらが良いかは問題の性質にもよるだろうしもちろん片方の探索ですべてのパターンを列挙できればいうことなしです。
しかし武器は多いに越したことはないと思います。
どこで役に立つか
このpとqはソフトでは状態の関係であり、アルゴリズムではインプット、アウトプット、条件の関係となります。
自分は普段アプリケーションの仕様作成、設計、実装を行っています。複雑なアプリケーションは様々なオブジェクト同士が互いに関連し合っています(できるだけ疎な関係にしようとはしていますが、、、)。
また動作フローなども何パターンもあり、それらすべてを考慮しないとバグの原因となります。
また自分はソフトウェアエンジニアになると決まったくらいから訓練も兼ねて競技プログラミングをやってます。
そこでも「このコーディングで果たして問題文のすべての条件をクリアしているか」といったことを考えるのは当然であり、難易度が高い問題ほどその工程の重要度、難易度は増します。
上で挙げたようなときに当たり前だけど漏れがないかを集合論的に考えることはとても大切だと思います。
もしかしたら日常でも何か役に立つかもしれないと思います。そしてモテるかもしれないです。
まとめ
・集合の考え方はソフトウェア開発するにあたってとても重要な学問
・$p=>q \equiv \lnot(p \land \lnot q)$は問題のとらえ方に2つの視点を与える。
・この考え方はいろんな分野に応用できる、、はず