このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

理解をさまたげるモノ/誤解をまねくモノ、それと対処

「モノイドからモナドを作る」に付いたhirataraさんのコメントを見て、3回開催したモニャドセミナーの首尾を思い出したりしたのですが、シミジミ感じることは

うまい説明ってヤッパリ難しい!

セミナー参加者の方々が誤解や混乱をしたときは、僕のほうが誤解や混乱をしているときでもあります。内容的に間違っていることを話してないにせよ(モロに間違っていることもあるけど^^; )、なにか省略しちゃってるとか、事実とは異なるメンタルモデルを想定していたりするんですよね。

この事に関して系統的な話は何もできないので、散発的な2つの話題を以下に書いてみます。最後に、部分的対処となる(かもしれない)心がけを記します。

右と左、上と下、前と後

「右と左」の問題は、このブログでも口頭でも何度も何度も、ほんとに何度も言及してます。これは僕自身が間違ったり混乱するからです。実は、僕はいまだに左右の区別が迅速にはできません。「右=お箸を持つ方の手」とかの変換をしているので時間がかかるんですよ。そのせいで(?)、右と左がひっくり返ったり混ざるとワケがわかんなくなります。

現状僕は、図式順(diagrammatic order;左から右)を常用していて、射の結合(合成)は、f;g と書きます。しかし、関数適用は f(x) と書いています。f(x) を (x)f とか x.f とか書く習慣がほとんど認知されてないからです。このため、

  • (f;g)(x) = g(f(x))

とかになっちゃいます。日本語や英語にアラビア語を混ぜたときのように、バイダイレクショナル(bi-directional, バイダイ; bidi)テキストなんですよね。次のように書けば、左から右で首尾一貫します。

  • x.(f;g) = (x.f).g

この程度のバイダイは別になんともないと思うかもしれませんが、例えば関手と自然変換が絡んだ計算では、バイダイレクショナルに目を往復させるストレスは相当なもんです。具体的には、Functor(C×D, E) と Funcor(C, ED)(EDは関手圏=圏の指数) の同型を示す計算とかやってみれば、けっこうコタエルと思いますよ。

図式になると、上下の順序も問題で、f;g の、fを上に描く人(上から下派)と、gを上に描く人(下から上派)が拮抗しています。前(pre)とか後(post)が何を意味するかも人によって違ったりしますし。そういや、日本語の「前」ってのが、forwardかbackwardか曖昧ですよね。空間だとforwardで、時間だとbackwardなのかな?

記号のオーバーロードと乱用

明示的な型指定を要求するプログラミング言語の(代表的)メリットは、型情報がプログラムコードの意味を理解する助けになり、型の曖昧性に起因するバグを防ぐ効果があることです。デメリットは、面倒で鬱陶しく生産性を下げるかも知れないことですね。

数学や科学の記法にも同じようなことが言えます。キッチリと細部まで書き下す記法だと、曖昧性がなく誤解を防げるのですが、あまりに面倒で耐えきれないモノになります。実際、誰も耐えられないので、猛烈なオーバーロードと乱用をします。そしてそれが躓きの石ともなるわけです -- どうすりゃいいのかねぇ。

実例を出しましょう。「Mがモノイドだ」ということを、細部まで書き下す記法で述べてみます。まず素材として M = (UM, multM, unitM)、これは何かというと:

  1. UM は集合(Mの台集合と呼ぶ)
  2. multMは、multM:UM×UM→UM という写像
  3. unitMは、unitM∈UM という要素

この素材 (UM, multM, unitM) があるだけではモノイドとは言えなくて、ある「性質」を持つことが要求されます。その性質をちゃんと述べるには、モノイド記述用の形式言語 LMonoid を準備して、それを素材(集合論的構造)(UM, multM, unitM) において解釈する方法を定義して、性質(論理式)が成り立つとはどんなことかを定義して、性質一式(公理系)AMonoid を準備し、実際にその性質が成り立つことを要求します。

「性質」の話は全部ハショッタとしても、f:UM→UN がモノイド射(準同型)であることをチャント記述すると、次のようになります。

  • 任意のx, y∈UMに対して、f(multM(x, y)) = multN(f(x), f(y))
  • f(unitM) = unitN

こんなことを律儀に書いているわけにはいかないので、ふつうは次のように書きます。

  • f:M→N
  • f(x・y) = f(x)・f(y)
  • f(1) = 1

このとき犯している誤用・乱用は:

  1. モノイドMと台集合UMを同じ記号で表している。
  2. Mの乗法multMとNの乗法multNを同じ記号「・」で表している。
  3. Mの単位unitMとNの単位unitNを同じ記号「1」で表している。

さらに、「・」や「1」は、もともと整数などの具体例で使っていた記号なのに、一般論に流用しているし。まったくヒドイもんです。

しかし実情は、ヒドイ書き方のほうが普通なんです。型宣言や型指定はしないで、とんでもないオーバーロードをするので、相当に知的で超・文脈依存な型推論が必要なわけです。この型推論がうまくできないで躓くケースは多そうです。

それと、具体例で使っていた記号・記法を一般論でもそのまま使うことが非常に多いですね。これは、類推により理解を助ける効果もある一方、典型的具体例のイメージに引きずられて、いつまでも一般的概念が形成できない原因になるかもしれません。

心がけ

用語とか記号の使い方に関して、是非とも憶えておいて欲しいキーワードは次のようなものでしょう。

  1. バラバラ -- 集団や個人によって、用法が違います。
  2. ズボラ -- 律儀に曖昧性なく書くことは極めてまれで、省略や乱用をするのが普通です。
  3. その場限り -- 同じ用語・記号が文脈によって違った意味で用いられます。その文脈の範囲や寿命(スコープ&エクステント)は非常に小さいことがあります。