"Python によるデータ分析入門" Wes McKinney 著

この酔いどれ天の邪鬼は、Ruby 信奉者である。いや、だった。それも仕事場ではなかなか受け入れてくれない。Ruby はもう死んだのか？やら、Rubyはまだ死んでいない！やらといった記事も見かけるけど...
近年、大人気と評判の Python なら受け入れられるようになったので使うようになったが、あくまでもスクリプト言語としての位置付けであって、まだまだ、Ruby の思考回路から抜けられないでいる。
しかしながら、Python 関連の書籍を漁っているうちに、こいつの本当の魅力は C 言語系との相性の良さではあるまいか、と感じ始めた。Cython プロジェクトなるものも耳にすれば、Visual Studio にも Python ツールを見かけるし...

実際、数値計算ライブラリや画像処理ライブラリには、C言語系の API が溢れている。OpenCV しかり、Dlib しかり、むかーしから愛用してきた LibTIFF しかり... 処理性能を求めれば、低水準言語で扱う場面が増え、ここにスクリプト言語との壁が生じる。その壁も随分と低くなってきてはいるが...
おいらの昔からの考えに、言語依存を避けるため、データの受け渡しにはテキスト形式で I/F するというのがある。テキスト形式であれば、エディタで直接編集できるし、痒いところにも手が届く。
そして、データ解析モデルや演算モデルに GNU Octave(数値演算言語)や Lisp、あるいは C++ を、これらの可視化ツールに gnuplot を、プロセッサや DSP の設計・検証に HDL(ハードウェア記述言語)を、そして、統合環境にスクリプト言語を用いるのが定番となっている。
ただ、受け渡しのための中間ファイルが巨大化する傾向があり、ずっと悩まされてきた。その都度圧縮したりと。ハードディスクも SSD に置き換わって高速化し、搭載メモリも大容量化してきたので、それほど目障ではなくなってきたものの、開発環境を一つの言語システムで完結できれば、それに越したことはない。こんなことは、三十年来、思い描いてきたことではあるけれど、人類の編みだす言語システムに完全で万能なものなんてありえないであろうし、用途によって、場面によって... 適した言語を、気に入った言語を... その都度選択するしかあるまい、というのが現実解だと考えている。否、儚い夢だからこそ追いかけていたい。
ここでは、そんな心を見透かすかのように、Python 上の統合環境を提案してくれる。やはり、蛇の道は蛇か...

本書は、科学計算パッケージ NumPy(Numerical Python)とデータ解析用ライブラリ pandas を話題の中心に据え、NumPy を基盤にした科学計算ライブラリ SciPy や、これらを可視化する描画ライブラリ matplotlib、さらには、これらを統合するシェル環境 IPython を紹介してくれる。

NumPy で注目したいのは、多次元配列オブジェクト ndarray である。モノは二次元配列だが、インデックスによる階層構造によって、見かけの次元を増やすことができる。配列上の操作関数も豊富で、線形代数演算、フーリエ変換、乱数の生成なども提供される。

pandas は、NumPy の高性能の配列計算機能と、表計算ソフトやリレーショナルデータベースの柔軟なデータ操作能力を併せ持つという。SQL との相性の良さも強調される。
当初は、金融分析用に設計されたツールだそうで、洗練されたインデックス付け機能を備え、データの再形成やスライス、ダイシング、集約、部分集合の選択が容易だという。
主要なオブジェクトは、二次元の表形式で、列指向のデータ構造をもつ DataFrame ってやつ。統計解析で知られる R 言語の data.frame オブジェクトに似たものらしいが、機能性は上回ると宣伝している。おいらは R 言語を見かける程度しか触れたことはないが、おかげで、R にも興味を持つ今日このごろであった。
データの受け渡しでは、JOSN や CSV のようなテキスト形式だけでなく、HTML や Web API を用いた読み書き、HDF5 形式を扱う HDFStore クラス、SQL データベースへの Import/Export の事例も紹介される。おいらが忌み嫌う ExcelFile クラスまでも..

SciPy は、これらのパッケージ群を眺めるだけでそそられる。

• scipy.integrate: 数値積分ルーチンや微分方程式ソルバ
• scipy.linalg: 線形代数ルーチンや、numpy.linalg で提供される機能を拡張した行列の分解機能
• scipy.optimize: 線形計画法などの最適化アルゴリズムや、求根アルゴリズム
• scipy.signal: 信号処理ツール
• scipy.sparse: 疎(スペース)なデータを持つ行列や線形システムの解法
• scipy.special: ガンマ関数のような一般的な数学の関数を実装した Fortran のライブラリ SPECFUN を使うためのラッパー
• scipy.stats: 標準的な連続分布や離散分布(密度関数、サンプラー、連続分布関数)、様々な統計検定、その他の記述統計
• scipy.weave: 配列計算の加速のために用いるインラインでの C++ コードを利用するためのツール

matplotlib は説明の必要がないほど、おいらの感覚に馴染めそう。ここでは、IPython との統合性が推奨される。
ちなみに、R の ggplot2 や trellis といったパッケージには見劣りするらしい。ますます、R に...

IPython は、いまや科学分野における Python のスタンダードになっているそうな。
ちなみに、著者のウェス・マッキニー氏は、pandas の開発者だけあって、ベストな開発環境を尋ねられたら、即「IPython + テキストエディタ」と答えるそうな...

"DEBUG HACKS" 吉岡弘隆/大和一洋/大岩尚宏/安部東洋/吉田俊輔 著

コンピュータ業界の格言に「プログラムは思った通りではなく、書いた通りに動く。」というのがある。そして、「思った通り = 書いた通り」を定式化するのは自分自身！何事も思い通りになった時の快感ときたら... これが忘れられなくて、今日もプログラムを書く。まるで麻薬！プログラムを書くのは楽しい。おいらはプログラマではない。でも楽しい...

デバッグの基本姿勢に、状態を見る！ということがある。まずは観ること！これは科学的思考の基本中の基本だ。しかしながら、自分自身を客観的に見ることほど辛いものはない。自分で仕掛けておきながら、自ら姑チェック！なんとも自虐的な世界。
そこには、自己矛盾が多分に含まれる。自分は天才かもしれない！って思うこともある。年に一度や二度は。一方で、つまらないミスで時間を浪費する自分に向かって、バカヤロー！って叫ぶのはほぼ毎日ときた。それでも、真に思い通りになった時の征服感ときたら... 出来の悪い子ほど可愛いと言うが、苦労に苦労を重ねて作り上げたコードほど愛着がわく。自己啓発とは、自己陶酔の類いか。そして、再々々々... 認識させられるのである。自分自身がいかにアホウであるかを。踊る阿呆に見る阿呆、同じ阿呆なら踊らにゃ損々... やはりプログラムを書くのは楽しい...

プログラムを書くのは実に愉快。しかしながら、デバッグ作業は辛い。動作が明らかにおかしな時は些細なミスであることが多く、バグも可愛いもの。だが、深刻な問題になりがちなのは微妙に動いている時で、数十時間に一度落ちたり、再現しなかったり、この手のバグの憎らしさときたら。
ちなみに、「バグ」の語源は定かではないが、リレー式計算機の中に紛れ込んだ蛾が誤動作の原因になった事例があるそうな。その蛾は、後に COBOL の開発者となるグレース・ポッパー女史の日記に記念として貼り付けられたと聞く。そういえば、むかーし、おいらが所属していた研究所にネズミホイホイが置いてあった。社内伝説によると、ネズミが電線をかじってシステムダウンし、大騒ぎになった事例があったとか...
バグってやつは、思わぬところに潜んでやがる、実に多種多様な生物。実際、設計作業より検証作業の方がコストは高い。テスト駆動開発(TDD)という考え方もよく耳にするが、そんな小難しい用語は別にして、上流工程からテスト方法を具体的に考慮することが習慣になっている。それだけ痛い目に遭ってきたということか。プログラムの書き方はコーディングルールで規定することができても、バグの在り方を規定することはできない。こいつに対処する最善の方法は、自分で編みだすしかあるまい。常に改善の意識を怠らず...
「デバッグという作業はプログラマが 10 人いれば 10 通りのデバッグ方法があるかのような極めて属人的な作業です。そして、デバッグの達人もいれば、そうでない人もいる。軽やかに、それこそ鼻歌まじりに魔法のようにバグを見つけ出し、直すハッカーもいます。」

本書は、主に C/C++ の使い手や Linux カーネル開発者を対象とし、Linux 上で動くアプリケーションや、Linux カーネルそのものを話題にしている。おいらがカーネルを書くことはないだろう、おそらくこれからも... ただ覗くのは大好き。低水準のデバッグでは、x86/x64 アーキテクチャやアセンブラ言語の基礎知識も要請してくる。お馴染みの GDB も登場。おいらはハードウェア設計者だが、低水準のデバッグは必要不可欠なので、うってつけの教材かもしれない。
多くのツールを紹介してくれるのもありがたい。達人ともなると、使う道具からして違うようだ。気の利いたところでは、システムコールをトレースする strace、動的解析ツール Valgrind、カーネル情報を取得する kprobes/jprobes など。
興味深いところでは、Linux 環境では定番の oprofile によるプログラムの性能調査。あるいは、KAHO(Kernel Aided Hexadecimal code Operator)というやつを使って、コンパイラによって Optimaized out された変数の値を取得する事例が紹介される。要するに、関数単位で動的に置き換えることができるもので、デバッグ用関数を埋め込む仕掛けを伝授してくれる。最初から関数にデバッグモードを埋め込むというやり方もあるが、リアルタイムシステムでは悩ましいところ。
また、Linux には、システムのメモリ・スワップを使い尽くすと、メモリを確保する最終手段として、プロセスにシグナルを送信し、強制終了させる機能が装備されている。OOM Killer(Out of Memory Killer)が、それだ。これに関する proc ファイルシステムを解説してくれるが、"/proc/meminfo" や "/proc//mem" を覗くだけでも、かなりの情報が得られるだろう。もちろん、Linux カーネルのオプションとして提供されるフォルトインジェクションも見逃せない。

ちなみに、おいらは、プログラミング言語を学ぶならアセンブラ言語から始めるのがいいと考えるネアンデルタール人だが、そんな時代でもあるまい。スクリプト言語が活況な今日では、C言語系をいじるのも億劫だが、関数とマクロの物理構造がイメージできるかどうかは大きな違いがある。
コアダンプの景色も直接関わらなければ、なかなかの眺め！痕跡をセピア色に彩り、デスクトップの背景に貼り付けるのも一献。
今となっては、malloc() の呪いも妙に懐かしい。
Linux も随分と行儀よくなったもので、あの忌まわしいメッセージもとんと見かけなくなった。そこで、わざと発生させてみるのも一献... Kernel Panic !
昨今、プログラミング言語そのものが注目されがちだが、本書は、言語とデバッグを表裏一体の方法論として捉えているのがいい。デバッグという分野は、なかなかハウツー本にはできない。ブレークポイントの設定、ステップ実行、バックトレース、はたまたスタックやレジスタの表示、変数の監視など、やる事は定式化できても、いかに効率的にやるかとなると経験がモノを言う。達人ともなれば、それだけ失敗の経験も豊富のようだ。その意味で、本書は失敗から学ぶ良い事例集と言えよう。失敗の効率化という日頃の意識が、デバッグの達人を育てるらしい...

"リバースエンジニアリング" Justin Seitz 著

プログラムを書くのは楽しい。プログラマ35歳定年説が囁かれる中、いくつになっても楽しい。おいらはプログラマではない。でも楽しい...
二十年以上前、組込系 OS を五年間ほど書いていた時期もあるにはあるが、あくまでもハードウェア設計者。当時、リアルタイム処理ではアセンブラ言語が主流だった。C コンパイラの性能がいまいちで、移行にはまだまだ感の残る時代である。とはいえ、CPU の方言を強要される日常を思えば、抽象度の高い高水準言語は憧れであり、コンパイラの癖を探りながら効率的な記述の仕方を試行錯誤したものである。
ちなみに、今では超ロングセラーとなった定番書も、「はじめての C」がいいのよ！... なんて理系女子にささやかれると、純真な好青年で通っていたおいらは赤面したのだった。
その高水準の地位も、コンパイル作業不要のスクリプト言語にもっていかれ、いまや低水準に格下げ。だからといって死滅することはあるまい。プロセッサや DSP の設計者にとって、痒い所に手が届く言語はありがたい存在。それに、人間が編み出した言語システムが、完全で万能ってことはないだろう。用途に適した言語を、好きな言語を、興味のある言語を、場面々々で選べばいいだけのこと。一つの言語に固執するということは、一つの文化に幽閉されているようなものだから...

ところで、システムの開発・設計には、デバッグ環境が欠かせない。おいらの感覚では、プロセッサや DSP の設計・検証に HDL(ハードウェア記述言語)を、数値演算モデルやデータ解析モデルに GNU Octave や Lisp、あるいは C++ を、これらの統合環境にスクリプト言語を用いるのが、一つのパターンとなっている。
そして、スクリプト言語に何を使うかが、いつも悩ましいところで、一昔前は、コマンド系に Unix シェルを、ログ管理に Perl を用いるのが定番であった。未だに、sed や awk を重宝してたりして。
ちなみに、おいらは、Ruby 信奉者だが、いや、だったのだが、仕事場ではなかなか受け入れてくれない。Ruby はもう死んだのか？といった記事も見かけるけど...
近年、Python なら受け入れられるようになったので、納品物に Python を、小物に Ruby をというのがパターン化している。できれば、C++ も避けたいところだけど...
尚、データ群を Excel ファイルで！と要求してくる人種は避けている。CSV や JSON のような形式ではダメらしい。ドキュメントを XML で！という要求もちょくちょく見かけるが、こういうのは頷ける。pdf じゃダメというところも見かけるけど。
いずれにせよ、SM 教の高価なツールを買わせようとするのは、零細業者には御勘弁を！おっと！この手の愚痴がはじまると、かっぱえびせん状態に...

さて、本書の副題に、「Python によるバイナリ解析技法」とある。実は、この題目に惹かれて手にとった。まさにデバッグの視点からスクリプト言語を語ってくれるのだから...
特殊な逆アセンブラを構築するにせよ、独自のデバッガを開発するにせよ、Python が最善の選択肢になるというのである。Python と言えば、大人気と評判のスクリプト言語。スクリプト言語がバイナリ領域にまで入り込んできたら、赤面する機会も失いそうで、ちと寂しい。おいらは、プロセッサの設計者なら、アセンブラレベルから学ぶべきだと考えるネアンデルタール人だが、そんな時代でもなさそうだ。
それにしても、Python の構文って、バージョンが 2.x と3.x で、なんでこうも違うの。おいらは、3.x から始めたので、ほとんど問題にならないが、本書は 2.5 で書かれており、いきなり Print "Hello world!" でこけた。システムを構築する上で、過去のしがらみをどこまで引きずるかは悩ましい。SM 教のような引きずり方をするぐらいなら、あっさり捨てる方がましかも。ということで、Python は最新版を使いましょう...

ここでは、まず、Python と C 言語の構造体や共用体との相性の良さを紹介しながら、ヒープ領域やスタック、あるいはレジスタへのアクセス事例を挙げている。
注目したいのは、二つのデバッガを紹介してくれることだ。デバッグのために実動作と違ったルーチンを通るのは、なるべく避けたい。特にリアルタイムシステムでは。となれば、ハードウェアが介在する領域でプログラムを書く必要がある。デバッグでお馴染みの作業といえば、レジスタやメモリの捕捉、スレッドの列挙、デバッグ用イベントハンドラの実装、ブレークポイントの設置といったところであろうか。そんな要求にも応えてくれそうな。
一つは、PyDbg というピュアなデバッガ。プアなおいらは、これだけでも満腹！こいつには、「プロセススナップショット」というクールな機能が搭載されるという。
二つは、Immunity Debugger というなかなか手強いヤツ。脆弱性の検出やマルウェア解析にも利用できる強力な Python ライブラリを提供しているという。エクスプロイトなコードも書けそうな。
おいらの場合、ソースの存在しないレベルでデバッグする場面はほとんどないが、ソースを見なければ書き手の思惑にも惑わされず、純粋な視点で検証できるかもしれない、と、そんなことも感じさせてくれる。痒いところに手が届くという意味では、スクリプト言語がここまでやれる時代になったのかと忸怩たる思い...

本書は、Windows プログラムを題材にしているところが、ちと抵抗のあるところ。おいらが、Windows プログラムを書くことはほとんどないが、それでも、なかなか興味深い話題を提供してくれる。Win 95 時代に猛勉強した記憶がかすかにあるが、まさかこんなところで Windows プログラムに触れることになろうとは。人生行き当たりばったり... やはり、プログラムを書くのは楽しい...
例えば、 DEP(Data Execution Prevention) を回避する事例に、ちとハマってしまった。DEP は、ヒープやスタックなどメモリ領域でのコードの実行を防止するための Windows に実装されるセキュリティ機能。他にも、善意にも悪意にも利用される DLL インジェクションに、油断のならないコードインジェクション。これらの技法を使えば、実行中のプロセスにコードを挿入することができ、その先にトロイの木馬が見えてくる。
また、プロセスを監視するためのフックを仕掛ける方法も紹介してくれる。そして、この二つの関数の構造体にアクセスするだけでも結構遊べる。
一つは、プロセスを生成するための関数 CreateProcessA()。この関数のフラグをうまく設定することによってデバッグ用プロセスモニタに仕立てるというわけである。

BOOL WINAPI CreateProcessA(
  LPCTSTR lpApplicationName,
  LPTSTR lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL bInheritHandles,
  DWORD dwCreationFlags,
  LPVOID lpEnvironment,
  LPCTSTR lpCurrentDirectory,
  LPSTARTUPINFO lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

二つは、Kernel32.dll からエクスポートされる関数 CreateRemoteThread()。スレッドのセキュリティ属性へのポインタにアクセスできそうな仕組みが見て取れる。

HANDLE WINAPI CreateRemoteThread(
  HANDLE hProcess,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  SIZE_T dwStackSize,
  LPTHREAD_START_ROUTINE lpStartAddress,
  LPVOID lpParameter,
  DWORD dwCreationFlags,
  LPDWORD lpThreadId
);

"科學の言葉 = 數" Tobias Dantzig 著

小雨降りしきる中、しとしとぴっちゃん気分で古本屋を散歩していると、なにやらノスタルジックな奴に出会った。琥珀色に染まった紙面が風格を漂わせ、そればかりか、書き込みがあちこちにあって元持ち主の情熱までも伝わってきそうな...
初版、昭和二十年(1945年)... 改訂第二版、昭和三十二年(1957年)... とある。おいらは、まだ生を受けていない。ただ、暗示にはかかりやすい。むかーし教科書を赤線だらけにし、何が重要なのか分からないほどにしちまった記憶がかすかに蘇る...

本書は、「数える」という行為をめぐっての物語である。扉を開けると、「数学者でない教養ある人々のための批判的概観」と見出しされる。著者トビアス・ダンツィクは、学校の数学過程が文化的な内容を削って、技術の骨格ばかりを追いかけているために、多くの優秀な人材を遠ざけてしまった、と考えているようだ。そこで、数の進化を文化的に、いや、人間的に物語ろうというのである。
「数」という概念と「数える」という行為は、ともに抽象化の道を歩んできた。数える行為を合理化するために記号を発明すれば、記号の関係性を求めて関数を編み出す。やがて、同じ性質を持つ数の集まりをひと括りにし、性質そのものの関係を探るようになる。「数」という概念は記号で抽象化され、「数える」という行為は関係性を結びつけることに抽象化されてきたのである。
さらに、無限までも数えてやろう！という願望に及ぶと、数の大小という関係は、濃度という概念へ飛躍する。「数える」というからには整数論の領域にあるわけだが、まったく数に見えないのに整数とはこれいかに？有限界の知的生命体が無限界に口を出そうとすると、まったく悪魔じみてやがる。とはいえ、すべては「一対一の対応」という手続きの元で引き出された知識であったとさ...
尚、河野伊三郎訳版(岩波書店)を手に取る。

数の学問は、数を数えることに発する。原始の時代、人類は指を折って数え始め、数の概念はまずもって両手合わせて十本の指に乗っ取られた。人間社会が十進法に席巻されるのも、その名残りか。女性が妊って十ヶ月で出産するのは、単なる偶然かどうかは知らんよ。ある原始民族では、手足合わせて二十進法を用いたという説もあるらしい。
「数える」という意識は、人間の本能に植え付けらたもののようにも感じられる。精神病患者や知的障害者は、心が落ち着かない時に数を数え始めると聞く。ある種の儀式のように。サヴァン症候群のような突飛な能力の持ち主ともなると、数字が風景に見えるらしい。おいらも、デスクトップ上のスキャンカウンタをなんとなく見入ったりする。数には、なにやら心を落ち着かせるものがある。数えるという行為は、人間の進化論とも関係がありそうな...
ちなみに、おいらが美少年と呼ばれた小学校低学年の時代、さんすうが大の苦手であった。放課後、一人残されては計算をやらされる。数ってやつがまったくイメージできず、机の下に手を隠して指を折りながら数える。すると叱られるのだ。堂々とやれ！って。ごもっとも！当時の女の先生が鬼にも、天使にも見えたものである。やがて数の概念が理解空間と結びつきはじめると、いつの間にか、数の虜に。鶴亀算があまりにもすんなり数える概念と結びついて、こいつが方程式ってやつだと理解するのに大して手間はかからなかった。しかしながら、大学の初等教育で再び奈落の底へ突き落とされ、高校までの数学がいかに算数であったかを思い知らされる。抽象化の概念は、指では数えられんよ。数学の落ちこぼれは、こうして今に至るのだった...

しかし、だ。数の学問において、十進法ほど厄介な道具もあるまい。コンピュータは二進法とすこぶる相性がよく、計算機工学やソフトウェア工学などで、8進法や16進法が用いられる。つまり、2の冪乗数があらゆる計算において優れているということだ。ラプラスは、こんなことをつぶやいたとか...
「ライプニッツは二進法の算術に『創造』」の形象を見た... 『一』は神を表し、『零』は空を表す...」
なのに、人類が十本の関節を持つ指を授かったがために、十の数が崇められる。こんな自然法則に反するものを、誰が授けたかは知らんが... ただ人類はどんなことでも、いかようにも解釈できる性癖も授かった。その見返りかは知らんが、幸福の原理として...
ピュタゴラス学派は、当時の四元素「火、水、空気、土」を底辺にした三角数 (4 + 3 + 2 + 1 = 10) をテトラクテュスと呼んで崇めた。三角形の頂点には、神に通ずるものがあるらしい。ただ、数学者が概念でねじ伏せようとも、計算ではレジのおばさんの方が位取りで一枚上手ときた。
ちなみに、鏡の向こうから「十の時が流れる」という名を持つ野郎が、顔を赤らめてこちらを見つめてやがる。どうやら数に酔ったらしい。あヤツはテトラクテュスの申し子か？ダンツィクの言う「人間は万物の尺度である。」という言葉が、嫌みに聞こえてくる...

1. 心を乱す無理数 vs. 心を癒やす超越数
計算において、なにかと面倒なヤツがいる。無理数ってやつが、それだ。しかも、幾何学で最も純粋とされる図形に出現しやがる。正方形の対角線と、直径を 1 とする真円周の長さに...
有理数があれば、どんな微細な数でも記述できそうなものである。分母の桁をどんどん増やしてやればいいのだから。数直線上の連続性を保つために無理数の存在が欠かせないとは、これいかに？おかげで、数学は分裂症を患わずに済むのだけど、ヤツの存在を隠蔽しようとしたピュタゴラス教団の考えも分からなくはない。
無理数の存在が面倒であるように、有理数が無限と絡むとやはり面倒となる。コンピュータだって万能じゃない。実際、実数演算は近似法で誤魔化されている。もし浮動小数点演算で答えが合わないと騒ぐ新人君を見かければ、IEEE754 の意義を匂わせてやればいい。2の冪乗数は偶数であり、奇数は奇っ怪な存在なのかは知らん。素数は、奇っ怪な存在か純粋な存在かも知らんが、暗号システムを根底から支え、ネット社会では絶対に欠かせない存在である。有理数と無理数の絡みでは、オイラーの等式にゾクゾク感を喰らう。超越数の代表格とされる自然対数の底と円周率が虚数を介して絡むと、整数になるというのだから...

  e^iπ = -1

自然美の対を心底感じさせるものといえば、なんといっても二本の脚線美。これに、おっ！πが絡むと、空虚な精神を平穏に整えてくれるのは確かだ。超越数ってやつは、そこに法則性を見い出したとしても、人間が編み出した概念なんぞでは説明の及ばない、もっと形而の上にある存在のように見えてくる。だから、超越した数なのである。

「神霊は、我々が負の単位 -1 の想像的平方根と呼ぶ解析のあの驚異のうちに、あの理想世界の前兆のうちに、存在と非存在との間のあの両棲類のうちに、その崇高なるはけ口を見出した。」
... ゴットフリート・ライプニッツ

2. 演繹法 vs. 帰納法
あらゆる体系を抽象化する思考アプローチに、二つの極性がある。演繹法と帰納法が、それだ。演繹法は、基本となる大前提から小前提に向かって法則性を導いていくアプローチで、三段論法がその代表。帰納法は、多くの事象から共通点を見出して法則性を導いていくアプローチ。数学の王道は、おそらく演繹法であろう。演繹法による帰結は反証の余地を与えないが、帰納法は一つの反証によって崩れる脆さがある。普遍的な言明と事例的な言明とでは、前者の方が圧倒的に説得力がある。そりゃ、現象をすべて演繹できるならそれに越したことはないが、現実世界は帰納法に頼らないと説明できない領域があまりに大きい。相対的な認識能力しか持ち合わせない知的生命体にとって、王道だけでは心許ない。
ダンツィクは、「数学は演繹的科学」としながらも、帰納法を「出直しによる推理」と位置づける。出直し... 大いに結構ではないか。あらゆる常識も一度は疑ってみて、再検証してみるのがええ。演繹的と表現するからには、完全演繹とはなるまい。四色問題やケプラー予想で用いられた戦略は、まさに帰納法的な思考であった。カオスの世界では、最も客観性を重んじる数学ですら確率的な厳密さを受け入れざるを得まい。
そして、厳密に対する準厳密、定理に対する準定理... といった位置付けも必要となろう。客観性を最高レベルで用いようとする数学であっても、やはり主観性からは逃れられそうにない。人間が思考するということは、そういうことだ。ガリレオの逆理をついたカントールは、論理の王国を直観の王国へ引き戻した。無限と戯れる才能豊かな連中にとって、厳密な世界は息が詰まると見える。王道は肩がこる。おいらは邪道を行きたい。王道とは、邪道があってこその王道なのだから...

「数学の本質はその自由にある。」... ゲオルク・カントール

ジョークの言える日に、真面目にファルス論でも...

「嘘というものがなければ、人間は絶望と退屈で死んでしまうであろう。」... アナトール・フランス

今日、四月一日は、堂々とジョークの言える日。巷では、そういうことになっている。
しかしながら、エイプリルフール禁止令をあちこちで見かける昨今。フェイクの拡散が日常茶飯事となれば、あえて、そんな日をつくる必要もないか。毎日がエイプリルフールなら、まったくおめでたい世の中。冗談の言える日ぐらい、真面目に語ろう！いや、エイプリルフール禁止令そのものがジョークということもある。
現代語辞典では、ジョークの定義も随分と変容したようだ。真面目に語って笑えるなら、それこそ真のジョークなのやもしれん...

「笑いとは、地球上で一番苦しんでいる動物が発明したものである。」... ニーチェ

世間では、笑いよりも涙の方が高尚とされる。だが、人間の情念は涙を誘うよりも笑いを誘う方がはるかに難しい。悲しみには人類の共通観念があり、死や命の儚さを匂わせればたいてい涙を誘う。
一方、笑いほど文化や慣習に影響されるものはない。笑いは否定をも肯定する。おまけに、涙をも乗り越える。故に、戯作をもって笑劇を演じることが、高尚な生き方ということになろうか。今日では、苦悩を笑い飛ばす能力が問われる。人間の滑稽を見て、これを笑い飛ばせるかどうか。これこそ真の道徳論なのやもしれん。少なくとも、理性をストレス解消のために用い、いつも憤慨する道徳論者よりはましか...

「人が死んでも、人生は依然として可笑しく、人が笑っても、人生は依然として深刻である。」... バーナード・ショー

笑いの世界にも、大衆の目には晒してはならない領域がある。大衆は臭い。どんなに良いことでも、同じことをする人が多すぎると、なにかと問題になるのが人間社会。どんなに良い人でも、集まりすぎると集団的悪魔に変貌する。俗人どもが、こぞって自己肯定に奔走しているのに対し、芸術家どもは自己を侮辱することによって自我の魔術性を露わにする。この自殺行為によって、芸術は芸術たりうる。芸術精神は自己の滑稽に発し、自己の風刺によって自らの悪魔性を炙り出す。自己否定に陥ってもなお愉快でいられるなら、真理の力は偉大となろう...

「ファルスとは、人間の全てを、全的に、一つ残さず肯定しようとするものである。凡そ人間の現実に関する限りは、空想であれ、夢であれ、死であれ、怒りであれ、矛盾であれ、トンチンカンであれ、ムニャムニャであれ、何から何まで肯定しようとするものである。」... 坂口安吾

パスカルが言ったように、人間は狂うものらしい。狂わなければ、まともな笑いにもありつけない。人の一生とは、狂言のようなもの。猿の仮面をかぶれば猿に、武士の仮面をかぶれば武士に、エリートの仮面をかぶればエリートに、サラリーマンの仮面をかぶればサラリーマンになりきる。あとは、幸運であれば素直に波に乗り、不運であれば生きる糧とし、いかに達者を演じきるか。人間なんてものは、物狂いを演じながら生きるぐらいの存在か。自己を見つめているだけで自然に笑みがこぼれる... そんな人生はいずこに...

「人生は近くで見れば悲劇だが、遠目に見れば喜劇である。」... チャールズ・チャップリン