2001-09-07
λ. XML-RPC HOWTO
わぁ。XML-RPCってこんなに簡単なんだ。
λ. こないだの続きで、ケンブリッジ方程式
ケンブリッジ方程式は貨幣数量式 MV = PT から出て来る。この貨幣数量式だけど、Mは貨幣量、Vは貨幣の流通速度、Pは物価、Tは取引回数で、要するに取引総量(取引量×物価)と使われた貨幣総額(貨幣量×流通速度)が等しいっていう当り前の関係を表してる。ここで実質GDPをyで表すと、Tとyには正の相関があるので、とりあえず T = ay という比例関係が成立してると仮定して、貨幣数量式に代入して変形する。すると「M = p(a/V)y = kpy」となる。これがケンブリッジ方程式で、このk(=a/V)がマーシャルのk。
λ. …と、ここまで書いて、こないだ書いた事が間違ってた事に気がついた。「実質GDPが一定であれば、物価と貨幣量の間に比例的な関係が成立する」って書いたけど、これが成立するには、式を見ての通り、マーシャルのkも一定でなくちゃいけない。でも、マーシャルのkは…(以下略)
λ. Gtk+ 2.0 とか UTF-8 とか CSI とか Xlib とか
「Gtk+ 2.0は(UTF-8を強制される|CSIじゃない)から嫌い」ってのは何度か書いた記憶があるけど、ツールキットがCのlocale機構に依存しなくなるってのは良い傾向かも知れん。C言語と異なるlocaleのフレームワークを持つ言語からすると、ツールキットがC言語のlocale機能に依存してて、使うのにC言語のlocaleを気にしなくちゃ行けないという状況はあまりにウザかった。…かといって「あらゆるUTF-8じゃ〜」ってのはやっぱり行き過ぎだよな。僕なんかは、C言語から使う場合はCのlocaleに沿ってCSIを保ちたいし、明示的にg_locale_to_utf8等を呼ばなくちゃいけないのも面倒だ。
λ. 個人的には、Widgetに対してlocale(かcodec)オブジェクトをimbue出来るような設計が望ましかったんじゃないかと思うんだよね。Widgetはデフォルトでは親Widgetのlocaleを継承し、親を持たないWidgetはApplicationオブジェクトみたいなオブジェクトのlocaleを継承する。さらに、C言語用のインターフェースを、本体から分離して別のライブラリにする。gtk_set_localeもそのライブラリに移して、gtk_set_localeの仕事は、ApplicationオブジェクトにCのグローバルなlocaleをimbueする事だけにして、gtk_set_localeの行っていた他の仕事はgtk_initに移す。んで、これまで通りCSIしたい人はこれまで通りgtk_set_localeを呼び出して使う、UTF-8らう゛な人はUTF-8なlocaleオブジェクトをimbueする事にすると。
λ. 時々こんな妄想するんだけど、実際やるとフォントとか描画まわりで破綻しそう。それにXlib自体がCのlocaleに依存してるんだよな〜。C以外の言語でもlibX11を使うのが普通になってる現状を考えると、これは気持悪い。誰かさんがlibX11は単なるProtocol Interfaceであるべきだと言っていたけど、X Protocolを処理する部分を別の小さな別ライブラリにして、libX11自体はそれへのC言語用インターフェースって事に出来ないものだろうか。
λ. そういや、RubyX11の国際化関係ってruby-m17n待ちなのかなぁ。それと、RubyX11を使う場合はlibX11を使わないわけで、Xftのようなクライアントサイドの拡張はlibX11に依存しているからきっと使えないんだろうなぁ…
λ. 妹価
小泉首相は買い時とか言ってるけど、僕のまわりの人はみんな1万はきっと切ると言ってるし、来年のはじめには8千円位に…とか言う人もいる。あと、どのくらい下るのだろうか。ちょっと楽しみではある。
2004-09-07
λ. 『セクシーな数学 — ゲーデルから芸術・科学まで』, グレゴリー・J・チャイティン(Gregory J. Chaitin) [著], 黒川 利明 [訳]
読了。インタビューと講演からなっているので重複する部分が多いのは残念だった。内容も、アルゴリズム論的情報理論に興味を持つには十分だけど、もう少し技術的に踏み込んだものを読みたかったな。
λ. 「人狼」各職の基本戦略
メモ。[追記] 太田さんの自堕落記(2004-09-08)より、もう一つの「人狼」各職の基本戦略。
λ. 第2回プログラミングおよびプログラミング言語サマースクール (PPL Summer School 2004)
そうそう。来週はこれに参加します。
2006-09-07
λ. Haskellに正格性注釈が無いのは何故か?
lethevert is a programmer - Haskell : モナドはややこしい のコメント欄での議論で、「何故HaskellにはCleanの正格性注釈にあたるものはないのだろうか?」と思い少し考えた。
GHC等の処理系では内部で正格性解析を行い、正格性の情報を利用して最適化などを行ってはいる。では、もし正格性の情報をユーザーから見えない内部情報ではなく、型として扱うことにしたらどうなるだろうか。とりあえず、一般の関数型の型構築子 (->) とは別に、正格な関数のための型構築子 (!->) を導入することにする。そして、(!->) a b のシンタックスシュガーとして !a -> b と書けることにもする。
関数 a -> b が必要とされる文脈では正格な関数 !a -> b も使えて欲しいから、!a -> b は a -> b のサブタイプになるのが望ましい。しかし、現在のHaskellにはサブタイプ関係は存在しないため、これを実現するには型システムにそれなりの変更を加える必要がある。障壁その1。
これが仮に解決したとして、次に「f x = 0」のような非正格な関数に対して、正格な関数の型を宣言したときにどうなるかを考えてみる。例えばこんな感じ。
f :: !Int -> Int f x = 0
このとき処理系はどのように振舞うべきか。
- 明らかな選択肢は「型エラー」とすることだろう。しかし、正格性解析は通常は型検査後に行われるので、型エラーにしようとするとややこしいことになる。また、正格性解析は型検査と違ってそもそも完全ではなく、正格な関数を解析機が正格と認識できない場合がある。そのような場合にエラーとなるのは(よほど分かり易い基準でも無い限り)どうかとも思う。
- それとは別の選択肢として、エラーにはせず正格な関数としてコンパイル/実行するという選択肢がある。ただ、これは同じ式が型によって違った意味を持つということを意味するので、一種のアドホック多相である。型クラス以外のアドホック多相をさらに導入するというのは、やはり躊躇われるものがある。
これらの問題に勝る正格性注釈のメリットがあるかと言えば……私には無いように思われる。*1
ただ、Haskellも正格なプログラムを書きやすくする方向へは進化していて、「f x = x `seq` 0」と書く代わりに「f !x = 0」と書くことの出来るBangパターンというものが GHC 6.5 には実装されている。*2
正格なプログラムが書きにくいという単純な問題はこのBangパターンでまず解決するだろう。それでもしも型レベルでしか解決できない問題が残ったとしたら、その時点で正格性注釈について議論すれば良いのではないかと思う。
2006-09-14 追記
lethervertさんが Clean の正格性注釈について、<URL:http://d.hatena.ne.jp/lethevert/20060911/p1> で解説してくれた。一見して型に見えるけど、実際は型ではないとのこと。これでCleanへの疑問が一つ解けた。
λ. 「デスノート」作者、小畑健容疑者逮捕
正直、車のコンソールボックス内に刃渡り8.6センチのアーミーナイフ(折りたたみ式)を持っていたくらいで……と思わなくもない。みせしめ感がひしひしと。ところで、産経の「ライトのせいで…「デスノート」作者、小畑健容疑者逮捕」という表題は狙っているのかな。
2007-09-07
λ. SLACS2007のプログラム
が出ていた。気になる発表が幾つかあるなぁ。 向井先生も例のPrologの話で発表するのね。
λ. 台風
通勤中、多摩川の増水のため戸塚で東海道線が止まってしまって困った。 適当に他の経路で通勤したが、電車も駅も無茶苦茶混んでいて、朝から疲れた。
何も考えずに会社に行ってしまったが、台風で某予定は無くなっていたので、午前半休を取ってしまっても良かったな。 あるいは、会社休んでIPA未踏ソフトウェア創造事業2006年度下期千葉PM採択プロジェクト最終成果報告会の方に行くという手もあったなぁ。 ちと勿体無いことをしたかも。
2008-09-07
λ. 「君の身体を変換してみよ」展
ICC ONLINE | ICCキッズ・プログラム 2008 「君の身体を変換してみよ」展、そのうち見に行こうと思っていたらもう終わっていた。 <URL:http://www.youtube.com/watch?v=ZeSZsBwnp8c> の紹介を観ると非常に面白そうで、見に行けば良かったと後悔。
2009-09-07
λ. Google Code Jam 2009 Qualification Round
Google Code Jam には参加してないけど、どんな問題が出てるのかなと気になったので、試しに解いてみた。 Qualification Round だったからか、特に難しい問題は無かった。 Aは普通に。Cも普通にDP。少し面倒だったのがB。 一度各セルから水の流れる先のシンクへの写像を定義して、それから北西から順にセルを辿りながら、対応するシンク(に代表される同値類)にアルファベットを割り当てるという風にしたが……
