日々の流転

λ. 他にマトモな活動をしている時ってやっぱ日記を書くのって面倒だ。

λ. Rouge(る〜じゅ)

ようやく、lambdaが関数じゃなくても実装できる事に気が付いたが、CommonLispは気に入らないところが多すぎるので、Schemeっぽく方向転換。完全数不完全数の概念はめんどくさいそうなのでパス、IntegerとRationalが完全数でFloatは不完全数でいいや。あと、マクロの実装をどうすれば良いかがいまいち良く解らない。月曜の授業の時に安村先生に訊いてみよ。

λ. サマランチ・IOC会長　16日勇退

という記事が昨日の毎日新聞にあった。サマランチは引退後の新委員候補の一人に、国際近代五種連合副会長を務める同姓同名の長男(41)を推薦したらしい。また、16日の会長戦の有力候補は以下の3人らしい。

• ジャック・ロゲ(Jacques Rogge)理事(58)＝ベルギー
• ディック・パウンド前副会長(59)＝カナダ
• 金雲龍(Un Yong Kim)理事(70)＝韓国

【2006-05-13追記】 どうでも良いが、この金雲龍という人はその後横領でつかまって、「国益のために釈放を」とかワケのわからんことを言ってる。ウケる。

λ. Gimp-Ruby

下らない経緯(historical origins)から、PDBの関数はGimp::PDBのメソッドにして、以下のようにgimp_で始まるPDBの関数だけ「gimp_」を取った名前でGimpモジュールのモジュール関数としても呼べるようにしてたんだけど、

Gimp::edit_fill(drawable, fill_type)
Gimp::PDB.gimp_edit_fill(drawable, fill_type)
Gimp::PDB.plug_in_gauss_rle(run_mode, image, drawable, radius, horizontal, vertical)

λ. 全部、そのままの名前でGimpモジュールのモジュール関数にしたくなってきた。絶対こっちの方が自然だよな。あ〜、どうしよ。

Gimp::gimp_edit_fill(drawable, fill_type)
Gimp::plug_in_gauss_rle(run_mode, image, drawable, radius, horizontal, vertical)

λ. ショートサーキット論理評価

Rubyも当然サポートしてるはず。

irb(main):001:0> false and puts("hoge")
false
irb(main):002:0> false or puts("hoge")
hoge
nil

λ. Rouge(る〜じゅ) その2

ちょっと変態的な記述を受け付けるようにしてみた。うひっ。

rouge> ((lambda (x . y) (* x y)) 5 . 6)
30

guile> ((lambda (x . y) (* x y)) 5 . 6)
standard input:1:1: In expression ((lambda # #) 5 . 6):
standard input:1:1: Wrong number of arguments to #<procedure (x . y)>
ABORT: (wrong-number-of-args)

λ. 何とかプロジェクト

偶然ミーティングをやっていた近くを通りかかったので、話を聞いてきた。

λ. 換え字暗号

某氏が、換え字暗号を解読するためのプログラムを書いて実行させていた。暗号化されたデータに適当な換え字を適用して、キーワードがその中に含まれるかどうかで、正しい解読結果の候補を探すという仕組み。しかし、1時間以上たっても終わらないようだ。

単なる換え字暗号なんだから、データ自体を変換するのではなく、キーワードの方を逆変換して検索した方が絶対速いに決まってる。

λ. 『しゃぼてん』 野中 英次

を読んだ。

λ. class From

こんなコードを随分頻繁に書いているような気がする。自然数を0から順番に列挙したくなる事とかって頻繁にあるよね?

class From
  include Enumerable
 
  def initialize(from = 0)
    @from = from
  end
 
  def each
    i = @from
    loop {
      yield i
      i = i.succ
    }
  end
end

それとも、無限大を表わすオブジェクトを作って 0..Infinity とか書けた方が良いのかな? coerceを使って比較演算子を定義するのが面倒そう。

λ. 第三十一回圏論勉強会

今日は圏論勉強会だった。写真

今回、面白かったのは、以下の練習問題。

For n≧2, not every n-ary function which is computable in each argument needs to be computable. (Hint: take g total nonrecursive and set f(x,y) = g(min{x,y}) ).

最初、「fは各成分についても計算可能ではないのでは?」*1と思ってしまったけど、ちゃんと計算可能だった。直観的には、f(n,-) では n 以下の自然数は有限個なので、それらに対するgの値をテーブルとして持てば良い。

λ. GHCの“Generalised derived instances for newtypes”便利かも

これまでGHC拡張の Generalised derived instances for newtypes はそんなに便利だとは思っていなかったけど、<URL:http://lambda-the-ultimate.org/node/2749#comment-41075> の以下の例を見て、これは便利かもと思った。

newtype X a = X (ReaderT XConf (StateT XState IO) a)
  deriving (Functor, Monad, MonadIO, MonadState XState, MonadReader XConf)

λ. ω人の小人のパズル

小人のパズルを100人からω人にしたらどうなるかという話を、PPL2009の懇親会で聞いた。 すなわち、各小人の前に可算無限人の小人がいる場合。

ω人の小人が怪獣に捕まってしまいました。 小人たちが怪獣に命乞いをしたところ、条件を出されました。

怪獣が小人たちを縦に一列に並べ、それぞれの小人の頭に 赤か黄色か青のうちのどれか一色の帽子を被せます。 小人たちは自分より前に並んでいる小人の帽子の色はすべてわかりますが、 自分を含め、後ろに並んでいる小人の帽子の色は全くわかりません。 （各小人は、自分の前に並んでいるω人分の帽子の色がすべてわかる）

小人たちはひとりずつ赤か青か黄色の色を一回だけ答えることができ、 それが自分の帽子の色と同じだった場合は命が助かるというものです。 答える順番はどの小人からでも構いません。

このような条件が与えられ、小人たちには作戦タイムが与えられました。 小人たちは少しでも数多く生き残れるような戦術をとるものとします。 たとえば、一番後ろの小人が目の前の小人の帽子の色を答え、 その小人は食べられてしまうとしても、次に後ろから二番目の小人が 今と同じ答えを言えば、その小人は助かります。 これを繰り返していけば、最低でも半分の小人は助かることなります。

さて、小人たちは何人助かるでしょうか？ また、そのときの戦略は？

なお、被らされる帽子の順番に特徴的なもの （赤、青、黄色が順番にならんでいるとか） はないものとします。

λ. 『抽象によるソフトウェア設計』がついに出版されます

先日、レビュワーを募集していた "Software Abstractions"の翻訳本ですが、ついに来週『抽象によるソフトウェア設計』として出版されることになりました。 2009年のFLTVで告知してから二年も経ってしまいましたが、ついに出版されることになったかと思うと非常に感慨深いです。これは訳者の贔屓目ですが、それだけの時間に見合う素晴らしい仕上がりの本になっていると思います。

抽象によるソフトウェア設計−Alloyではじめる形式手法−(Ｄａｎｉｅｌ Jackson/中島 震/今井 健男/酒井 政裕/遠藤 侑介/片岡 欣夫)

この本はAlloyという言語・ツールを用いた形式手法の教科書です。

Alloyというのは、モデル発見器と呼ばれているツールの一つで、条件を与えるとその条件を満たす具体例を探してくれます。モデルというのは、条件が連立方程式であればその解だし、条件が数独のルールと問題だったらその解とかです。Alloyについてはこの日記でもAlloyタグのついた記事で何度か触れてきました。

この日記ではAlloyはパズルを解いたりといった目的にしか使っていなかったけれど、その本来の使い方は、ソフトウェアの設計を書いてみて、変なところや見落としているケースがないかを確かめたりという使い方であり、この本ではそういった手法について書かれています。 この本を読めば、正しい抽象化がソフトウェアにとって死活的に重要であること、そして正しい抽象化を追求するためにAlloyを用いる方法を学べるでしょう。

(続きはきっと後で書く)

関連

• サポートページ