C/C++のとんだ落とし穴（ハマっちまったよ） 上記の記事で、Shift_JIS（CP932）のコメントにまつわるトラブルを紹介しました。あまり時をおかずして、C/C++でまたハマりました。コメント事件ほどの意外性はないにしろ、事情を知らないと対処しにくいトラブルなので顛末を記しておきます。 この記事の内容は、僕が実際に体験した状況そのものではありませんが、それらしい例題を仕立てたので、ストーリーを追いかけてみてください。 内容： 例題：時刻付きのメッセージキュー 実装を変えてみると なんで、こんなことに 誰が悪いのか 例題：時刻付きのメッセージキュー 例題として、次のような機能を持つクラスを考えます。 文字列メッセージを、時刻（タイムスタンプ）を添えてキューで管理する。 クラスのインターフェースを、次のようなヘッダーファイルに記述します。 // msgq.h #ifndef MSGQ_H

昨日の記事「メイヤー代数やメイヤー加群はまだ整理不足」において、 双代数の条件を入れておいたのはトランザクションのためでした。トランザクションは、「更新オペレータをローカルでキューイングする」方式を前提とします。 と書きました。 ここで、トランザクションについてザッと説明しておきます。下の絵のような3つの方式について紹介して、僕の立場からのコメントを付けます。それぞれの方式を切り離した絵も後に再掲します。 詳細はともかく、絵の見方は： 時間は上から下の方向に経過します。 Sは状態空間です。データベースの可能なすべての状態の集合と考えればいいでしょう。 Vは状態の観測値の集合です。観測値は状態に関する部分的な情報を提供します。 fは状態を変更する処理を行うプログラムです。 Mは状態を更新するオペレータの集まり、モノイドとなります。 黒三角はデータのコピー（クローン）です。 S→S×V という

デイヴィッド・スピヴァックの著作物を読むときに注意しなくてはならないのは、彼が好んで例に出しているものを彼が好んでいるかどうか分からないことです。評価・価値判断にはあえて触れないのかも知れないし、好悪の感情や批判も称賛もほんとに興味ないのかも知れません。 僕は最初、Functorial Data Migration（http://arxiv.org/abs/1009.1166）は、関係（リレーショナル）データモデルを圏論の立場から合理化するものかと思いました。例として出しているのが関係（リレーショナル）データベースだからです。しかし実際は、スピヴァック理論は関係データモデルの諸概念をほとんど無意味化してしまいます。 RDF(Resource Description Framework）もしょっちゅう例に出しているので、RDFを推奨している印象もありましたが、スピヴァック理論からの帰結は「R

一昨日の「主キー／外部キーなんてドーデモイイ」と昨日の「絵で分かる！ 主キー／外部キーのアホらしさ」において、主キー／外部キーというのは、いわばメモリ番地とポインターのような、仕掛け・手段が露出しているだけのものだ、と説明しました。仕掛けが露出している結果、概念的には単純なもの（例えば単なる写像）の実現が複雑でしかも恣意的になっています。 今日は正規形、なかでも一番基本的な第1正規形の話です。控えめなデイヴィッド君に代わって、ジイサマ（檜山）が批判的に検討しましょう。 アトミックって何ですかぁ？ 圏論を使えばどうなる スピヴァックは型システムとデータベースシステムの統合を目指す アトミックって何ですかぁ？ 関係データベースである限り、かならず第1正規形になっていることが要求されます。で、第1正規形って何？ カラムの値がアトミックであることだと定義されます。アトミック？ それ何？ まーともか

ちょっと時間がたってしまったネタですが： プログラミングの出来る人と出来ない人の決定的な違い。 「プログラミングの出来る人と出来ない人の決定的な違い」？ ワンヤグさんの「プログラミングの出来る人と出来ない人の決定的な違い。」は、たくさんのブックマークを集めた記事。それに対して、id:JavaBlackさんが随分と否定的な記事を書き、さらにワンヤグさんが当該記事への追記として反論（らしきこと）を書いています。内容的に、ドチラかが全面的に正しいとは思えないし、ドチラかに味方する気もありません。 ですが、僕のセンサー（どんなセンサーかは最後に述べます）が反応したので、思うところを書いておきます。 時間順が前後しますが、まずはJavaBlackさんの記事のほうから。僕は、元記事「プログラミングの出来る人と出来ない人の決定的な違い。」を読む前に、JavaBlackさんの記事のほうを先に読んだのです。

ここで言うストレージには、「メモリ内の単純な変数、リストやハッシュマップのようなコンテナ・データ構造、ファイルシステム、キー・バリュー・ストア、関係データベースなど」、データを蓄えるモノならなんでも含めます。一般的なストレージに対して、書き込みを行うオペレーションだけを考えます。今回は読み出しは考えません。 ストレージと書き込みオペレーションの代数構造が線形代数と類似であることは何度か言及しました。例えば、「モニャドセミナー4の予定：トランザクション計算のフレームワークとか」(2009年7月)より引用： 副作用としての書き込み（メモリ／ストレージの更新）はモノイダル・スタンピング・モナドで定式化して、外部環境の参照（読み取り）は、その双対であるコモノイダル・スタンピング・コモナドを使って定式化します。書き込みのコミット操作は、モノイド作用（線形代数の用語では加群）で定式化します。計算処理の

モニャドセミナー3をやってから一週間以上経過しちゃったんですが、だいぶ遅れた補足です。なぜ補足が必要かというと、当日の後半、なにかに憑かれてラリラリだったから。ホワイトボードでの説明でグダグダだったところを少しはクリアにしよう、と。説明のストーリーや記号法は、セミナー当日のものとほぼ同じにしました。そのため、慣用の記法とは少しずれたところがあります。例えば、「μ」を使うところで「δ」を使ったりとか。 この記事は、あまり実例がなくて定義ばっかりの印象かもしれませんが、モニャドセミナーが事例中心だから、いいとしましょう。それと、やっぱりどっかで定義を確認することは必要なんです。確認作業では、つまんないタルイ計算が続きますが、我慢してヤッテ。 内容： モノイドの復習 直積による掛け算関手 掛け算関手の繰り返し適用 2回適用を1回につぶす自然変換δ クライスリ結合 クライスリ圏 ●モノイドの復習

だいぶ前に、クロージャ（閉包）って言葉の意味がわからないと書いたことがあります（「クロージャ、それなに？」）。最近また「クロージャ」って言葉を聞いたのですが、やっぱり何を意味しているのかわかんなくて（詮索する余裕もなくて）落ち着かない気分になりました。これはどうも精神衛生上よくない。 「クロージャ」と「ラムダ式」はまったく同義に扱ってもいいんじゃないのかな。例えばラムダ式 λx.(a*x + b) があるとき、自由変数a, bを具体化するための環境（変数束縛）をラムダ式と一緒にした (λx.(a*x + b), {a : 2, b : 1}) が古典的な意味のクロージャでしょ、たぶん。letを使えば、(let a = 2 b = 1; λx.(a*x + b)) みたく書けるけど、これも結局 (λa.λb.(λx.(a*x + b)))(2)(1) だから1個のラムダ式ですよね。 「クロー

最小抽象ファイルシステムの仕様案 最小抽象ファイルシステムの仕様案 その2 これらの続きです。 内容： ファイル名、だいたいのところ アクション設計の方針 エンティティの分類 アクション動詞の分類 API関数のネーミング API関数群の仕様 まだ続く ファイル名、だいたいのところ ファイル名に関しては： ちゃんと考えると、ものすごくめんどくさいですよね。なので、今は決めないことにします。 もう少し決めておくことにします。まず、名前文字という概念に関して次の規約をします。 文字番号32未満の文字は名前文字ではない。 '/'（スラッシュ）, '\'（バックスラッシュ）, ':'（コロン）は名前文字ではない。 他に禁止する文字があってもいいが、それは環境に依存する。 これじゃ曖昧な点が残ってますが、名前文字がなんであるかが確定すれば、次のBNFで「名前」という構文要素を定義できます。 名前 ::

調査／作業の依頼とその報告が、恐ろしくガラス張りなことになっているんだけど： 調査報告と問題点 対処のヒントと懸念 さらなる調査と実験 NNDAスタイルってのはこういう事だから、まーいいや。背景として、僕がKuwataさんに「考えて欲しい」と言っていることを記しましょう。 テンプレートエンジンの構造 基本的な要求は、Webサイト／Webアプリケーション／Webサービスを作成する作業を比較的細かいタスクに分割して、それらを最適に（できるだけ最適に近く）配分・配置したい、ということ。配分・配置とは、人と時間のリソース空間における計画のことです。配分・配置の自由度を高めるには、タスクどおしの依存性が少なくて、並行的に作業できるのが望ましいですよね。打ち合わせや報告の負担も少なくしたい（どうせゼロにはできませんけど）。 こんな要求に対する基本原理となるのが、テレンス・パーの厳密分離（Strict

Erlangのプロセス間ではメッセージ通信が容易に行えますが、JInterfaceライブラリを使うと、ErlangプロセスとJavaプログラムとのあいだでもメッセージ通信ができます。予備知識である分散Erlangから説明し、JInterfaceを紹介します。ちょっと長いので、前後編に分けて、今回の前編ではErlang側の話をします。 内容： Erlangを分散モードで動かそう セキュリティソフトとマジッククッキー 分散ノード達を互いに接続する リモートメッセージングを試してみよう 今回のまとめと次回の予定 後編 参考資料： http://www.erlang.org/doc/reference_manual/distributed.html Erlang Reference Manual（http://www.erlang.org/download/erl_spec47.ps.gz）11章

「読む人達へ」とはいっても一般論ではなくて、ジョニーが『層・圏・トポス』を読む勉強会をするらしいので、このメンバーへ老婆心から二三言っておきたいことです。 「層・圏・トポス 現代的集合像を求めて」 勉強会 - hiroki_fの日記 Diary?::2009-04-28 ジョニーの最初の企画「第５回Student Chapter, 「層、圏、トポス」の集中勉強会(企画中)」へのコメントにも書いたことだけど、竹内本は短時間・短期間で読むテキストには向いていません。一度ならず「もっと短いテキストがいいよ」って勧めたんだけど、ジョニーは「どうしてもコレを読みたい」と。 もちろん、『層・圏・トポス』がマズイということではありません。以下のエントリーでこの本を紹介もしてますし、僕個人にとってはなつかしい本でもあります。 「圏論番外：米田の補題に向けてのオシャベリ」のコメント欄 「竹内外史・著『層・圏

http://golem.ph.utexas.edu/category/2009/04/graphical_category_theory_demo.html で知りました。 http://www.j-paine.org/cgi-bin/webcats/webcats.php ページ内にあるボタンを押すと、圏論の諸概念に対して有限集合の圏における具体例が、式と図で表示されます。[Your results are here.」のhereをクリックするとResultページが現れます。「Equaliser in the Category of Finite Sets」とか「Ternary Coproduct in the Category of Finite Sets」とか。 乱数を使っているので、Resultは毎回違いますが、僕がやったとき Colimit in the Category of

※ 子供の話ばかりじゃアレ(?)だから、「カリー／ハワード（Curry-Howard）対応をうんと一般化するとどうなるか」みたいなネタで。 以前紹介したことがあるバエズ＆ステイのロゼッタストーン論文がarXivに入っていました。 題名: Physics, Topology, Logic and Computation: A Rosetta Stone 著者: John C. Baez, Mike Stay URL: http://arxiv.org/abs/0903.0340 ページ数: 73 この論文の最後のほうにある「The Rosetta Stone テーブル」のlarger versionは次のようなものです。 画像だとコピーに不便ですからテキストにしたもの： Category Theory Physics Topology Logic Computation object Hil

3月19日(木)にやったセミナーに関して、さっそくにKuwataさんによるまとめが公開されています。 http://return0.dyndns.org/log/2009/03/20#s_2（20日の記事までスクロール） これがまた、とんでもない力作で驚きました。とてもよく仕上がったレポートで、僕の話なんかより、これを読んだほうが分かりやすいくらい。ホントにお疲れさま。どうもありがとう。 Kuwataさん曰く： 今回は内容的に俺がまとめを書けるレベルじゃねえと思っていたら、他の参加者から「また徹夜してまとめ書くんでしょ」と言われてもう後に引けない状況。 僕も含めて皆さん期待していたのは確か。「まとめるんだよね、帰ったら書くんだよね、朝まで書くんだよねー」と、何人かがKuwataさんに声をかけていたけど、彼を殺してしまいかねないから、もうあまり言わないように。 Kuwataさん曰く： さすが

久々にThe n-Category Cafeを見たら、Mike Stayによる"The Continuation Passing Transform and the Yoneda Embedding"なんて記事がありました。 米田埋め込みは圏論ではお馴染み。継続渡しへの変換はコンピュータ・プログラミングではお馴染み。 この2つは、実は同じものなんだよ。なんで、誰もこのことを言わないんだろうね？ The Yoneda embedding is familiar in category theory. The continuation passing transform is familiar in computer programming. They're the same thing! Why doesn't anyone ever say so? Mike Stayのこの記事、面白いのだ

JavaScriptでカリー化。ありがち、つうか実際にあるでしょうね。小ネタと思ってやりはじめたら、意外と混乱した。一種のメタプログラミングのはずだが、実際にはテキスト加工処理。 内容： カリー化ってなに？ カリー化を行う関数を作る：準備 カリー化を行う関数を作る：テキストのパッチワーク カリー化を行う関数を作る：組み立て ●カリー化ってなに？ 2引数の関数f(x, y)に対して、「gがfのカリー化」だとは、f(x, y) = g(x)(y) が常に成立すること -- ゴチャゴチャ説明するより実例実例： functio sum(x, y) { return x + y; } このsumのカリー化の例： function curried_sum(x) { return function (y) {return sum(x, y);} } curreid_sum関数は1引数で、戻り値として関数

Erlangのエラーメッセージは暗号のようだ（Cryptic error messages）とか言われたりします。確かに分かりにくいです。http://bluebones.net/2006/12/erlang-error-messages/ に良いまとめがあった*1ので、これを敷衍＜ふえん＞する形で説明します。 内容： 例外の一般論 ランタイムエラーとスタックトレース reasonタームの一覧 ●例外の一般論 Erlangの例外（exceptions）は次の3種に分類されます。 throw例外 ： ユーザー（プログラマ）が任意の時点で生成する例外 exit例外 ： プロセス*2の終了に伴って生成される例外 error例外 ：主にシステムが生成するランタイムエラー それぞれの例外を、次の関数で引き起こす（raiseする）ことができます。 throw(Term) exit(Term) erla

さらにさらに「ラムダ計算、論理、圏」セミナーへの補足・応答： 今日中に他のエントリーにも一言二言。 hiroki_fさん： 映画マトリックスは好きな映画の一つだ。 マトリックスの世界、ミニモイの国、ネバーランドなんかを妄想するのはいいよね、仮想の世界のなかに入り込んだり世界を外から眺めたり。マジでトレーニングになるよ。 限られたロジックで世界を認識する知的生命体は何処まで世界を認知できるかと言うことを考えてみたい。 この問題意識は重要だと思います。「閉圏、弱いラムダ計算、弱い論理」における、「“そとの人”と“なかの人”」の議論はまさにこの問題です。 Kuwataさん： 実際のプログラミング言語のラムダ式って、ぶっちゃけ大きなラムダ式だよな普通。例えば Hakell の場合、ラムダ抽象は以下のどっちでもいい。 \x -> \y -> x + y \ x y -> x + y 実際のプログラミ