他の日記へのリンク - メモのような日記のような(4) 2021.03.14-
- このページ → メモのような日記のような(3) 2019.11.16-2020.10.23
- メモのような日記のような(2) 2018.11.24-2019.10.30 へ
- メモのような日記のような(1) 2017.10.17-2018.11.04 へ
- 丘浅次郎の「落第と退校」を読んで - または「作文」のこと - 2020 年 10月 23 日 (金)
YGU 氏 のご冥福をお祈りいたします 2020 年 7月 31 日 (金)- 束における分配不等式の3Dモデルのプロトタイプ
- 娑婆への復帰のためのリハビリ - 2020 年 5月 24 日 (日)- 某勉強会で「計算機科学のための圏論の基礎の基礎」の発表をした話 2020 年 3月 28 日 (土)
- <ul> と <ol> の上のスペースがなかなか取り除けなかった話 2020 年 3月 26 日 (木)
- 「やはり基礎はとても大切!」というお話とちょっとだけ圏論のお話 2020 年 2月 27 日 (木)
- 川を渡って良いものか? 2020 年 2月 14 日 (金)
- 機械と人間は違うか? - A* と A∞ - 2020 年 1月 15 日 (水)
- 「モノ」を分けたがる人,境界が曖昧だと騒ぎ立てる人
- 悪党,愚者,正直者- 2019 年 12月 28 日 (土)- AI (Artificial Intelligence) とは何だろうか? トライアル 2019 年 12月 25 日 (水)
- 説明における人型アイコンの効果の実験 2019 年 12月 14 日 (土)
- 違いは,出っ張り具合? PAD と C言語風疑似コード 2019 年 12月 9 日 (月)
- 学習形態に関するメモ:プレゼン資料の提示形態 2019 年 12 月 4日 (水)
- 「物理学の応用について (寺田 寅彦)」を読んで 2019 年 11 月 23 日 (土)
- 仕様は実装より分かりやすいか? 2019 年 11 月 16 日 (木)
- または「作文」のこと -
奥さんが亡くなった落ち込みからのリハビリプログラムの1つとして,
落第と退校 (丘 浅次郎 著)を書きました.
![]()
丘 浅次郎は,
で,もとの作品「落第と退校」に戻って,この作品はタイトルからは分かりにくいのですが,
この作品で,丘は,当時の予備門や大学の制度に対して色々と不満を書いていますが,
私は,この
私の高校入学は 1974年なのですが,そのときに
こういうことがあったのですが,一方,国語が出来なくてまったく問題ないと考えて
いるかというと,そうではありません.
もあまり力がついていないのです.おまけにどこで習ったんだか分かりませんが, 文章を格調高くしようとして「自分の云ひたいと思ふことを、読む人によく解からせる様な文章を作る術」
私が,技術文章を,
上に書いたことは,高校から国語の授業をなまけた私自身の反省ですが,
の練習をしていれば,もう少しましなのではないかと思います.「自分の云ひたいと思ふことを、読む人によく解からせる様な文章を作る術」
それで,今回は何が言いたかったかと言うと,
ここまで書いてきて分かったのですが,要は,
現在,世の中で動きがあるように,
最後に,もう一度,丘 浅次郎の話に戻って,私が大学に入った時に感動した
というキーワードで丘 浅次郎 進化論講話
やはり大学に入ってすぐの出来事は結構覚えているものです.
今回は,某勉強会で知り合いになった YGU さんがお亡くなりになった話です.
「YGU さん」と
伏字で書いていますから誰だか分かりにくいでしょうし,たとえ,実名が分かったとしても,YGU さんを
ご存じない方には何のことか分からないかもしれません.でも,後半は,私が YGU さんに触発されて,このコーナーに書き散らかした
二週間ほど前に,私がこの2年くらい
とのメールが,YGU さんの娘さんからありました.ご家族の方には心より お悔やみを申し上げます.また,YGU さんのご冥福をお祈りいたします.
その勉強会は,どちらかというと数学や計算機科学を
中心として,各自が興味のあるものを勉強してきて,二週間に一回,一人が2時間発表して30分質疑応答があるというもの
です.各自が興味があるものということで,哲学,言語学,経済学,歴史,物理学,などなど
多彩なトピックスがあります.なんでも,この会は,YGU さんたちが,某日本XXXSYS の時からやっている勉強会だったのだけど,
メンバーの大部分が定年などで退職してしまったので,会も社外に出て,さらに社外のメンバーも加わって
活動を続けているとのことです.すでに 468 回まで続いているのですごいものです.
YGU さんは某日本XXXSYS の,もとお偉いさんで,G.H. ハーディの
私は 2014 年頃,たまたま,その勉強会のホームページを見て,束論,論理学,圏論などの話題が時々 出ているので,興味を持っていたのですが, 2017 年 12 月に,その会の KWB さんの「圏論による量子系のモデル化」というお話を聞きに いくために意を決して参加し,自分自身も計3回発表しました.ここの「メモのような日記のような」に,そのことをYGU さんも登場させて度々書いています.
その勉強会ですが,今は私は抜けています.というのは,私自身の話になりますが, 今年の4月に妻が突然亡くなり,気落ちしてしまい,発表したり,議論したりする 気力がなくなったからです.5月に,会の取りまとめの YGU さんに, 「こういう次第でしばらく抜けます」と伝えると,そのことの了承と慰めの言葉をいただきました. それが,今度は YGU さん自身が亡くなられてしまいました.
娘さんのメールでは,世の中では,新型コロナウイルスによる肺炎が流行っているので, 「葬儀などは家族のみで済ませる」と書かれていましたが,YGU さんは, もと日本XXXSYS の偉い人なので,やはり,旧知からの問い合わせなどで大変なのでは ないかと想像します.その大変な中に,せいぜい2年間の付き合いである私が 加わり,余計な手間をかけてはと思いましたので,私は自宅で手を合わせるだけに しました.私自身,家内が亡くなったときの大変さを覚えていますし,実は,まだ色々な 手続きが続いていたりするので,遺族に余計な手間を掛けさせたくないのです.
代わりと言ってはなんですが,ここの
私と YGU さんとはこの2年間の勉強会だけの付き合いであり,また,私も あまり勉強会には出席していないので,たぶん,直接お話したのは10回くらいと思います. したがって,ここでのお話はあくまで私がほんのちょっとのお付き合いの中で感じた 少し偏見のある,私の「YGU さん像」ですが,単に「りっぱな人でした」というよりは, 生の YGU さんのイメージを残せるのではないかと思いました.
勉強会やその後の飲み会などで YGU さんと話した感じでは,
私は
私自身は,「人間と機械の能力は原理的には同じで,ただ,現状では規模が違うだけ」と考えています.つまり,どちらも帰納的関数,あるいは止まらない場合も許せば,帰納的列挙可能な関数です.YGU さんの お話を聞いていると,最初は私と同じかなと思うのですが, 途中で,「うん? 違うのかな?」というところが沢山でてくるのです.この二つに関する 考え方の違いをまとめると
人間の能力
なのか
人間の能力
人間の能力
これらに関係して,ここの「メモのような日記のような」で
MTDA さんが大雑把に,自然語理解の文脈で,「意味」とか「理解」とかの語を自分の感覚に結び付けて
話されるのに対して,YGU さんは,それらの語の
そのとき,私が丁度,底の無い集合論(集合の要素を次々に辿っていっても 底(集合以外のもの)にたどり着かない集合論)のことを調べていたので, このような無限に定義が 遡(さかのぼ)れたり,あるいは循環している定義が可能ではないかという 記事を書いてみたのです.
それで,私は,皆さんが資料を持ち寄って討論会をしたらどうかと提案したのです.このときは,私自身は聞く方に回り,話者の一人にはならないと 言ったこともあり,この企画は実現しませんでした.この後,「やはり,自分は 発表しないという態度は良くないのではないだろうか」と思い,ちょっと, このコーナーを使って自分の意見をまとめていたのです.それが上のリンクからたどれる 記事です.これはゲーデルの不完全性定理などの内容を含んでいるので,少し長いです.
この絵は,YGU さんが良く言われる,
を絵にしたものです.私は,YGU さんが何を意図しているのか正確には分かっていません. 分からない部分のポイントは,YGU さんが,AI と普通のソフトウェアが違うところは,AI はセンサーと アクチュエーターが付いているところだ
ソフトウェアが,センサーとアクチュエータを備えることが,通常の帰納関数の 能力を超えてです.後者なら私は合意なのですが,何か話を聞いていると前者も混じっている ような感じがするのです.尚,YGU さんは出てきませんが,この続編で,私自身も 「人間 ≠ 機械」と考えている記事機械では実現できない人間に近づく 方法だと考えているのか,
あるいは
帰納関数の範囲内で高度な ソフトウェアができると言っているのか
機械と人間は違うか? - A* と A∞ -もあります.
![]()
この絵のような状況が発生して,YGU さんを含めて結論のでない議論に突入するので, その場面では,私はいつも頭の中で,この絵本のタイトル
のように悪態をついていました.このヒトタチくっつくべからず
勉強会の皆さんは昔同じ会社にいて何十年もこういう議論を続けてきたんでしょうから, いい加減,相手の言うことを予想して,議論を避けるなり,逆に,深めるなりしてくれたら 良いのに
![]()
でも,もしかしたら,第三者が見るほど, このかみ合わない会話は当人たちにとってはつまらないものではないのかも しれません.延々と同じ会社でこういう議論を行ってきて,まだ,同じ勉強会に いるのですから.所謂,腐れ縁というものかもしれません.
将来,圏論が計算機科学専攻の基礎的な素養になって, これを知らないと話にならないという時代がくるかもしれませんねと言ったときの,YGU さんの反応です.
「そんな世の中には絶対なりません」と言われてしまいました.
でも,実は,これは私も分かります.世の中の計算機ソフトウェアは 殆どが整数の加減乗除くらいの理論で作られているのです.
いや,Kさんね,圏論に出てくる概念の意図が分からないというけど, あれはいくつかの数学的概念を横並びに見て抽象化したものだから もとの概念を思い浮かべれば...と反応されました.
私は,そのとき,「あれらの定義が普通に頭の中に入ってくる人たちが いるんだな」と少し感動しました.
そのときは,一応,YGU さんに,
いや,YGU さんは大学で,抽象数学を立派に修めて卒業したのでしょうが, 我々,抽象数学のバックグラウンドが無いものにとって,それら横並びに するものを思い浮かべることができないのですよ.と言っておきました.でも,そのときはこの絵を見せなかったのが悔やまれます.
以上,ここのコーナーに書いたことから,YGU さんに関連することを色々並べてみました. ここだけ読むと,YGU さんはかなりの偏屈だと思われるかもしれませんが,たぶん,実際, そうです. 同時に,私程度が太刀打ちできないくらいの成果を上げていますし,また,ご高齢に なっても,学問の具体的な内容(形式だけでなく)まで立ち入った勉強をされている方でした. 私なんかは,数学の定理でも,証明の概要さえ聞けば,自分でやってみようとは思わないのですが, YGU さんはきちんとそれも押さえていかれているようでした.勉強会の場でも,他の人の スライドの中の証明を一生懸命追いかけていらっしゃった姿を思い出します.
ちなみに,最初の絵
色々書きましたが,最後にもう一度,
- 娑婆への復帰のためのリハビリ -
今回は束論の分配不等式の3Dモデルを作るお話です.
別の日記 「私の奥様の朋子さんが突然亡くなられてしまいました」 で書いたように,先月,奥様が急に亡くなってしまい,元気がでないというか, 落ち込んでいました.しかし,いつまでも落ち込んでいる訳にも行かないので 現世(娑婆)への復帰プログラムとして,ずっと放っておいたこの3Dモデルを 作るというのに取り組んでみようと思った訳です.
分配不等式の3Dモデルは,ここの束論のページの
にあるのですが,実際に「物」を使って作ってみたり,CG を使って精細な画像を作って みたりして,リアリティを向上しようという企みな訳です.一応,束(lattice)の定義だけ言っておきます.
(部分)順序集合 (L, ≤) が
ここで,z∈L が x と y の上限 であるとは,z が {u∈L | u≥x かつ u≥y} の最小元であること, w が x と y の下限 であるとは,w が {u∈L | u≤x かつ u≤y} の最大元であることである.x と y の上限をx ∨ y , 下限をx ∧ y と書く.
これも一応ですが,分配不等式とは
a ∧ (b ∨ c) ≥ (a ∧ b) ∨ (a ∧ c)という不等式であり,束では常に成立します.この不等号が等号になっているのが 分配法則
a ∧ (b ∨ c) = (a ∧ b) ∨ (a ∧ c)で,それが成り立つ束は分配束(distributive lattice)と呼ばれ, 性質の良い束とされています.ブール代数は分配束です.でも,一般の束では, この等号は必ずしも成立せず,左の方が真に大きいことがあります.それを視覚的に 表しているのが上のモデルの中心部にある次の部分です.
一般の束ではこの上下は一致するとは限りません.
で,今回,分配不等式の3Dモデルを作ろうとしてみて気付いたのは,
私がずっと放っておいたのは,実は,軸やノードとして適切な材料がなかなか 見つからなかったという理由があった.気力がない今それらの解決が 出来る訳がないということでした.一応は,石膏粘土と竹ひごとかで試してみたのですが, 中々,きれいにできませんでした.
このまま放っておくと,また,長い期間寝かしてしまいかねないので,今回は, 不格好でも,とりあえず,厚紙でペーパークラフトを作ってみました.
こんなのです.一応ステレオグラムの画像(平行法)も載せておきます.
スマフォを 手で少しずらしながら撮ってみました.正確ではないですが,およそ立体が把握 できるのではないかと思います.でも,やはり歪んでいるので長い間眺めるのは 辛いですね.
この分配不等式を把握するのに,本当に3Dモデルが要るかと言うと,重要な所は 中心部分の
なので,必ずしも要らないのです.この図をどう読むかと言うと,
ということで,分配不等式が成立することを見て取るためには,この3Dの大物ノモデルは 要らないのですが,ただし,学習という観点からいうと,実際に 工作してみて,単項の a, b, c も含めその中に出てくる式の間の 位置関係を理解することは,この不等式に慣れるという意味で重要なことだと思います.
また,3Dモデルは次の図のように中に5角形を含んでいます.
この5角形はN5 と呼ばれる束で,
モジュラー束(分配束より少し条件を緩めた束)になる ためには,この N5 がその束の部分束として現れてはいけないという束です. 単項の要素までモデルに含めるとそのこともしっかりモデルの中に現れてくる訳です.
こうやって,このモデルを作ったり,それを触ったりすることで,分配不等式に慣れることができます. 多分,束論を習い始めた学習者は,この不等式に慣れたとしても,この不等式の 意味が分かる訳ではないのですが,最初は
上でもちらっと述べましたが,分配束の条件を少し緩和した束として
ここで, c ≤ a なら a ∧ c = c ですから,上の式は次のようになります.c ≤ a ならば a ∧ (b ∨ c) = (a ∧ b) ∨ (a ∧ c)
式は簡単になりましたが,意味はよく分からなくなりました.括弧が微妙に左右にずれても 等号がなりたつ? 分配束も何に役に立つのか分からないと言いましたが,分配法則自身は 小学校の頃からc ≤ a ならば a ∧ (b ∨ c) = (a ∧ b) ∨ c
という式で慣らされているので,なんとなく役に立つ気がします.モジュラー束は慣れてないので なんの役に立つのか一見わかりません. モジュラー束の 代表的なものとしては,アーベル群の部分群がなす束が あるそうです.これはデデキントが彼の研究 "algebra of modules" の中で 発見したとのことです.まあ,具体例があり,役にはたっていたということですね. これらの不等式の意味を考えるというのは,いろいろな束で等式が 成立するもの,しないものを見ていくことなんだと思います.a*(b+c) = a*b + a*c
今回は紙で間に合わせに3Dモデルを作ったのですが,3D グラフィックスを使って 作るのが,材料が不要で良いかなという気がしてきました.特にプラグインを必要とせず, ブラウザで見えるためには WebGL を使うというのが手ですかね.ただ,私はこれ,ほとんど知らないんですよね.ということで,この後の リハビリ候補として,WebGL とその上のライブラリ Three を学習して,分配不等式を可視化するというのが 一つの候補としてありそうです.
先日,某勉強会で,
計算機科学のための圏論の基礎の基礎に置いておきます.発表資料は枚数が 104 枚あり,時間も2時間喋りっぱなしだったので, 終わり位には少し心が折れました.
全部のスライドに全く問題がないならまた違ってくるのかもしれませんが,今回のものは, 自分自身の 考えや感性をかなり入れていて,それが「十分伝わるかな?」とか 「こんな反論があると怖いな」と思いつつ進めると,だんだん疲れが溜まってきて, 1時間半くらいで心が折れ始めたのです.実は,こういうことはよくある事なのですが.また,気が張っていて,心が折れてることに気が付かない場合でも, 次の日か,またその次の日に疲れが出ることはあります(ね?).もっとも,今回は 聞いてるほうも疲れたと思いますが.
私はこれから,なんとか,こういうチュートリアルをやって幾ばくかでも稼ぐことが 出来たら良いな と思っているので,自分自身と聴衆の折れた心を伸ばす術も身に着けていかねば ならないなと思うことしきりでした(まあ,当面は資料の改善と整備ですが).
先日の発表では聴衆は8名,そのうちの2名の方は圏論を知っていて,それ以外の6名の方は 自己申告では圏論を知らないと言われてました.勉強会の場を借りて,チュートリアルの 試作品の初期テストをさせてもらったのでした.結果は,やはり,2時間ではあの 104 枚の スライドは喋り終えられないということでした.1時間45分でスライド 52 までしか行けません でしたから,あとの 15 分は,残りに何が書いてあるかざっと概要を言って終わりにしました. チュートリアルの目的は,聴衆に理解してもらうことですから,やはり全部やろうと思うと 4時間~6時間あった方が良いように思います.そうすると,長時間でまた自分の心が折れそうになるので, そこも鍛えたり,自分も聴衆も十分な休憩が取れるように時間割りを工夫したりが 必要そうです.
今回の発表で印象的だったのが,聴衆の中の圏論をご存じの YG さんの次の発言でした.
K さんは圏論の諸概念の意味や意図が分かりにくいとおっしゃいますが,あれらは 数学のいくつかの概念を横並びにして抽象化してみたものなので,それらを想像してみれば その意味が分かってくるものなんです.この発言の何が印象的だったかというと,
ということです.まあ,考えてみれば,圏論を作った人たちもそういう人たちだった 訳でしょうから当然と言えば当然なのですが,自分がこれだけ理解に苦しんでいる中, 直接,そういう発言を聞くと感動してしまいます.圏論の中の諸概念を別に難しいと感じていない人たちがいる
今後,私自身は,当初からの目的
に向かって進もうと思っています. とりあえず,今回作ったものは,「自然変換」さえも含まないくらい, 圏論に必要な概念が不足しているものですので,そういうものの説明の資料を 書いていくことが当面の仕事かなと思っています.私のようになかなか圏論の学習が進まない(計算機科学の)学習者に, なんとか市販の教科書を読み進められるだけの 動機の説明や,難しい概念の紐解きをした教材を用意する
あと,こうやって仮想的な聴衆を仮定して,説明資料を作るという作業は 自分自身の勉強にもすごく役に立ちます.自分自身があやふやだった部分を すべて明確にしていかなければならないのですから.
長めの話が続いているので,ここらで短いのを一つ書いておきます.とは言いつつ,html の
タグの話なので,興味のある人は少ないと思いますが.
先日,某勉強会で,圏論のチュートリアルのようなものを発表してきたので,こちらのサイトにも 載せることにしました( 計算機科学のための圏論の基礎の基礎). そのとき,某勉強会に送っておいた内容梗概をこちらに html の形に 修正して載せようとしたのですが,次のようにどうしてもリストの上に意図しないスペースが 空いてしまいます(「圏論の計算機応用に関する概要」の上と「代数/余代数によるデータ型の表現」の上).
この html のソースファイルは
<ul> <li>圏論の計算機応用に関する概要 ... <ul> <li>代数/余代数によるデータ型の表現 ...
で,今までもこの形で使っていたのに,今回だけこんなに大きくスペースが開くのは なんでだろうとと思いながら,インターネットを検索して, スタイルシートを margin-top:0px; とか padding-top:0px; とか 色々ためしてみましたが,一向にスペースはなくなりません.
で,一日悩んでやっと分かりました.某勉強会に送ったテキストでは,テキストに よる整形をしていて,各項目の前に全角の空白を入れてインデントしていたのです. そのテキストに <ul> や <li> を挿入していたので, 全角の空白を■と書くと次のようになっていたのです.
<ul> ■■<li>圏論の計算機応用に関する概要 ... <ul> ■■■■<li>代数/余代数によるデータ型の表現 ...
これでリストの最初の項目の上に■■や■■■■が一行取られて表示されていた訳です. つまり,全角の空白を■で明示すると,次のように表示されていたわけです.
まあ,これらを半角のスペースに変えることで,余計なスペースが無くなって,事なきを
得たのですが,
前回の記事「川を渡って良いものか?」 で,大学の
先生は
自分自身は何がどう難しいかを忘れてしまったり,あるいは,最初から簡単に 理解できたので何が難しいか分からないとしても,ということを書きました.自分の周りに,分からない学生が常にいる ので, 彼らからその分からなさを教えて貰える恵まれた環境 にある
実は,もう一つ,大学の先生方が恵まれた環境にあると思うことがあります. それは,
です.これは別に,教科書や教材を作ることに関して恵まれているという訳でなく,否応なく,毎年,繰り返し繰り返し,基礎をやらなければならないこと
一般に,基礎はとっても大切です.私が非常勤講師で教えに行っている科目は,数学ではなく, C言語の応用編みたいなものですが,そこでの分からない学生は,応用編が分からないのでは なく,その前の基礎編でつまづいている学生が多いのです.
学生は応用編の単位を取らないといけないので,労力をその前の基礎編の復習に向ける気が 起こりません.なんとか基礎編の復習をせずに,応用編の課題を解けないかと頑張ります. 教える側の私としては彼らの基礎編の知識の欠落状態が分かるので,一応は,「君は基礎のこの部分が 分かってないので,昔の教科書を見て復習してごらん」とは言うのですが,彼らの
という反論にあってしまいます.「そんなことをやっている暇はない」
話を,「大学の先生が毎年基礎を繰り返さなければならない恵まれた環境にいる」ということに 戻しますと,この基礎が大切というのは,なにも学生さんたちだけに限ったことでは無いと 思います.私は非常勤講師で担当しているのは,このC言語の応用編だけなのですが, 年に2回,説明資料を見直して改良していきます.
また,扱っているプログラムに関しても 色々な実験をしてみます.そうするといろいろな疑問が出てきて,それをC言語の規格書で 調べなおしたり,あるいはプログラムを色々な条件で走らせて実行速度などのデータを 収集・整理してみたりします.扱う対象はごくごく単純なプログラムなのですが,結構, 自分の知識の空隙が見つかったり,新たな発見があることがあります. また,同じ表記や同じ課題に何度も触れるので,それらを把握するのに ほとんど頭の中のリソースを使わなくなるまで習熟していきます.これは,一つの 見方を固定させてしまう危険性はあるので気を付けないといけないのですが,しかし, 大部分の場合,頭の中のリソースを真に思考力を必要とする対象に向ける余裕を生みます.
以上のような理由から,
ちょっと想像してみると,
特に,この「分かりやすく説明できるようになる」というのは重要だと思います.よく,
という人がいますが,説明できないということは,「分かっていない」か, あるいは,「十分には分かっていない」ことが多いのではないでしょうか.自分では分かってはいるんだけど,それをどうやって人に説明して良いか難しい
本当に口下手で,分かっているけど説明できないという人もいるとは思いますが,
多くの場合,口に出してみるとつっかえるということは,
以上,大学教育におけるプログラミングや基礎数学の例をみてきましたが,
これらの知見を(計算機科学で使うための)
注)S. Awodey の Category Theory に載っている項目を参考にしましたので, 比較的基本的な項目だけ拾っています.
でも,実際にはそれらの人はその前につまづいているのではないでしょうか? たぶん, 自然変換 (natural transformation) あたりから,モヤモヤとしたものが溜まっていって... . でも,なんとなくわかったつもりになって進めていって,とうとう上のような項目の学習で 「もう,先に進めない」という気持ちになるのではないかと思います(これは実は私のことです).
上にあげた項目の中で,例えば,米田のレンマは,表現可能関手 C(A, -) : C → Set と任意の関手 F : C → Set との間の自然変換の集合 Nat(C(A, -), F) と 集合 F(A) の自然な同型に関する命題です.したがって,自然変換があまり分かってないと, この命題自身を想像することができません.また,そこでの同型は「自然」であるという但し書きが ついていますので,ここでも「自然」ということが重要になります.
ここは勇気をもって,もう一度自然変換の 章に戻ってみることが必要なのでしょう.
自然変換が分かるためには関手 (functor) が分かっていなければなりません.
もし,自然変換がどうしても分からなければ,関手の章に戻って,
関手の例を色々みたり,関手にどんな意味付けが可能かなと考えてみるのが良いのかなと
思います.
自然変換は,そこで関手に意味づけたものの間の
さらにもっと前に 戻って,始対象や終対象を復習したり,また,見方を変えたら,こういうものが始対象や終対象と してみることができるなどの考察をしてみるのも良いと思います.基本的に始対象は最小値で, 終対象は最大値です.ある問題の一般解の最適な表現を求めようとするとき,その問題の条件を 満たすオブジェクト,あるいは,何らかの構成物を集めて圏を作れば,求める一般解の表現は,その圏の中の最小値, あるいは,最大値として定式化できる可能性があります.
もし,手元の本では,そのような 概念の説明が十分でなかったり,例が少なかったりした場合は,別の本やインターネットで 公開されているチュートリアルの類を調べてみるのも良いと思います.最近は,自分の講義資料を CC (Creative Commons) の著作権で,ホームページやarxiv に公開している大学の先生方が結構いらっしゃいます.
基礎の繰り返しの学習は,その後ずっと効果が続きますから,その後の項目数を N とすると ×N で効いてきます.N 倍化です.ですから,これがプラスに効いてくる場合と,授業の担当の ように, お金をもらうかわりのオブリゲーションという場合はずっと基礎をやってたら良いのではないでしょうか.
P.S.
来月の終わり位に某勉強会で圏論のごく基礎の発表をすることにしましたので, 発表資料の作成を始めました.本当に ごく基礎の部分で,たぶん,自然変換も含まれません.発表資料は先方の ホームページに公開されますが,発表が終わったら,こちらのサイトにも 置くかもしれません.
以前,「ソフトウェア科学とボサツ様」で
ソフトウェア科学のに興味があると書きました.あちら側(理論的な世界,抽象数学的な世界) に容易に行けるような 教材作り
そのような教材を作るためには,自分自身,あちら側に行かないといけないのですが, 安易に行ってしまって良いのだろうかという心配があります.私は,今,こちら側にいるので あちら側に行くのがいかに大変か分かるのですが,「あちら側に行ってしまったら,それが 分からなくなるのではないだろうか」という心配です.
大学で代数や代数幾何など高度に抽象的な数学を専攻した人たちには分からないかもしれませんが, 理系でも別の畑で育った人間には抽象数学はかなり分かりにくいものです.私は,何かの 気の迷いで,圏論を使った計算機科学の論文を読んでみることがありますが, 読み始めるとすぐに頭がくらっとして,しばしば 次の絵のように抽象数学の波に翻弄されている幻想に襲われます.
たぶん,数学を専攻していても,解析学など比較的現実への応用のある分野の方は このように感じる方がある程度いるのではないでしょうか.
私は数年前,会社を辞めた時,仕事をしながらこういう抽象数学を学習することの辛さを知っているので,
これからは,ここの橋渡しをするような活動をしていこうと思いました.
つまり,大学の初年程度の数学が分かる人に対して,計算機科学で使うような圏論や束論など,
抽象数学の習得を
助ける教材を作ったり,勉強会を開いたりすることです.
そして,その延長上に小遣い程度でもよいので幾ばくかのお金を稼ぐことができれば嬉しいなと
考えています.
なにしろ,それらが
そこで最初に書いた
あちら側(that side)に渡っても「分からなさ」を分かっていられるか?
どうなんでしょう? もともと分かっていなかったという事実があるのですから,それを覚えていられるかもしれません. でも,「何が分かっていなかった」という項目は覚えていられるかもしれませんが, それはあくまで項目であり,変質してしまった知識なので,生の「分からなさ」では ないかもしれません.あるいは,何が難しかったかを全く忘れてしまうかもしれません. こうなると私が唯一持っているアドバンテージを捨てることになります.
こういうことを色々悩んでいたのですが,最近は,
int main(int argc, char *argv[]) { /* argv[i] を使ってコマンド引数の 判断や処理をする */ }
で,実行時に与えられたコマンド引数 argv[i] の判断や処理を行うという課題なのですが, argv[i] がコマンドの i 番目の引数として与えられた文字列ということがなかなか理解できない 学生がいるのです.
「char *argv[] が何のことなのかさっぱり分かりません」という質問を最初に受けたときは
えー? 文字列の配列でしょう.何か悩む要素はあるの?
と思ったのですが,よくよく考えてみると,これはパラメータ argv の両側から 「*」と「[]」が掛かっている訳で,なかなか分かりにくいのかもしれません. しかも優先順位も明示されていないので,どちらが先に掛かっているの かも分からないのでしょう.思い返してみると,私も C言語を学習しているときは 悩んだのかもしれません.こう考えて,学生さんには次の図のように優先順位から 丁寧に説明していきます.
上の例では,要素に分解するまでもなく,我々は,
で,すでにパターンが頭の中にできているので,難なく読み取れるわけです.ものを 勉強していくとこういうパターンは頭の中に沢山できてきます.そういう人たちには, 部分部分を定義に従って組み立てていくしかない初心者の苦労は分からないのだと 思います.char *array[];
多くの圏論の書き物で,次のようなモナド(monad)の可換図式がさらっと出てきます.
最初にこれを見た学習者がこの内容をくみ取るのはとても大変だと思います (私は今でも大変です).特に,自然変換と関手の合成をきちんと勉強してきていない 人にとっては意味を解釈することさえ出来ないかもしれません.でも,ある程度慣れて, こういうパターンが頭の中に刻み込まれてくると,その大変さが分からなくなって しまうのでしょう.上の char *argv[] と同じです.教科書を書いている人は,その段階では, 一瞬でこれを読み取れるのです.ただ,落ちこぼれる人の比率は char *argv[] より高いと思います.
上の二つは,「以前は分からなかったということ」が分からなくなる例でした.
人間はその時々の状態で,以前の気持ちや思考過程を忘れてしまうことは,
こういう例を出さなくても,プログラマならよく経験していると思います.
昔書いたプログラムの中の文の意図がどうしても分からないということは
よくあることです.
こういうことを考えると,やはり,
もうひとつ,上の学生の例を書いていて思ったのですが,近くに分からない初心者がいるということは ありがたいことです.自分が,「分からないところがどこか」分からなくなっても, その初心者が教えてくれるからです.
今作成しようとしている教材に関して,学校で教科を持っている訳でもない私が, このような状況を作ろうとすると,常に初心者を確保して,うまくフィードバックを 受ける方法を考えなければなりません.作ってみた教材で,あまりクレームの入らない 条件を設定して,時々勉強会でも開いてみるのは良い手かもしれません.
以上をまとめると,今回の結論としては,次のような感じでしょうか.
まあ,すごく当たり前な結論ですね.ということで,「川を渡る」ことにしますが, あとは本当に渡り切れるかどうかがとても心配です :-) .
P.S.
最初に,「『分からない』気持ちが分かることが私の唯一のアドバンテージ」と言いましたが, 大学の先生は,多くの分からない学生を抱えているので,教育熱心な先生なら,この アドバンテージを学生から貰える環境にあると思います.そうすると私の アドバンテージはもともと無いことになってしまいます.まあ,『分からない』気持ちを 強く意識する態度位ならまだアドバンテージとして残っているかもしれません.
今回のお話は,以前(2019年12月25日)のメモ「AI (Artificial Intelligence) とは何だろうか? トライアル」の続きです. 私は,そこで,
と書きましたが,今回はそれの逆に見えることを書きます.機械ができないことを人間が出来るとは考えない
期間的には前回から1か月もたってないのですが,まあ, 年が変わったということを言い訳にして,今回は逆のことを書きます. 前回のお話はとっても長かったのですが,できれば 前回の話もお読みいただけると 今回の話の位置づけが明確になるかなと思います.
話をひっくり返すことになった切っ掛けは月並みなのですが,上の絵のような状況を考えたとき,
と思ったことです.どちらかというと顔から受ける印象で好き嫌いが 決まっているのであって,自分はあまり論理で人の好き嫌いを決めてない
(P1 かつ P2) またはというような論理式では決めてないなという気がしています.もちろん,顔の印象も論理式だという論も あるでしょうが,素朴なアイデアとしてはアナログ量で決めているように思うのです.
((任意の x に対して P3(x, y) を満たす y が存在するならば P4) かつ ...) または
...
実際的にはある量以下の微細な量については認識できず,有限の桁数で打ち切った
「好き嫌い判定処理」をしても問題ないのでしょうが,どこで打ち切るという明確な
基準が無い以上,連続量をどこかで打ち切ることは近似をとっていることになります.
そのようなことを考えていくと,これも月並みかもしれませんが,上の絵の一番下の
一つの連続量に限って言うと,「どこまでも精度を求めても仕方がないじゃないか」という 気になりますが,次の図のように,閾値を無限精度で決めるということは,情報量的には,無限の二値の属性の中から,「好き嫌い」に 関する属性の有限集合(有限の台)を決めることにほかなりません.要は,「好き嫌い」に関する 有限個の属性を特定できるかという問いに何らかの答えを返す必要があります.
今まで,
ゲーデルの不完全性定理の中に現れるゲーデル数もそうですが,我々が日常扱っている事柄を数で
表現するのは分かりにくいものがあります.計算機科学が発達した現在は,数より分かりやすい体系があります.それは
A : アルファベット.文字列を組み立てる記号の集合.ここでは A は有限集合としておきます.
A* : A の記号の有限列の集合.ここでは長さ 0 の列も含めておきます.
Aω : A の記号の無限列の集合.
A∞ : A* と Aω を合わせたもの.つまり, A∞ := A* + Aω
A* は基本中の基本ですから計算機科学を専攻している方はよくご存じでしょうが, Aω や A∞ は余り出てこないのでご存じない人もあると思います.A* は無限個の要素からなりますが,その基数は ℵ0 で,自然数の集合と同じ大きさです. それに対して,Aω は 2ℵ0 で実数の集合と 同じ大きさであり,A* より遥かに巨大です.
もう一つ言っておくことがあります.A* は結構表現能力が高く,Aω の一部分の要素を表現することができます.というのは,A* はちょっとした公理系を 導入すると再帰関数を定義するためのプログラミング言語として使うことができます.この言語を 使って,無限列 (ai) i = 0, 1, 2, ... を i に対して計算する再帰関数を定義 すればよいのです.この A* の要素を使って,(ai) i = 0, 1, 2, ... を表現すれば, 本来無限列となり有限の文字列では表現できなかったものが,A* の中の有限の文字列で 表現できることになります.もちろん,全部は表現できません.|Aω| の方が |A*| より遥かに大きいわけですから,表現できるのはほんの僅かです.
この A* の有限長文字列で Aω の一部分を表現できるという性質は, 我々が円周率 π や自然対数の底 e などの無理数を有限の記述で表現できることを考えると分かりやすいでしょう. 実数すべての集合は 2ℵ0 の大きさがあり,その要素すべてが有限文字列の表現を持つという訳ではありませんが(すべての有限文字列の集合は ℵ0 のサイズ),一部は有限文字列の表現を持ちます.π や e などは 無限に続く桁を計算し続ける再帰関数があり,我々は,日常,有限長の言語によって それらの数を扱うことができています.まあ,各桁を計算する再帰関数まで持ち出さなくても, それらの数は,もともと定義が有限長の文字列でできていますね.
これらの用語を使うと「連続量の内部状態と離散量での会話のモデル」は,次のように書き表せます.
このモデルは,
我々が持っている伝達手段は A*,つまり,有限長の文に限られるため, 人は自分に内在する Aω の要素を伝えようとするのだけど,それは A* で表現できる要素に限られ,発話した瞬間に内在したものとの差異を感じて,何度も何度も言いなおす.とか,我々が時々経験する議論でのもどかしさを説明してくれているかもしれません.本当に Aω 間の伝達が可能なら,真に分かりあえたと 言えるのでしょう.
このモデルはチャーチのテーゼを理解するのにも役に立ちます.
チャーチのテーゼ
計算できる関数は帰納的関数だけである
このテーゼの文言で,「計算できる」は「機械が計算できる」という限定はなく,「人間が計算できる」も対象に入っています.
人間や機械の間を A* で伝達している以上,有限の長さの文字列で伝達されるものを 表さなければならず,それは有限の長さのルールで計算できるものに限られる訳です.したがって, 伝達手段を A* に限定している以上,チャーチのテーゼは成り立たざるを得ません.
年末,KNDH さんとお話したとき,彼は
と言われていましたが,私は,「チャーチのテーゼは経験則である,つまり,まだこれに反する例を我々が見つけ出していないもの」
という気がしています.もう一度,双方が元気なときに,お茶でもしながら議論してみようかと 思います.「陰に A* での情報伝達を仮定した下での不可避な結論」
ちなみに,Aω の要素 (ai)i=0, 1, 2, ... は Ai = A としたとき,Ai から要素を一つずつ取ってくる選択関数です. 選択関数 f(i) := a (定数)と言った有限文字列で表現できる,つまり,A* で表現できる 選択関数もあれば,そうでないもの,つまり選択の基準を明確に与えられないものもあり, 後者の方が圧倒的に多いのです.例えば,Ai を何らかの述語で P で Ai := {x∈A | P(x, i)} のように, 空集合に ならない程度に絞り込むと,選択関数の構成は非常に難しくなります.そういう非構成的な 要素,選択公理でしか存在を示すことができないような要素でも集めたものが Aω です.
今回は,前回の「AI (Artificial Intelligence) とは何だろうか? トライアル」の逆に見えることを話すと最初に言いましたが,実は前回と同じことを言っているの だろうなと思います.つまり,
人間の内部的に機械を超えたものがあろうがあるまいが,伝達手段が A* である限り,人間の能力と機械の能力は変わらないという主張です.前回の話を「伝達手段」という観点から見直したということです. 最後まで話してみると,話のとっかかりだったはずの「『好き嫌い』を論理式で 判断していない」は本当に関係なかったですね.
以前のメモ 「仕様は実装より分かりやすいか?(2019 年 11 月 16 日 (木))」で, 「仕様と実装はそれほど明確に区別できる概念では無いのではないだろうか?」と 言いました.さらに言えば,私は,
なのだと思っています.動かない仕様を実装というのは無理がありそうですが,実装の方は一応 作るべきものの機能を十分決めている訳です.どう作るのかと言ったところまで 決めすぎているという欠点はありますが, 決めていることに違いはないのですから,これが仕様だと言い張る人もいるかも しれません.もっとも,普通,「仕様」とはそれがなんであれ,書いた人が仕様と思えば仕様
こういう,「仕様」と「実装」など,ちょっと見では「明らかに」違うと思われる
1 | 仕様 | ←→ | 実装 |
2 | 発明(特許における) | ←→ | 既存技術の組み合わせ |
3 | システムをなす要素の集まり | ←→ | 単なる要素の集まり |
4 | 論文 | ←→ | 開発の報告書 |
5 | アルゴリズム | ←→ | プログラムコード |
6 | AI のプログラム | ←→ | アルゴリズミックなプログラム |
7 | R の発音(英語の) | ←→ | L の発音(英語の) |
8 | 意味(semantics) | ←→ | 形式(syntax) |
9 | 良いコメント (意味や意図を書く) | ←→ | 悪いコメント (プログラムの直訳) |
L と R は普段は英米人は明らかに違う音というのですが,フォルマントの特徴などから, 人工的にこれらの中間付近の音を作り出すと,かなり判定が難しくなるそうです.
上にあげた例の中の
となっています.「技術的思想の創作」という得体の知れないものも出てきますが, そのようなものの中で発明とは自然法則を利用した技術的思想の創作のうち 高度のもの をいう
この新しい効果としては,次の「金属製灰皿」の例がよく持ち出されます.
これをはじめて聞くと,「ほー,なるほど.それは確かにそうだな」と感心するのですが, よくよく考えてみると金属製灰皿の発明
従来例として陶器製の灰皿があり,金属製の灰皿を作った場合,それを発明として 主張できるか?これは金属製の灰皿が従来なかったなら発明になる可能性が高い. 一般に陶器の製品は落とすと割れやすいという性質があり,それを金属で作って,割れにくくする というアイデアは,他にも金属製の鍋などたくさん事例がある.しかし,この金属製灰皿は そういう壊れにくいという効果だけでなく,
金属製灰皿は熱伝導率が非常に高く,タバコの吸い口まで火が来る前に,灰皿のふちの部分で 火が消えてしまい,火事になりにくい
という効果があり,これは
従来にない新しい効果 である.
私は昔,ある知り合いに対して「特許とは何だと思いますか?」と聞いたところ,多くの人は
「と答えました.それを聞いて『驚き!』 だと思う.」
「へー,この人はスゴイな.ちゃんと, 人間の感性という観点から特許を認識しているのか.僕も,うすうすそうじゃないかと思ってたけど,こんなに完璧に 言い切ることはできないもんな.」と思ったことを今でも覚えています. 特許の分野では,「発明の構成に人間を入れてはいけない」という不文律(有文律かも)があり, 説明のなかから,極力,「人間性」を排除しようとするように思うのです. たぶん,これのおかげで,特許を生業としているような専門家と話すと,なかなか,発明の定義として 実質的に「人間の感性」が入っていることを認めた会話にはならないのです. 例えば,何か便利なことを思いついたので特許にならないかと専門家に相談すると
K さん,あなたのアイデアは単なる A 技術と B 技術の組み合わせじゃないですか. 「進歩性」*がありません. 従来にない新しい技術は何かということを書いてくださいよ.でないと特許にはなりませんよ.
*「進歩性」:先行技術を元にその技術分野の専門家が容易に成し遂げることができないくらい難しいこと
といった答えが返ってくるかもしれません.そこで,生真面目に
いやいや,T さん.A 技術と B 技術が組み合わされている訳ですから,必然的に何らかの シナジーは生じている訳ですよ.それを「進歩性」が無いというのは単に あなたの感性じゃないですか.どれだけ「進歩性」があれば良いというんですか. 私はこれでと返すと,こちらの話題のやり取りに移ってしまい,本来の特許に関する相談ができなくなってしまいます.こんな状態でも,特許の弁理士さんに 大金を積めばなんとか知恵を出して書いてくれるのかもしれませんが,私は,今,無職なので とてもそんなお金は積めません.そもそも弁理士さんに依頼するお金さえありませんし.十分 だと思いますよ補足.
ということで,世の中には,
の二種類がいるように思うのです.
ただ,「きれいに区別がつく」と
この二軸を使うと,次の表のように人間を整理することができます.私は,これを使って 人との摩擦があまり無い付き合い方を心がけています.
概念間の曖昧性に |
概念間の曖昧性を | |
正直者 | 境界が曖昧性だと騒ぎ立てる
|
二つの概念の違いを一生懸命説明してくれる |
悪党 | 明確な境界が引けないこともあると知りつつ,区別があると言う | <この組み合わせはない?> 発明の基準が明確でないことに気が付いてない悪党は何をするのか? |
私の知り合いには悪党が多いので,付き合いには細心の注意が必要です.正直者は, 私と, KNDH さんと, KRM さんくらいで,残りはみんな悪党です.言葉の裏に隠されている 「なにか」を常に読み取るようにせねばなりません.実は, 正直者どうしの付き合いも 大変です.まともにやると意見がぶつかり合います.つい先日,KNDH さんと3時間ほど お茶会をやって2日間ほど知恵熱を出してしまいました.
こういうふうに書いてみると,私は,すべての区別をなくしてしまいたい人のように見られる かもしれませんが,実は,区別をつけたがっている人なのです.
「仕様」と「実装」も, 「発明」と「単なる従来技術の組み合わせ」も,「システムのシナジー」と「単なる コンポーネントの寄せ集め」も,これらが区別できる概念なら,いろいろな指針が 立ちやすくなります.例えば,どうすれば「単なる従来技術の組み合わせ」が「発明」に なり,私に大金を運んできてくれるかが分かる訳です.そうしようとするためには, やはり境界をよく考える必要があり,それらを明確に区別している人たちにお聞きする訳です.
もしかしたら,こういう,なかなか結論の出ない問題は,ある程度,役に立つところだけ 使うというのが良い態度なのかもしれません.例えば,ここのメモで以前書いた 「『物理学の応用について (寺田 寅彦)』を読んで 2019 年 11月 23 日 (土)」では,寺田寅彦が
(物理学の)第一次の近似だけでもそのつもりで利用すれば非常に有益なものである. しかし学者が第一次の近似を求めて真理の曙光を認めた時に、といった類のことを書いていると紹介しました.「仕様」も「実装」も我々の感覚で明確に 区別できる場合が多くあります.そういうものを区別することは,ソフトウェアの 品質を上げたり,工期を守ったりするのにとても有効っぽいです.世人たる私は 枝葉の問題を並べ立てて抗議を申し込んでいるだけなのかもしれません.世人はただちに枝葉の問題を並べ立てて抗議を申込む 。
でも,この第一次近似に満足していて,それが常に有効だと考えると進歩がないと 思うのです.やはり,これらの概念をより有効に使うためには,境界の部分を明確にできる ような概念の先鋭化,エッジを際立たせることが必要と思います.
したがって,本来は,第一次近似の利益を享受しながら,境界を磨き上げるという態度が 必要なのだと思います.これはなかなか難しいですね.心の中に,相反する態度を保持 することが得意な人と苦手な人がいるように思います.私は苦手な人です.
結局,今回のメモは,
という態度が良い態度なんだろうなというお話でした.「利益の享受」の最中にも 次のステップに向かうヒントが出てくるかもしれませんものね.相反するいくつかのテーゼを頭の中に抱えながら,利益を享受しつつ,より高次の 理解に至る努力をする
ブレードランナー 十分ですよで検索をかけてみると, 結構たくさん見つかります.
前回予告したように長いので,目次を書きます.
目次
私が時々行く勉強会で,
「あーでもない.こーでもない.それはちがう.....」と言った感じで大もめします.
おまけに,この問いは突然でて来て, 議論している人たちは資料もなく,発話のみのやり取りで議論するので,各自の主張が なかなか掴みにくいものです.聞いていると同じ人の主張がだんだんずれてくるようにも思います. この問いの根っこには「人間と機械はどう違うのか?」という 疑問をはらんでいるような気がします.つまり,議論している人たちは,
という問いが深層心理の中にあるのでしょう.もしかしたら,心の中には明確なイメージ,あるいは理想が あるのかもしれませんが,表現として出してみると,その発話者自身「なんか違うな」と思って,言いなおし, それでだんだんずれてくるのかもしれません. あるいは,聞いている側もしっかり把握できていないので相手の主張が揺れているように思えるの かもしれません.(人間の知能を目指している)AIと機械(の計算可能性)はどう違うのか?
=人間と機械はどうちがうのか?
私はその勉強会で,一度
そのときの提案は,思い付きであまり練れてなかったことと,私自身はポジショントークするとは 言わなかったことからお流れになってしまいました.やはり自分が話す気になって提案しないと 良くないなと思いましたので,その第一歩として,今回,思うことをちょっと書いてみようと 思います.ここは,「メモのような日記のような」ですので,あまりしっかりしたものでなくとも, 後々,ポジショントーク用の資料の核になれば良いかなというくらいの気持ちです.
ポジショントークをする前に,自分自身の AI に関する関わりを簡単に述べておきます.
基本的には
私の主張の本質は単純で,次の3つです.
「AI」 というなんだかわからないものを,
主張だけでは何ですので,以下の項目について述べて,上の主張の理由付けと補強をしたいと思います.
では,それぞれについて意見を述べます.
上では,私は3つの項目で AI を特徴づけていますが,本質的なことは1つ目です.つまり,
という主張が核となっています.これはチャーチのテーゼAI は普通のソフトウェアと変わらない
に基づきます.つまり,計算できる関数はチューリングマシンやラムダ計算で計算できる 関数だけということで,もっと言えば,コンピュータの普通のソフトウェアで計算できる ものだけという提唱です.帰納的関数は「どんな入力に対しても必ず停止すること」という 条件が付けられますが,ここではずっと答えを求めて走らせ続けてもよいので, 帰納的関数を部分再帰関数(帰納的関数と同じ作り方なのですが,ある入力に対しては停止しなくなるかもしれない関数のこと)に変えておきます.並列計算を考えれば一つのプロセスを 走らせ続けておいても,次の問いには対応できるので,人間の能力を模したものという 意味ではこう考えておいてもよいでしょう.チャーチのテーゼ
計算できる関数は帰納的関数だけである
私自身はチャーチの提唱を信じているというか,信仰しているので,「AI は普通のソフトウェアと変わらない」という答え以外に無いのです.でも,これだと,聞いてる人からは不満がでるでしょうから,なんとか定義している体裁を保つために,ウーンと頭をひねって,
and/or
初期の AI をいくつか挙げてみます.
前の方のパズル,積み木の世界のロボットのプラニング,チェスなどのゲームは, 問題自身は明確なのだけど 解き方が分からないソフトウェアです.そのため,決まった手順で問題を解くのではなく, 探索を使って問題を解く手法がたくさん開発されました.しかし,15 パズルや ルービックキューブなどのパズルは最初はなかなか解き方が分からないのですが, 次第に,群論とか半群論とかを用いて解析されて行って,いくつかの基本的な 定理の組み合わせで解けるようになってきます.そうすると,それらを解く プログラムも探索を大規模に使うものではなく,比較的手続き的になってきます. 例えば,いくつかの条件判定や小規模な探索で初期の素解を求めて,それを最適化 するなどの解き方になってくる訳です.そういうものは段々 AI とは呼ばれなくなってきます. 今日,ハノイの塔のプログラムなどは誰も AI とは呼ばないでしょう.でも,はじめて あれを解けと言われた人間にとっては結構難しいものなのです.
後半の線画からの立体の認識や人工無能,自然語翻訳は問題の定式化自身が難しい例です. 線画からの立体の認識は問題を限定すれば定式化はある程度できます.例えば,
点の間が直線で結ばれている図形から,線のつながり方の制約から, 各線が飛び出しているのか,引っ込んでいるのか,あるいは物理的に無理な 接続の仕方なのかを判定せよという問題なら,定式化は線のつながり方の制約を列挙する位でしょうが, 「人間がどのように凹凸を判断しているか?」というところから考えると 問題はそれほど明らかではないでしょう.
人工無能の例は
どういう対応だったら,人間はその対応をしているものが人間であると感じるのか?という問いへのアプローチなのだと思うのですが,この問いはなかなか定式化することができません.
そのために,いくつかの仮説を 立てたり,実験的に対話させてみて,不自然に感じるところを修正していくことに なると思います.
自然語翻訳も簡単なものなら,二つの言語の間の文法の対応規則の適用ということになるでしょうが, そうやってできた翻訳文には我々はすごい違和感を感じます.そうすると,「自然な翻訳とは」 と言った定式化の難しい問題が出てくる訳です.
これら「人間の感じ方」に依存していて,定式化の難しい問題も,「人間の感じ方」の部分に 関する知見が蓄積されてくると,定式化可能な部分が多くなってきます.線画からの 凹凸の判断などは典型的でしょう.この問題に初めて出会った時は,人間がどう判断しているか分からないのですが, 1960 年代の初期の段階ですでにいくつかの凹凸判断のルールが抽出されていました. 自然な会話の条件やこなれた自然語翻訳の断片的なルールもいくつか発見されていて, 長時間,機械だと判断できない会話ソフトウェアや極めて自然な翻訳文を生成するソフトウェア などが出てきています.
先走りましたが,こういう,
その特徴の度合い(問題の定式化と解決方法の記述の難しさの基準)はテクノロジーの進歩とともに変わるを上げています.
以上,古い時代の AI の知識から,AI とは何かを論じましたが,現在のディープラーニングなど のテクノロジーが入ってきても,「問題の定式化と解決方法の記述の難しさを AI の基準にとる」 ことはまだ有効なのではないでしょうか.インターネット上の膨大な画像からネコを判定する プログラムも問題の定式化と解決方法の両方が難しく,ディープラーニングはこのような 問題に対応できるという解釈でいけるかなと思います.
また,最初はディープラーニングなどで無理やり解いたとしても,そのうちに ディープラーニングで学習した結果のデータからいくつかの概念整理の技術などが 出来てくるかもしれません.そうすると,人間とのうまい対話を学んだ AI システムから 「人間とのうまい対話」に必要な条件を記述するための諸概念が整理されるでしょう. 人工無能も,問題の定式化と解法の記述,ともに不明な部分が少なくなって いく訳です.
以上,私が思う AI の特徴づけの基本的な考え方を述べました.次は,ほかの人たちが 提案している AI の特徴づけに対する反論と最後に AI は人間を目指すべきかに関する意見を 述べます.
ここでは 「AI とは何か」に対する二つの仮想的な主張を相手取って反論 してみます.あくまで「仮想的な」主張で,実際の誰かの主張という訳ではありませんので 反論は一方的です.こういう「妄想」に対する議論は,般若心経の
菩提薩埵 依般若波羅蜜多故に反する行いで,心の平安からは遠いところにあるのですが,主張の差を認識する上では有効な 手法と思います.
心無罜礙 無罜礙故 無有恐怖 遠離一切顛倒夢想
究竟涅槃
考察する主張は次の2つです.
上では,チャーチのテーゼに対する信仰で,
私は,「人間のできることは機械でもできる」という立場をとります.もう少し正確に表現するなら
です.例えば,誰かが,何らかのスゴイ推論をしてある結論を出したとします.人間の思考で結論して,他人に説明できることは,機械でもその思考の過程をシミュレートできる
それを他人に説明するときは,聞いている人の理解を得るためには, 推論がきちんとした論理でつながっていなければなりません. そうでないなら,
ということで,「説明はできないけれど,俺はスゴイ結論を得た. 信じられないかもしれないがこれは本当のことなんだ」
よく,
という文言が頻繁に出てくるからです.これから,ある人たちは正しいけれど,証明できない命題が存在する
人間には正しいということが分かるけれど,機械にはそれが出来ない命題が存在する. 言い換えれば,と考えて,人間と機械に差を置き,心の安定を図るのだと思います.また,別の人たちは,人間と機械の差ではなく,神のようなものと人間の差ととらえて,「真なる命題だが,人間にはそれを 知ることができない命題があり,それが人としての知性の限界を示している」と考える人もいるみたいです. とにかく,ここでは「正しいけれど,証明できない命題」の人間は機械が真であると知ることができない真なる命題を知る能力がある .
これらについて簡単に述べておきます.
ゲーデルの(第一)不完全性定理は,
ある程度強く,かつ,系統的に列挙できる公理系では,必ず証明も反証もできない命題が存在するということを言っています.この時点ではそれほど問題の無い文言だと思いますが,その証明も反証もできない命題の例が上で述べた,所謂,
なのです.これを解説します.正しいけれど証明出来ない式
次の図はゲーデルの(第一)不完全性定理の内容
算術が表現できるくらい強い公理系で,かつ,その公理が計算機などで 列挙可能で,かつ,その公理系が無矛盾なら,証明も反証もできない閉じた命題があるを表しています(正確には,ゲーデルの後,少し補強されたものですが).「閉じた命題」というのは,その命題に現れるすべての変数に全称記号 ∀ か 存在記号 ∃ がかかっていて,変数の値で真偽が変わらない命題のことです. ここで「命題」と言っているのは,正確には数理論理学でいう「論理式」の つもりです.全称記号 ∀ や存在記号 ∃ が現れる式です.あまり論理学を知らない人には「論理式」という言葉は分かりにくいだろうと 思い,より一般の言葉である「命題」を使いました.逆に論理学を知っている人には,命題論理の 「命題」と勘違いさせるかもしれないので一応断っておきます. また,上で公理系の条件に「無矛盾である」を入れましたが, 矛盾のある公理系では,すべての命題が証明されてしまい, 通常,それは我々が望む状況とは異なりますから,以後, 「無矛盾性」の条件ははデフォルトでついていると思ってください.
図を説明します.何か公理系Aを定めたとして,その公理系は算術が表現できるくらい強力で, 公理を計算機等で列挙することができるものとします.そうすると公理から推論規則(普通は 三段論法(modus ponens)と全称化(現れる変数に全称記号 ∀ をつける推論規則))を 使って証明可能な命題を次々に生成していく証明機械を考えることができます.この証明機械が 生成していく命題を P とします.それを「証明される命題 T」に溜めていきます.また,同時に P の否定 ¬P は「反証される命題 F」の方に溜めていきます.これは反対の証明が見つかる命題で 絶対に偽の命題です.P が¬Q の形のときは,Q もこの F に入れておいて良いでしょう.
先ほど言いました閉じた命題,つまりその命題に現れる変数すべてに ∀ か ∃ が 掛かっていて,変数への割り当てに関わりなく真偽が決定 している命題について,上の機械証明の手続きはそれを「証明される命題 T」か 「反証される命題 F」のどちらかに必ず分類できるだろうかという疑問が生じます.
このような
と言ったものがあります.公理系Aに条件G : G は公理系A で証明できない
正確には命題の字面だけでなく,その字面の意味も記述できる必要があります. 例えば,"(1 + 1 + 1) mod 2 = 1" を符号化した結果を受け取って,"true" を 符号化したものを返す関数がその公理系で定義できるなどです.算術でもある種の 簡単な文字列の体系でもそれはできます.
とおけば,命題 P が証明可能であるということはAX(n) := {ax(i) | i ≤ n}
TH(n, m) := 公理の集合 AX(n) を使って,長さ m の証明で証明できる命題
になります.これは,k = 0, 1, 2, ... に対して, n + m ≤ k の組 (n, m) の TH(n, m) を調べていけば機械的に調べることができます.集合論で有理数が可算集合であることを 証明するときの方法と同じですね.ある n と m があって,P が 命題の集合 TH(n, m) に入っている
という命題を作ることができるようになり,この G が仮に証明されると,その内容は G は証明できないですから,矛盾となり,また,これが仮に反証されると,G に内容の 否定,すなわち,G が証明されるとなって,これも矛盾が生じます.まとめると,G : G は公理系A で証明できない
G が証明される => G は証明されない => 矛盾したがって,G は証明も反証もされないので, 証明できないことがわかり,次の図(先ほどの図の再掲)で「証明も反証もできない命題 U」が空集合ではなくなる 訳です.G が反証される(¬G が証明される)=> G が証明される => 矛盾
もし,仮に U が空集合なら,機械で次々に公理から証明を作り,「証明される命題 T」と 「反証される命題 F」を作っていくことで,どんな閉じた命題の真偽も決めることが できます.つまり,C 言語風に書くと
/* P は証明されるか反証されるかを調べるために与えられた命題 */ k = 0; while (FOREVER) { for (n = 0; n < k; n++) { if (P が TH(n, k-n) に入っている) { return P は証明される; } else if (not P が TH(n, k-n) に入っている) { return P は反証される; } } }のような手続きで,証明可能か反証可能かを調べることができる訳です. しかし公理系が十分強くて,かつ,計算機などで列挙できる場合は,
が与えられると,上のC 言語風の手続きはG : G は公理系A で証明できない
もう一つの前提知識として同じくゲーデルによる
です.ここで公理系A から証明できる命題の集合は公理系Aを満たすすべてのモデルで成り立つ命題の集合の共通部分と等しい
つまり,ゲーデルが想定している証明システムは,真なる命題を完全に証明できるシステムで あるという意図です.公理系A のモデルすべてで成り立つ命題は,公理系 A で証明できる
(第一)不完全性定理の「完全」という意味と完全性定理の「完全」という意味は違う意味で 用いられています.
これで議論するための前提の知識を説明し終わりましたので,いよいよ核心の命題 G の 話に入ります.
我々の関心の的の命題 G をもう一度書いておきます.
G は(第一)不完全性定理により,確かに公理系A からは証明することができません. G の内容は,「G は証明できない」ということで,しかも,確かに証明できないのですから, ちょっと考えるとG : G は公理系A で証明できない
ということになります.G は正しいけれど証明できない命題
ここで
その命題が「公理系A のすべてのモデルで成立する」ならば, その命題は「公理系A で証明できる」と言っていますので,「G は証明できる」ことになってしまいます.したがって,
「G が正しい」ことを導いたのは誰で,それはどこで行われた推論だったかを思い起こす 必要があります.
「G が正しい」ことを導いたのは,のです.ここで,「メタな立場」とは,公理系A や証明システム,モデルに関する我々の 議論の立場であす.また,それと対の用語として, 公理系A や証明システム,モデルの中で行われる推論や正しさの評価を我々 であって,それは公理系A や証明システム,モデル をメタな立場 からみたメタな推論 においてであった
G はこういう立場の命題なのです.
では,先ほど行った
を導いた推論はどこにいったのでしょうか.これはメタな立場の推論なので,我々の 推論のシステムを何らかの公理系で規定したとき成り立つ推論です.このとき 用いた推論は,高々,背理法程度なので,この推論もメタなレベルの適切な公理化 と推論ルールの設定で, 機械でシミュレートできるはずです.G は正しいけれど証明できない命題
ということで,ゲーデルの不完全性定理は,別に人間ができることと機械ができることの 間に境界を設けたものとは考える必要はないという説明を終わります. 混乱の原因は,
と言われること正しいけれど証明できない命題
人間と機械の能力に差がある根拠とみなされがちだった不完全性定理に関する状況を 一応整理したところで,最初の議論に戻ります.
今まで述べたように,私は AI が目指している人間というものが機械より優れた推論能力を持っているとは考えておらず, 人間と機械は同じ推論能力であると考えています.また,その推論能力は 計算の言葉に言い直すと,帰納的関数(あるいは,部分再帰関数)です.
しかし,最近,量子計算など,従来と異なる計算モデルが出されてきています.したがって, 将来,帰納的関数より強力な計算原理が発見される可能性は否定はできません. でも,そうならそれを計算機に組み込むこと によって,現在,「帰納的関数」と言っている計算能力のベースをその見つかった 「(新)帰納的関数」に置き換えれば,「人間のできることは機械にもできる」ということに 変わりはないと思います.もとの主張が動いている気がして,ちょっと卑怯な気がしますが 少し逃げを打っておきます.
もう一つ逃げを打っておきます.ここでの議論は一階述語論理のお話で,二階以上の高階論理の 場合は,私はあまり良く知りません.でも,なんとなくですが,大丈夫じゃないかと思います.人間が推論したことを 他人に納得してもらうには,論理が必要で,どこかの階では,こういう一階の論理学を使った 説得が入る訳ですから,その部分で機械でシミュレートできるはずです.
もうひとつ,私の知り合いに,
AI の特徴はと言われる方がいます.私自身,センサとアクチュエータの重要性は否定しませんし, 実際,人間はそれによって進化の中で,現在の能力を獲得したのだと思います.センサ とアクチュエータ を持つことであって, センサを通して外界から得られる膨大な刺激に 対して,アクチュエータでアクションを起こし,そのフィードバックで学習を行うシステム
しかし,センサとアクチュエータの有り無しをもって,AI かそうでないかを定義するのは 違うんじゃないかなと思いますので,ここで少し反論しておきます.もっとも,私は その方の主張を全部聞いたわけでなく,上の文言を聞いたくらいの状態ですので, これも仮想的な主張(私の妄想)に対する反論な訳です.どちらかというと,今度議論するときの ための下準備です.
上の定義への不満は2つあります.
一つ目は,現状 AI と呼んでいるものの多くが AI と呼べなくなって不便だということ位なので 実は大したことではありません.「呼び名を変えれば良いのかな」位の話です.重要なのは 2つ目です.これも,計算能力としては普通の帰納的関数で表現されるものということなら, 別に問題はないのですが,それを超えるきっかけとなる因子と考えるならそれは違うのでは ないかと思う次第です.
確かに,センサーとアクチュエータを持ったシステムを絵に描いてみると,なにかすごいことが できそうな気がします.センサーを通して得た膨大なデータから判断したアクチュエータを介した 外界への働きかけ,そしてそのフィードバックの獲得,そのサイクルの中でも推論部の学習, このようなプロセスで従来のソフトウェアでは実現しえなかったような学習が行われ,「知能」と いうものに近づいていくような気がします.
でも,疑問もあります.推論部が帰納的関数のままでは,結局,次の図のように, AI システムは取り込んだデータを 離散化し,普通の帰納的関数で計算し,それをアクチュエータに出力するだけなので,やれることは普通のソフトウェアと同じなのではないでしょうか.これは推論部にどんな技術を使った としても,いまだに,帰納的関数以上の計算能力を持った計算原理は発見されていないのですから, このようにセンサとアクチュエータを備えたとしても,しょせんは普通のソフトウェアと 原理的には変わらないということになりそうです.「フォン・ノイマン・ボトルネック」の 言葉を真似すれば,「推論部ボトルネック」あるいは「計算原理ボトルネック」です.
もちろん,「AI は,普通のソフトウェアと原理的には変わらないが,その中で
センサとアクチュエータを備えたものを AI と呼ぶ」という,
もしかして,上の図のように,
はっ? もしかしたら図の見方が逆なのかもしれません.真の AI システムは図の右側の
確かに,宇宙でしたら,有限だか無限だか分からない状態を持ち,連続量を伴う現象が起き, そして解明しつくせない法則が支配していて,帰納的関数の束縛から自由であるのかもしれません. 右側の AI システムのふりをした観測システムは,アクチュエータを介して,真の AI システムに 入力を行い,宇宙空間でなされた不可思議な計算結果を,センサで受け取っているの かもしれません.
しかし,これだと,帰納的関数を超えたものを「宇宙」というなんだか分からないものに 押し付けただけなので,何らかの新しい原理を提案することが必要になってくるのでは ないでしょうか.
ということで,私にはまだ,センサとアクチュエータを備えた AI の提案が, 単にソフトウェアの分類を与えているのか,新しい計算原理を提案しようとして いるのか分かっていません.
今度,ぜひ,その方の主張の深いところまでをお聞きしたいのですが,そうすると,必然的に 私自身もその議論に深くかかわることになり,それほどの能力の無い私は辛い目に合わなければ ならなくなるのです.その決心がついたら...あるいは,誰か援護射撃をしてくれる人が いる状況を狙って...
これまでさんざん,AI は人間を目指していると文中では書いたのですが, 今回私がやった特徴づけは,
ということで,人間を目指しているという項目はありませんでした. もし,その条件を入れると,やはり 「人間て何?」という問いに答えないといけません.私はこれに答えられないし,答えようとすれば 機械と変わらないという答えにならざるを得ないので,この条件は入れられないのです.AI とは,仕様が作り辛いソフトウェア and/or解法が作り辛いソフトウェア
ということで,私としては,AI は人間を目指すという立場ではなく,
世の中の AI 研究のアプローチに大きく2種類あるのかなと思います.
これを図にしてみました.
「人間とは何か」アプローチでは,人間の思考過程の解明などが 最終目標になっていて,そのモデルなどを作り,それを検証するために何か試作品を作ってみて, モデルを修正していきます.一方,「高度な機能追及」アプローチは,なにかスゴイ機能を作りたい のが動機ですから,人間がやっていることにこだわらず,役に立ちそうな方法は試してみます. 機能実現のために無節操にやっててもすぐアイデアが枯渇して行き詰ってしまうので,ときどき, 「人間とは何か」アプローチの人たちがどんな仮説やモデルを作っているのか覗いてみると ブレイクスルーになることがあります.
私としては,
以上,今回のメモは,たぶん,
これを書いてから約一か月後,ここでの議論の反対に見えるかもしれない
機械と人間は違うか? - A* と A∞ - 2020 年 1月 15 日 (水)を書いてしまいました.そちらはここの続きですので,こちらにご興味があれば是非!
最近,このコーナーに書いている話も随分長かったり,重かったりするものが続いているような気がするので, 今回は軽いものにとどめておこうと思います.この次の話も長くなるんじゃないかと 予想しますので(次は AI についての予定です).
一般に数学や計算機科学などで,複雑な概念を理解するのに,その概念に関する
では,説明しようとする概念と直接関係のない,人型のキャラクターのような絵(ここでは,
ということで実験をしてみましょう.説明対象として,1つ前のメモに載せた
まず,
次に
少し,説明されている気がして,聞こうという気になりませんか?
逆に
こうなってくると,読者は,「実は文章を読ませられているんだな」ということに 気が付いて,人型のアイコンの効果は薄れていくと思います.
上の実験は非常に公平性を欠き,かつ,不十分な実験だったと思います.一般にこの手の実験はとても難しく, また,たくさんの被験者を必要とします. だいぶ前に,映像が学習にどのような効果があるかという研究のサーベイを見たことがあります.
この本は,映像が人間によるモノの理解にどのような影響があるかに関する色々な理論の サーベイが載っています.ここでは映像は,動画だけでなく静止画も含んでいるようです.中島義明 : 映像心理学の理論, 有斐閣, 2011 年
その本に載っていたことですが,発表された論文によっては,ある研究では映像が効果的であるという 結論を導き,別のある研究では効果がないという結論が導かれているなど, 正反対の結果が得られているものが たくさんあるということです.どれも実験で出された結果なのですが, 実験の前提条件を揃えることがとても難しいのでこのような状況が生じているようです.また,「理解に効果がある」という 指標も正確に定義することがとても難しいんだと思います.
今回は「軽いメモ」ということでしたので,ここでこれらに深入りするのではなく, 関連する項目のメモを列挙して終わりにします(上にあげた本とはあまり関係がなく,私が いろいろな本を読んだり,人と話して感じたりしたことです).
・・・
今回は「軽くやる」という方針でしたので,ここらでやめておきます. それでも随分,長くなってしまった気がしますが...図が多かっただけですね.きっと.
私は.とあるところで,C言語の基礎を終えた大学生の実習編を担当しています. そこに来ている学生さんたちを指導して思うのですが,彼らは殆どフローチャートを書きません.
実は,学生さんたちは他の図も殆ど書きません. 他の図とは,例えば,ポインタで繋がっているリストの図,データ構造の図, 問題を分析した結果の何らかの構成図,また,これは図ではないかもしれませんが, 日本語など自然語で解法を抽象的に書いた疑似コードなどです.また, 制御フローを表す図でも,好き勝手なフローが書ける伝統的なフローチャートのほかに, 構造化されたフローを書くことに特化した,構造化フローチャート,PAD図, NSチャート, HCP図などもあります.これらも書きません.
大部分の学生さんたちは,このような図を書かずに,エディタに向かって 直接プログラムを書いていきます.それでプログラムが 書ける学生は良いのですが,書けない学生はなかなか課題を進めることが出来ません. もしかしたら, 彼らはフローチャートや疑似コードの書き方を(全く or 十分には)習ってないのかもしれません. 従って,頭の中にあるもやもやっとした解法を表現する手段が,直接実行可能な 詳細度を持つプログラミング言語しかないので,なかなかそういう詳細のコードを 出力できずに苦労しているのではないかと感じます.私はその大学の教育全体に係わっている 訳ではなく,学生さんたちがどんな教育を受けてその実習の場に来ているか 知らないので,上に書いたことは想像がずいぶん混じっています.
で,これも想像なのですが,この状況は1つの大学だけの状況ではなく,全体的な 状況なのではないかと思っています.理由は二つあります.一つ目は,私があまり段階的詳細化と いう言葉を聞いたり,目にしたりしないことです.特に本屋で「段階的詳細化」という語を タイトルにつけた本に出会った記憶がありません.こういう構造化フローチャートの技術とか, 段階的詳細化の技術は殆どロストテクノロジーと化しているような気がします.
二つ目の理由は,自分自身の心の中を覗いて 思うのですが,私自身がフローチャートを書かねばならないというニーズが殆ど無いこと です(他の構造化フローチャートも同様).C言語は,ほぼ構造化された疑似コードと 変わらず,(私たちは)これを使って段階的詳細化が行えるので,特にフローチャートを起こす必要性を 感じないのです.これは一般の先生方も同じなのではないでしょうか.先生方も, 自分たちの成長のある時期までは, フローチャートや疑似コードなど,何らかの中間的な表現手法でプログラムを作成する技術を学んだと思うのですが,
で,今回のメモの内容は次の二つです.
という疑問にしておきます.「プログラミング初心者がプログラムを作るときや教師からプログラミングの説明を 受けるときの補助資料としてPAD 図とC言語風疑似コードに違いはあるのか
「段階的詳細化法」とは,1960年代後半から1970年代,もしかしたら,1980年代の
初めくらいまで,提唱され,使用されていたプログラム作成の方法で,
こういった短所はあるのですが,しかし,小規模なプログラムで限定的に使い, 「一度に詳細化せずに段階的に詳細化する」くらいの緩い原理として使う場合は結構有効で, 教育においても初期段階から使ったら良いのになと思います.実際,私は全然課題を 進められない学生には,
と勧めています.その学生が書いたものを見ながら,まず,日本語か,自分の得意な言語で,大まかに解法を箇条書きで書いてごらん
とか,分かって来るのです(私も学生さんたち自身も).ああ,ここがまだ一塊のままで,中がどんな手順になるか見えてないんだな
段階的詳細化をこういった個人の工夫で使っている場合は結構あると思うのですが,我流なので, 何か標準的な方法/記法があると良いと思います.次のトピックスの PAD のように, それほど難しくない大らかな技法として.
でも,こういう技法の制定はすぐ詳細化・特殊化してきてしまうんですよね. 技法の開発者さんとか標準化屋さんは,何かを詳細に決めていくのが自分の価値だと思っているので.
それと,「今更,段階的詳細化か」ということで,研究者があまり飛びつきにくいトピックスで あることも,この標準的な手法が確立されない理由なんでしょうね.あまり,論文ネタに ならないとかで.
PAD (Problem Analysis Diagram ) は H 製作所が開発した 構造化フローチャートです.世の中に既知の事実なので, 別に社名を伏字にする必要は無いのですが,私の昔いた会社なので,なんとなく, 直接書くのが躊躇われました.最初に PAD に出会ったのは 1982年頃,私が 修士1年の学生だったときに,ある研究会で,当時,H 製作所のF村Y彦さんという方が紹介したときだったと思います(F村Y彦さんは,Wikipedia によると,後に早稲田大学の教授になられ,さらにその後ご自分で会社を 作られているようです).
なんか,見るからに怪しそうな風貌と言動のF村Y彦さんが
PAD の普及のためにあちこちで講習会の講師をやっているんですけど,時々,「その書き方は規格と違います」と逆に注意されるんです.とか言われていたような気がします.当時の私は,「へー,真面目そうな企業の社員なのに面白い人だな」と 思った記憶があります.もともと,私たちが作ったのに,規格化されると,もう私たちの自由にはならないんですよ.
PAD 自体はかなり簡単で,基本的には次の3つの規則を覚えておけば書けます.これらは構造化プログラミングの3つの要素ですね.
他にも規則は沢山ありますし,流儀も沢山あるように思いますが,私は, 上の3つを使い,箱の中に適当な自然語を入れて使っています.
皆さんもお分かりと思いますが,実は,PAD で書いた殆ど同じものが,C 言語で書けるのです. 要は PAD は C 言語の構文木をグラフィカルに書いているだけですから.
例えば,「エラトステネスのふるい」で N 以下の素数をすべて列挙する手順を C 言語風疑似コードと PAD で書いてみます(小さい数からはじめて,見つかった素数の倍数を消していって 残ったものが素数という方法).
まずは,C 言語風疑似コードです.
続いて,PAD です.
多少,視認性が違うような気がします.私は,この二つの効果が,学習者や, これを参考にしながらプログラムする人にとって,本当に違うのかずっと 悩んでいました.もっというなら,現在進行形で悩んでいます. これら二つはロジカルには等価なものを書いているつもりだからです. 書いたり,修正したりは,C言語風疑似コードの方がはるかに簡単です. でも,初学者に見せたとき,どちらが分かりやすいかと言うと PAD 図の 方が分かりやすいのではないだろうかと思いますので,学生さんたちに説明するときは, PAD 図に落とすようにしています.もしかしたら,PAD 図はフローチャートほどは 一般的ではないので,学生さんによってはこの図を読めない かもしれないという心配はありますから,有難迷惑なのかもしれませんが.一応,凡例はつけているので, それを見て解読はできると思うのですが,そういうことを総合すると,C言語風疑似コードに 理解容易性において劣るかもしれません.
いろいろ,あーでもない,こーでもないという議論をしてしまいましたが,現在, 私の中では,
さらに,色を加えるともっと印象が変わります.
また,PAD 図とC言語風疑似コードとは出っ張り具合が違うということに着目するなら, 横顔の対比の方がよいかもしれません.
つまり,疑似コードに比べての,PAD の極端な凸凹,四角の区切り,文章と if や while などの 構文要素の明確な分離は,人にその処理フローの特徴をかなり明確に印象付けるもの ではないかということです.
ということで,プログラミングや計算機科学,数学でも,ロジカルには一緒でも印象が 違い,学習効果が異なる教具が存在し得るという個人的な結論を出して,今回のメモは終わりに します.
けど,...
最後にもう一つ.最近の学生さんがフローチャートを書かないことに関して,もう一つ気が付いたことがあります. 最近の学生さんは,goto も殆ど使いません.もしかしたら goto を習って ないのかもしれません.学生が goto を使うのを見た数少ない例では,その学生はどちらかと いうと優秀な学生でしたから,自分で習得したのかもしれません.フローチャートから プログラムを起こす場合は,goto がある程度出てきますから,フローチャートを書かないことが これに寄与しているのかもしれません.goto は,エラー処理など,ある局面ではプログラムを 分かりやすく書く効果はありますが,一般的には処理の流れを分かりにくくするので, 殆どの学生が goto を使わないという状況は,今の教育は構造化プログラミングの普及に 成功しているのかもしれません.ただ,上にも書きましたように,これは図を排除することが 良いと言っているのではありません. フローチャート以外の図や何か詳細なものに落とし込む手前の表現形態を勉強させることは 初学者の躓きを無くすことにつながると思います.
学生さんたちがあまり図を書かないのは,いったん図を起こして(b),そこからプログラムを 作る方(a)が,直接プログラムを作る(c)より手間がかかると思うからなんですよね.「三角形の 二辺の和は他の一辺より長い」ですね.でも,c が絶望的に出来ないときは,a + b の方が 短い訳で. 急がば回れなんですよね.
学習というような大げさなものではないかもしれませんが,プレゼン資料を自分で読むか, 相手に説明してもらうかで,理解の程度に差があるように感じますので,今回はそれに ついて考えたことを書いておきます.あまり整理されていないのですが,追々,整理して いきたいので,忘れないうちに考えたことを書き下しておこうということです.「難しいことを 比較的容易に理解するためにはどうすればよいか」というのが私の重要な関心事だから, こういう思い付きは大切なのです.
私は,とある勉強会に時々出かけるのですが,発表資料が事前に PDF で その会の web-site に掲示されるので,それを読んでいきます. 自分で読むのは,自分のペースで進められるのでとても良いのですが,やはり 理解できないところもあります.そういうのを,実際に勉強会に行って,発表者の 説明でプレゼンを一枚一枚進めていくと,自分で読んでいて分からなかったことが とてもよく分かるのです.
いま述べた例はとてもまともな比較にはなってないとは思います.例えば, 上の例で発表者付きのプレゼンでは,
でも,私の感覚的にはそれ以上に理解が深まっているような気がするのです.また,発表者によっては プレゼンに文章を書き,それをただ読むだけという人もいますが,それでも,発表形態の ほうが理解が深まっている気がするのです.
ということで,今日のメモの内容は,この「理解が深まる(と感じる)」理由はなんだろうか, 思いつくもののメモを残しておこうということなのです.上に述べたような第1因子を 置いておいて,第2の因子を考察するのですから,あまりまっとうな話ではありません. 趣味の一人ブレインストーミングです.
とりあえず,すぐ思いつくものを挙げてみます.
今回はこれらについて一言ずつ述べてみます.
認知科学での用語で,ワーキングメモリモデルの中央実行系のサブシステムの一つで 言語・音韻情報を保持する記憶貯蔵庫だそうです.聴覚の短期記憶です.発表者がしっかりした音声で説明してくれると,自分で読んだときは あまり働かなかった音韻ループがしっかり働いて,記憶や理解を助けるのかも しれません.発表の場合は,音声の反復を含んでいる訳ではないので,正確には 当てはまらないかもしれませんが,何らかの効果はあるんじゃないかと勝手に 想像しています.一方,音声を頭の中で木霊するのはそれなりの時間がかかるので, 頭の中での音読は,読書を遅くする理由として挙げている人もいるようです. 「速読」を主張する人とか.技術的な基礎の学習とかは,しっかり定着させることが 必要なので,ある程度時間を掛けてもよいのではないかなと思います.
私は,6年前,会社を辞めた頃,学習に,「説得術」が使えないかと考えたことがあります. 無批判に何かの陳述を受け入れるのは学習とは言えないかもしれませんが, 生き物である私たちが,ある種の知識を手に入れるためには,保持すべき知識を受容しないと いけません.したがって,取り込みを楽にするための方便として,このような 説得術に基づいた手法もあっても良いのかもしれないと思ったのです.もちろん, 無批判の取り込みは良くないので,しっかり有効性を確かめたあと,それを 受容し,活用する手段としてではありますが.説得術で すぐ思い浮かぶのは,
があります.「小手先だけのテクニックで要求を飲ませるのは良くない」と言った 注意書き付きですが,色々なテクニックがあるようです.こういうのもプレゼン, あるいは,学習で役に立つかもしれません.例えば,とても難しい大きな定理を理解するのに, まずは,その定理の系から導かれる小さな例題をいくつか理解してから,その 大きな定理の理解に取り掛かるとかです.この例は結構普通ですね.
プレゼン資料からの学習形態として,他に,展示会でのパネル展示などがあります. これは置いてあるパネルを読んで,分からないことを説明者に聞くことができるので 結構充実した学習ができます.時々,読んでいる最中に,説明者が,「ご説明しましょうか?」と 割り込んでくることがあったり,もう読んでしまって声を掛けて欲しいのに誰も声を掛けて くれなかったりすることもあります.そこでの説明者のスキルは,お店で,タイミング良く お客さんに声を掛けることができる店員さんのスキルと共通のものがありますね.
会社を辞めてから6年間,久しくこういう展示会場に行ったことがなく, 世の中に取り残されている気がするので,何か無料の展示会などを探して 行ってみようかと思う今日この頃です.
このサイトの別ページで, 青空文庫に挿絵を付けて紹介する(寺田寅彦の作品は, こちらで紹介)というのをやっていますが,昨日,寺田寅彦の 次の随筆を紹介しました.寺田寅彦は, Wikipedia によると,戦前の日本の物理学者、随筆家、俳人(1878年(明治11年)11月28日 - 1935年(昭和10年)12月31日))です.
この随筆は,文字数にして 3,300文字位(400字詰め原稿用紙9枚)の短い随筆ですが上の場面の文章がとても気に入りましたので こちらでも紹介したいと思います.
この随筆は上の絵でも説明しましたように,物理学を色々な分野に応用していくときの, 心構えや方法について述べているものですが,理論を実際の応用に持っていくときは, 色々な抵抗に会うということが,この随筆の中に次のように書かれています.
...
この随筆は百年以上前に書かれたものなのに,今日でもこの状況は変わってないように
思います.つまり,
ところで,同じ人がこの世人と理論適用の提案者になっていることはないでしょうか? つまり, ある事柄については,理論適用の提案者になって,世人の態度に大いに憤慨しているのだけど, 別の事柄については,世人となって別の提案者を攻撃しているとか.
例えば,私は,一つ前の日記の 「仕様は実装より分かりやすいか?」 で形式手法に ついて,かなり否定的なことを書いたと思います.これは,今をさること約40年前,1982年ごろ, 大学の研究室で作っていたプログラムの検証システムの経験がトラウマになっていることが あります.私も少し作ったのですが,大部分は私より前の学生さんや先生が作って,私は 主に,このシステムを使ってその妥当性を調べる役割でした.
そのシステムでは,プログラムが満たすべき性質や補助的な情報 を一階述語論理で与えると,証明すべき一階述語論理の論理式を生成して,後は, そのシステムに備わっている証明システムでひたすらその論理式を証明するというものでした.
ほんの小さなプログラムでも証明すべき式はすさまじく大きくなります.そこの建物は 4階建てでしたが,ラインプリンタ用紙にその論理式を打ち出して,4階の窓から垂らすと, きっと下までついてしまうほどの論理式を相手にしないといけないのです(ラインプリンタ用紙は 一ページごとにミシン目がありますがずっと繋がっています).
論理式の一部分には x=x のような自明な論理式も含まれているので,そういうのを除去するとある程度までは小さく なるのですが,それでも量に圧倒されます.そのとき,証明の空間を直に感じとったのが トラウマになっていて,形式検証にちょっと否定的な気持ちが出てきてしまうのです. もちろん,計算機も当時から比べるとすさまじく良くなったのですが,やはり,証明の 空間は莫大です.ちなみに,これはAI(人工知能)にも絡んだ問題だと思います.人は証明空間に 均等に関心を持っている訳ではないので,何か人の活動に関連の深い部分空間に限定する 方法はあると思いますが,何となく私はこの広大さに恐れがある訳です.
形式検証にしてもAI(人工知能)にしても,その発展のどの段階でも,(人と言うお手本の) 第一次近似だと思って,欠点に目を瞑れば,色々役に立つことが多いと思います. 寺田寅彦の随筆では先の文章の前に次のようなことが書いてあります.
「
そしてやっていくうちに 何とかなると思っていた問題が実はとても難しい問題で最初のセールストークから ずいぶん後退したり,あるいは結局,使い物にならなかったり.
予算を取るときは,あまり欠点を大きく言うことは得策ではないし,プレゼン相手を 混乱させてしまうので大っぴらには言えませんが,トーンの大小や言い方を工夫して,やはり,こういう, 出来ないことや欠点も一応分析して述べておかないといけませんね.
今回は理論を適用する提案者側とそれに反対する世人の両方に配慮したバランスの とれた,我ながら良いお話になったのではないかと思います.
でも,他人の提案に枝葉を並べたくなる心理は,人間の根源に係わる 何か(生存競争に係わる)かもしれないので,今度,枝葉を言いたくなった時には自分の心の中に 潜ってみたいと思います.自分たちが生き物だと言うことを忘れて,理想を語ることはできませんので.
ソフトウェアの分野で「形式手法」という研究テーマがあります.ソフトウェアの 信頼性を向上するために,仕様を述語論理や様相論理などで「形式的」に記述して, 実装がその仕様を満たすことを,証明やモデル検査などで確かめる(検証する)という研究テーマです. 検証まではやらなくても,とにかく「形式的」に仕様を書いてみるという ようなことも含むと思います.ここで「形式的に」というのは述語論理など形式的体系を 使って厳密に記述することを意味します.私の知り合いにも,形式手法に真剣に取り組んでいる 人がいます.
ここでは,証明やモデル検査などの難しい話ではなく,
ということを考えてみたいと思います.もっと言うなら,仕様と実装の間の理論的な線引きはとても難しいということを 言うつもりです.
一般には,仕様自身はソフトウェアが動くところまで書かなくて良いので,記述において動くための仕掛けを 省略して,そのソフトウェアが満たすべき性質,あるいは他のモノ(ソフトウェア,デバイス,etc.)との関係のみに着目できます.
その意味では,
その具体的な効果として
今回の日記では,
少し話の設定を設けておきます.それは仕様と実装を記述する言語を別のものに してしまうと,話が簡単になりすぎてしまうからです.例えば,C言語で 書くのが実装で,述語論理で書くのが仕様というような基準ができてしまいます. ここはどちらも述語論理にしてしまいましょう.述語論理でも Prolog のように ホーン節だけに限れば,インタープリタを用意して,実装が書けます.つまり, フルの述語論理を使うと性質の記述だけになってしまうが,その中のある部分集合に 限ると実行できるという記述体系の中で考えることにします.
この枠組みでも実行できないものを実装とは呼べないでしょうから, たまたまホーン節で書けて実行できるようになってしまったものを実装と呼ぶべきか仕様と呼ぶべきかが問題になります.
話を少し具体的にしていきましょう.配列のソートを考えてみます. 配列の要素は大小関係のあるキーを持っていて,入力の配列のキーは すべて異なっているとします.そうすると仕様は次のようなものになるで しょう(読みやすさのために厳密な文法は決めずに書いています).
b = sort(a) → b は a の要素の並び替え and
(0 ≤ i < j ≤ size(b) → b[i] < b[j])
つまり,
ということです.配列 a をソートした結果の配列 b は a の並び替えであって,要素の小さいものから大きなものへの順序で並んでいる
この記述は,ソートするとき,どのような手順で要素を並び替えるかという情報を 含んでおらず,ソートされた結果に要求される必要なことだけを含んでおり,大変分かりやすく 感じます.具体的にどうやって並び替えるかは実装者に任せられ,バブルソートでも クィックソートでもマージソートでも適切に選んで実装すればよいのです.
この例を見る限りは,仕様は非常に分かりやすくソフトウェアの記述や検証にも有用に思えます. しかし,ほんの少し条件を複雑にすると状況はがらりと変わります.
上のソートの例で次の二つの条件を付け加えてみましょう.
これは,システムの刷新に伴ういくつかの一時的な不便は我慢すると言う,責任者の英断がないと 何時までも古いままになってしまうのですが,過渡期にはあり得る話です.
このような条件にすると,ソートの仕様としては,上のようなすっきりした仕様でなく,元のソフトウェアの ある種の クィックソートの並びを規定したソートの仕様を書かなければならなくなってしまいます. クィックソートは,適当に選んだ要素を基準にして,それより大きな要素のリストとそれ以下の 要素のリストに分けるということを繰り返していくソートですから,同じ順序(同じキー)のデータ同士の 相対位置は動的に変わってしまいます.これを最初の配列の性質から静的に論理式で記述するのは とても難しく,元のソートのアルゴリズムをそのまま論理式(ホーン節)で記述するしか 無いように思います.以上,例題がちょっと長かったですが,これは
でした.仕様として,アルゴリズムを記述し,しかも動くレベルまで 記述しなければならない例で,仕様が実装より簡単にすっきりと書けるとは 限らないことを示す例
もう一つ,簡単な例として,例えば,信号機の色の変わる順番を規定する仕様を考えてみます. 信号機の色が,青 → 黄 → 赤 → 青 と変わるという仕様は,
となるでしょう.実はこれは動いてしまいます.したがって,前の例もそうですが, 動く動かないを実装と仕様の差にすることはできません.next(青, 黄)
next(黄, 赤)
next(赤, 青)
以上をまとめると次のようになります.
以上,仕様と実装の違いを改めて考え直してみると言うお話でした.仕様というのは ソフトウェアを作る人が,作るべきものを必要十分に記述したもので,実装はそれを満たす 実際に動くものということなのでしょう.そして,仕様が実装より分かりやすく書けることが多いというのは 仕様を作る人たちの努力と勇気によってそうなっている部分も大きく,仕様だから,実装だから だけの理由では無いと思います.
こういう,概念の区別に人間の判断基準や感性が絡むものは,理論的かつ厳密な定義が難しいのですが,やはり, 定義しようという努力はそれらに対する理解を深めることに繋がり,大切なことだと思います. こういった事例は沢山あると思います.例えば,
話を元に戻して,ソフトウェアの分野で形式手法を活用していくためには
最後に,仕様が必ずしも実装より簡単にならない場合があるということは,圏論で つくるモデルが必ずしも理解容易なものにならないことと関係があるような気が 最近してきました.実際,
では,著者は圏論での記述を specification と呼んでいることがあります. これについては,また,圏論の考察をするとき書いてみたいと思います.
他の日記へのリンク - このページ → メモのような日記のような(3) 2019.11.16-
- メモのような日記のような(2) 2018.11.24-2019.10.30 へ
- メモのような日記のような(1) 2017.10.17-2018.11.04 へ
圏論を勉強しよう