確率変数（random variable, stochastic variable）という言葉の意味が分からない！ と何度か書いています。 2015-05-26 「確率変数」と言うのはやめよう 2015-05-27 「分布、測度、密度」は同じか違うか 2015-06-17 まだ「確率変数」が分からない 結局分からないままでした。「慣れ」の問題かも？ と思ったこともあります。 2015-05-28 「慣れれば分かる」問題 慣れることも出来ませんでした。 最近、「これなら納得できるかな」という解釈に出会いました。 [追記 date="翌日"]最後に分かりやすいマトメを付けました。[/追記] 内容： 「確率変数」はなぜ分からないのか アレックス・シンプソンのアイディア 「確率変数」の2つの用法 確率空間と圏Prob 測度論的確率変数 曖昧な確率変数 前層と米田埋め込み 米田埋め込みとしての確率変

『シン・ゴジラ』は僕のツボにはまったんですよね。コワ面白かった！ 最近、もうひとつ「これは面白い！」と思っていることがあります。微分幾何の応用の話です。多くの人が「応用」という言葉から連想する内容とはちょっと違います。微分幾何を換骨奪胎して、その枠組を、微分とも幾何ともまったく無関係と思える分野にも適用するのです。 「微分とも幾何ともまったく無関係と思える分野」には、コンピュータ科学や組み合わせ論が含まれます。これには驚きました。好奇心を刺激されて、しばらく猿になって調べまくってました。 調べても理解できないことがたくさんあるので、断片的で中途半端な知識を推測（妄想？）でつなぎ合わせるという手法（いつものやり口）で語ってみます。圏と多様体の定義くらいは仮定しますが、それ以外の知識は要求しないオハナシ調です。 内容： リソース計算が微分計算だってぇぇ?! 微分の計算が出来る圏 組み合せ論とデ

「JavaScriptには、クラスとその継承はないが、プロトタイプベースの継承をサポートしている」と、まー、これはよく言われる決まり文句です。がしかし、JavaScriptにおけるアレを継承と呼んでいいものかどうか？ 「継承」といえば、多くの人が通常の継承、つまりクラスベースの継承をイメージするでしょうし、無意識に通常の継承とのアナロジーを追うことになるでしょう。これは危険だと思いますよ。 「プロトタイプ」とか「継承」という言葉から連想する常識的なイメージは全部捨てて、事実を白紙から眺めましょう。その事実とは、「JavaScriptには、実行時プロパティ検索のメカニズムがある」と、それだけです。 今回の内容： 「プロトタイプ」じゃ、なんのことだかわからない __proto__プロパティ、__proto__オブジェクト、__proto__チェーン __proto__チェーンを追いかけてみる

2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん

[追記 dateTime="2007-12-07 夕刻"]あーっ、今ごろ気付いた。イライライって「イ」がひとつ多いや。タイトルを編集すると、なんか悪いことが起こったりしませんかね？ うーん、いいや。typoしたままにしとこう。ちなみに、「イライライ」は回文になっているぞ。[/追記][追記 date = "2007-12-11"]http://d.hatena.ne.jp/keyword/%a5%a4%a5%e9%a5%a4%a5%e9%a5%a4 [/追記] いつか文句言ってやろうと思っていた件ですよ。長いぞ。 内容： 似てるけど少しずつ違うイベントモデル達 イベントターゲット イベントフロー EventTargetインターフェース イベントハンドラーとイベントリスナー リスナーとハンドラーについてもう少し イベント伝搬とハンドラー実行 イベントの通過または出現 イベントタイプ 「イベント

「久しぶりに圏論勉強会」で触れた次のこと： 非対称なモノイド圏という概念 モナドの定義をモノイドとして再確認 これを、お絵描き計算（pictorial calculation）を使ってチャント（になるかな？）説明してみようか、と思いました。こういうことは一気にババッと書き切らないと、ヘタって後が続かないことが多いのですが、残念、本日は厳密モノイド圏の実例で息切れ。でもまー、お絵描きの準備はできたから、いいとしよう。 内容： モナドはモノイドだ -- 言ってるだけ 循環的な状況が恐いけど魅力的 準備：ボックス図からストリング図へ 準備：徹底的に左から右の記法 自己関手の圏End(C) 余談：圏論は、ほぼ計算だけ 厳密モノイド圏 実例：行列の圏 実例：非負の実数 実例：釘にラベルが付いたブレイド図の圏 ほんとに面白いのは モナドはモノイドだ -- 言ってるだけ 実は、「モナドはモノイドだ」とい

「代数」という言葉は様々な意味で用いられます。ここでは、余代数とペアにして語られるアレのことです。と言っても何だかよく分からんでしょうから以下で説明します。代数・余代数の定義には圏論を使うのが普通ですが、ここでは圏論なしでいきます。クラス・余クラスは、代数・余代数を裏返しただけで事実上同じものです。 内容： 演算と代数 代数の指標とモデル 余演算と余代数 余代数の隠蔽指標 クラスと余クラス 演算と代数 Aをなんらかの集合だとして、f:A×A→A という関数（写像）をA上の二項演算と呼びます。A = Integer（整数の集合）のとき、足し算や掛け算は二項演算となります。add:Integer×Integer→Integer、mult:Integer×Integer→Integer とかですね。 二項だけでなく、三項や一項の演算もあります。三項演算というと、プログラマの人は、(- ? - :

MongoDBは、よく知られているように、ジョインもトランザクションもサポートしてません。これは確かに不便なこともありますが、欠点・弱点というよりは、最初からそのように設計されているもので、ひとつの設計判断です。パフォーマンス、スケーラビリティ、耐障害性、分散化の容易性などをより重要視した結果でしょう。 MongoDBの特徴を見ると、大規模なデータセットを高速にハンドリングするためにチューンされているように思えます。しかし、それとは違った場面で使える機能性も備えています。それは「ユニオン型を自由に扱える」ということなんですが、地味であまり言及されないし、ちょっと分かりにくいところもあります。でも、この特徴は、僕にとっては嬉しいものです。ちょっと説明してみます。 ジョインとユニオン SQLDBはジョインができます。ジョインとは、“直積”と“等式的条件による絞り込み”の組み合わせです*1。等式

関手データモデルのデイヴィッド・スピヴァックが、圏論の教科書を書いたようです。商業出版ではなくて、Web上にPDFが公開されています。スピヴァックの大学での講義のテキストとして書かれたようです。 Title: Category theory for scientists Author: David I. Spivak Submitted: 27 Feb 2013 URL: http://arxiv.org/abs/1302.6946 This book attempts to show that category theory can be applied throughout the sciences as a framework for modeling observed phenomena and for communicating results. In order to targ

夢のような話も楽しいけど、今日は地道に行きましょう。様々なスキーマ制約を、単純な発想だけを使って、すべて一様に扱う方法を紹介します。 それにしても、「入門 2」なんて番号付けていいんでしょうかね？ 「衝撃的なデータベース理論・関手的データモデル 入門」を「入門 1」とみなすつもりですが、「入門 3」「入門 4」があるかどうか不安。 内容： データたちのいるところ 集合と部分写像 従業員と事業所の例 主キーと外部キー 従属性（冗長性） ビジネスルール スキーマにおける制約記述法のまとめ データたちのいるところ 関手的データモデルは、データベース理論を極限まで単純化します。基本概念は、テーブル、カラム、制約の3つだけです。この3つだけであらゆることを記述しようとします。背後に、対象、射、可換図式だけであらゆることを記述する圏論があるので大丈夫、ってことです。 そうはいっても現実は複雑です。複雑

デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか？ と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン！[/追記] 内容： はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使

最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル

IO(入出力）の形式化はけっこう難しい問題です。ここでは、ラベル付き遷移系によるIO（あるいは通信）のモデル化を述べます。XとYがラベル付き遷移系のとき、あるインターフェースを通じてXとYはIO（通信）をします。「Xが出力命令を実行すること」と「Yが入力命令を実行すること」は必ず同時に起こります。2つのラベル付き遷移系において、出力命令と入力命令が同時に実行されることがIO（または通信）ということになります。 内容： ラベル付き遷移系 IOインターフェースを持ったラベル付き遷移系 IOインターフェースによるIO結合 圏論の観点からの課題 ラベル付き遷移系 SとLは集合、δ:S×L→S は写像とします。3つ組 X = (S, L, δ) をラベル付き遷移系といいます。Sは状態空間、Lはラベルの集合、δが遷移写像です。Lの要素は、アクション記号と呼ばれることもあります。遷移写像δは、部分写像や

忘却関手とは何であるか？ を、一般的に定義するのはけっこう難しいことです。 さまざまな忘却関手 ですが、構造を忘れる忘却関手なら定義できなくもないようです。 P. V. Golubtsov, S. S. Moskaliuk "Method of Additional Structures on the Objects of a Monoidal Kleisli Category as a Background for Information Transformers Theory" （http://arxiv.org/abs/math-ph/0211067） に、次のような定義が載っています。 ∀X, Y ∈ Ob(C) the map F : C(X, Y) → C'(F(X), F(Y)) is injective, ∀X ∈ Ob(C), Y ∈ Ob(C') and an isom

僕は、分散バージョン管理システムMercurialをサッパリ理解できなかったわけですが、「これは便利だ」と思ってからはずっと使っています。しかし、ジョエル・スポルスキのように研究したわけではなくて、数個のコマンドを覚えただけです。日常的作業は、それらでなんとか間に合っている感じです。なので、僕が使っているコマンド（少数です）を紹介します。 bashのコマンドラインで紹介しますが、使っているOSはWindowsです。とはいえ、コマンドラインでの使い方はOSによらず共通のはずです。 コマンドの詳しい解説はしません。あまり考え込んだり、躊躇はせずに； 「四の五の言ってないで、使ってミソ」ってことです。 “Mercurialのすすめ”や“Mercurialの概念的な解説”を一応挙げおくと： http://local.joelonsoftware.com/wiki/%E5%88%86%E6%95%A

「メイヤー先生からモナド類似構造へ」で、「モナド類似物」という歯切れの悪い言葉を使っていたので、もっとスッキリした呼び名を与えて、ストレージIOの文脈における「モナド類似物」の解釈を与えようと思います。 内容： 言葉使い メイヤー指標 メイヤーオートマトンとその解釈 言葉使い 「代数、モノイド、マグマ」において、「代数」と「モノイド」という2つの言葉を区別するのは無理だろう、と言いました。なので、「代数」と「モノイド」を厳密に区別する気はありません。メイヤー先生の原則に従った「Command-Query分離された状態遷移系」から出てくる代数系は、双モノイドとコモノイド（余モノイド）の組で、さらに加群の構造を持ちます。これをメイヤーモノイド、メイヤー双モノイドと呼んでも別に悪くはない気がしますが、より意味が曖昧な「代数」を付けて「メイヤー代数」なら、まーなんとでも解釈（言い訳?）できるので、

メイヤー代数の全体に、適切な準同型を定義して追加すると圏になること、また、メイヤー代数の圏の上にメイヤー加群のインデックス付き圏も定義可能なことをザッと説明します。 内容： はじめに メイヤー代数の定義（復習） メイヤー代数の準同型の定義 メイヤー代数の圏と加群の圏 メイヤー代数の準同型の実例 メイヤー代数／メイヤー加群の守備範囲 はじめに メイヤー先生が提唱する「Command-Query分離された状態遷移系」の代数的な定式化はだいぶ以前から考えていたのですが、なんと呼べばいいかウジウジと悩んでいました。思い切って（勝手ながら）メイヤー代数と呼ぶことにしました（「メイヤー代数、メイヤー指標、メイヤーオートマトン」）。これで話がしやすくなりました。名前がないモノについて語るのは困難（ときに不可能）ですからね。 メイヤー代数の、僕にとっての主たる用途は、ファイルシステムやデータベース、メモリ

以前、「モノかつエピだがアイソではない例」というエントリーを書きました。順序集合を圏とみなした圏では、すべての射がモノかつエピとなりますが、アイソでない射も含まれる、という内容です。 もう少し普通な（なにが普通だ？）の例としてよく引き合いに出されるのは、有理数の集合Qを実数の集合Rに埋め込む包含写像です。ただし、集合圏ではなくて、位相空間の圏Topで考えます。e:Q→R in Top は、モノかつエピだがアイソではない例になっています。それと、単位元付きの可換環の圏で、整数環Zを有理数の環Qに埋め込む写像も、モノかつエピだがアイソではありません。これらの例を紹介します。 有理数を実数に埋め込む例 e:Q→R （eはembeddingから）は、集合と写像の意味で単射なので、圏Topのモノになります。この部分では、eが連続写像であることは特に使いません。次に、eがエピであることを示しましょう。

yoriyukiさんとの一連のやりとりで、「プログラマのための『ゲーデルの不完全性定理』」シリーズ第2回「速攻速習編」の「ゲーデルの不完全性定理への（ほんの少し）展望」に問題があると判明しました。その問題とは主に次の2点です。 あまりにも説明をはしょっている。そのため、誤解・誤読のリスクが高い。 「ゲーデル」という、歴史上実在の人物を表す固有名詞の使い方が間違っている。 1番目に関しては、ていねいな説明を書く以外の対策がなく、手短な展望としてはいかんともしがたいです。ただし、ある程度の予備知識を仮定してよいなら、次が補足説明になっています。 プログラマのための「ゲーデルの不完全性定理」番外：「デタラメだ」と言われたので… - 檜山正幸のキマイラ飼育記 Yoriyukiさんへの返答：内容的なコメント編 - 檜山正幸のキマイラ飼育記 メモ編 不完全性定理シリーズの背景とシナリオ - 檜山正幸の

えっ、それが疑問だったの？ あ、そう。んじゃ、ちょっと説明しましょう。 A、Bが集合だとして、 AとBの直和は、A＋B AとBの直積は、A×B AとBの指数は、BA と書きます。算数の足し算、掛け算、累乗の記号を使うのはなぜ？ いやっ、そもそも、直和＜ちょくわ＞、直積＜ちょくせき＞、指数＜しすう＞ってなに？ と、そんな疑問を持つ人のために。 記号の約束 集合とはいっても、ここでは有限集合だけを例に使うことにします。そして、[0] = {}, [1] = {1}, [2] = {1, 2}, [3] = {1, 2, 3} などと約束します。つまり、[n]と書いてあったらそれは「1からnまでの整数の集まり」です。こういった[n]は有限集合の典型例といえるでしょう。 有限集合Aに対して、#(A) は、Aの要素の個数だとします。例えば、#({a, b}) = 2 です。シャープ記号はナンバー記号