リリカル☆Lisp開発日記

もっとevalされるべきとは、「もっと評価されるべき」のLISP方言である。
eval関数は、プログラムを評価する関数で、詳細については、Wikipediaのevalの記事を参照。
(もっとevalされるべきとは (モットイーバルサレルベキとは) – ニコニコ大百科)

ねーよｗｗｗｗｗ

KOFに行ってきました。
ニコニコ技術部のMZ-700の実演とか楽しかったです。
KOFの後はK*BUGの打ち上げに参加させていただきました。
他に学生がいなかったためか、学生価格「0円」という驚異的な事態に。
ありがとうございます。本当にありがとうございます。
本当は何かBSDのプロジェクトに貢献することにより恩返しをするべきなのでしょうが、
私にはそんな力量は無いのでK*BUGの宣伝でどうかお許し下さい。
—
K*BUG
– Kansai *BSD Users Group の略
– 日本語名は、「関西 *BSD ユーザ会」
– BSDに限らず、Squeakなど色んな楽しい話が出てくる
– 主に、大阪と京都で研究会が開かれる
– 酒豪が多い
—
こんな集まりです。
興味がある方は是非ご参加下さい。

うかべんの時に作ったCLISP用のプログラムを、SBCLでも動くようにしてみました。
そして、動かそうとしてみたら、

> ; note: *INLINE-EXPANSION-LIMIT* (200) was exceeded, probably trying to
> ;   inline a recursive function.

こんなメッセージが出たまま固まってしまいました。
どうも、マクロ展開で生成される関数が長すぎるのが悪いみたいです。
コンパイルしたら動くんじゃないかと思い、試してみると、
メモリが足りなくなり、ハードディスクがガリガリなり始めました。
今度はもっとスペックの高いマシンの上でコンパイルしてみると、無事コンパイルできました。
(それでも、展開系が長くなりすぎるとコンパイル中にエラーが発生しました。)
で、計測してみました(このときに前のエントリーの通り、スライドの重大な誤りに気づきました)。

[計算]
SBCL    CLISP    里々
215us   1269us   55646us
[括弧]
SBCL         CLISP    里々
47860usec    22760us   13295us

計算速っ！！！！
あまりの速さに驚きました。
コンパイルに異常にリソースを食われたのも納得。
しかし、括弧の処理(主に文字列処理)は案外遅かったです。
汚いコードだったから上手く最適化できなかったんでしょうかね。

どうも、gettimeofdayの精度が悪いようなので、
QueryPerformanceCounterを使うようにして、計測をやり直してみたんですよ。
ブラウザ等を立ち上げたまま計測したためか、前に計測したときよりも、全体的に遅かったんですが、

***
[計算]                   (前回)        (今回)
- オリジナル里々：       3700usec ---> 55646usec (前回の約15倍)
- Lisp（コンパイル済）：  800usec --->  1269usec (前回の約1.5倍)
[括弧]                   (前回)        (今回)
- オリジナル里々：       7600usec  ---> 13295usec (前回の1.7倍)
- Lisp（コンパイル済）：16300usec  ---> 22760usec (前回の1.4倍)
***

…いくらなんでも、里々の計算式の処理があきらかに遅すぎる。
しかし、gettimeofdayに戻して計測しても同じくらいの時間に。
そんな馬鹿なと思い、スライドを作ったときの計測データを見直してみたら、
***
400回: 75.2
200回: 38.2
差分: 37
(単位はms)
***
0が一つ抜けてました。 orz
とんでもないミスをしていました。本当にすみません。
計測データを改めて全て見直してみましたが、間違いはここだけのようです。
一応、スライドを作るときに使った生データを置いておきます。
計測はそれぞれを10回ずつ行い、その平均(行頭が@で始まるもの)の差を取っています。
単位はms(cygwinのgettimeofdayはミリ秒単位でしか時間を取得できないため)、
calcは計算式、kakkoは括弧の計測を表しています。

——————————–
// satori-calc400
78
76
75
76
74
75
77
75
75
75
@75.2
// lisp-calc400
8
8
9
8
8
9
8
9
8
9
@8.4
// lisp(c)-calc400
4
4
4
4
4
4
4
4
4
4
@4
// satori-calc200
38
38
39
38
39
38
38
38
38
38
@38.2
// lisp-calc200
5
5
5
5
5
5
5
5
5
5
@5
// lisp(c)-calc200
4
3
3
4
3
3
3
3
3
3
3
@3.2
—-
// satori-kakko50
18
17
16
17
17
17
17
17
17
16
@16.9
// lisp-kakko50
113
112
112
111
112
115
113
111
112
111
@112.2
// lisp(c)-kakko50
39
37
37
37
37
38
38
38
38
38
@37.7
// satori-kakko50
9
9
8
9
8
9
8
8
8
8
9
@9.3
// lisp-kakko50
51
50
50
51
50
50
51
50
50
51
@50.4
// lisp(c)-kakko50
21
22
22
22
22
21
21
21
21
21
@21.4

修正した資料。
当日使ったもやつの誤字を修正したものです。
うかべん大阪#4の話。
CLIPS少し気になった。今度調べてみる。
Prologは状態数が爆発するんじゃ…という話があったけどカット(!)があるよ。
あと、『ルールエンジン』より『推論エンジン』の方がカッコイイと思う。
懇親会。食べ放題。学生料金500円。安すぎ。ワロタ。ありがとうございます。
私の講演でLispに興味を持ってくれた人がいた。やったね。
Lisp in Box for Windows。zipじゃなくてインストーラ付きのものがあることを知った。
でもそっちの方が分かりにくかった。

という訳で行ってきました
何か書こうと思ったら、ヒノハルさんのげっかんにっきに全て書いてあるので、
そちらを見てくださいということで(笑)
本日使った資料は、少々手を加えて数日後にうｐします。
また、ソースコードなどは現在は公開するつもりはありませんが、
要望がありましたら、考えておきます。
それでは皆さんお疲れ様でした。

11/3のうかべんの資料が完成しました。
これです。
疲れたんで寝ます。
誤字とかあったらこっそり教えてください。
あ、CLANNADは今週も面白かったです。
次回予告を見たところ、ちゃんと猫の話もやるみたいですね。
相変わらずことみの出番が多い。そして風子でてこない。
いつしかのリリカルの続き。

若干流行に乗り遅れた感じはありますが、
Cyanを触ってみました。
色々気になったけど、時間が無いから一点だけ。
関数の中で関数を作れるのか試してみたんですが、

def(reverse)^(lst):
iter:=^(lst2, acc):
say(lst2)
if (lst2.null?()):
acc
else:
iter(lst2.cdr(), [lst2.car()|acc])
iter(lst, [])
reverse([1,2,3,4,5])
# => [5, 4, 3, 2, 1]
# 出力されるのは
# [1, 2, 3, 4, 5]
# [2, 3, 4, 5]
# [3, 4, 5]
# [4, 5]
# [5]
# []

これは上手く動きますが、
次のコードだと、

def(reverse)^(lst):
iter:=^(lst, acc):
say(lst)
if (lst.null?()):
acc
else:
iter(lst.cdr(), [lst.car()|acc])
iter(lst, [])
reverse([1,2,3,4,5])
# => (無限ループで結果出ず)
# 出力されるのは
# [1, 2, 3, 4, 5]
# [2, 3, 4, 5]
# [2, 3, 4, 5]
# [2, 3, 4, 5]
# [2, 3, 4, 5]
# ...(以下同様)...

何故か無限ループに陥ってしまいます。
iterに代入される関数の参照してる「lst」が外側のlstかとも思ったんですが、
一度だけはCDRが取れてるし、そういう仕様でもなさそう。
試しにこんなコードを動かしてみたんですが、

m=100
def(f1)^():
i:=^(n):
say(n+m)
i(1)
m:=3
i(1)
m:=2
i(1)
f1()
# 出力されるのは
# 101
# 4
# 3

このように動くのを見たところ、関数内部における変数への参照があると、
定義された環境から外の環境に向かって、順番に変数を探すように思えるんですが、
引数の場合だけ何か扱いが違うんですかね。
ローカル変数の取り扱いの説明が、この記事だけだと、分からないところが多いので、
出来れば詳しい説明をお願いします。

ニコニコ動画にShibuya.lisp Tech Talk #1の開会の挨拶があがってました。
Shibuya.lispテクニカル・トーク#1 開会の挨拶 ひげぽん
(要アカウント)
最初のスライドに”Why Lisp?”と書いてありますが、
この言葉、何処かで聞いたことがあるな…と思って調べてみたら、
「OnLisp」の1.5節が”なぜ(またはいつ)Lispか”というタイトルで、

今や問いはなぜLispか？ではなくいつLispか？になっている．

なんて書いてました。
残念ながら少なくても日本ではいまだに「なぜLispか？」の時代みたいです。
前々から言っていた、SHIORIの問題ですが、ぽなさんに解決法を教えていただきました。
仕様の見落としという非常に恥ずかしい原因でした…なんとも恥ずかしい。
そんなわけで、ようやく前に進めました。

しかし、うかべんまで本当に時間がなくなってきた。
非常にまずい感じです。
17日のリリカルの続き

とりあえず、OnTranslateメッセージがやってきたときに、
直前に送ったリクエスト再び送るようにしてみました。

SHIORI/3.0 200 OK
Sender: matsuri
Charset: UTF-8
Value: \0\s[0]\1\s[10]\0おはー\1らっきー\e

GET SHIORI/3.0
ID: OnTranslate
Sender: SSP
Charset: UTF-8
SecurityLevel: local
Reference0: \0\s[0]\1\s[10]\0おはダ

SHIORI/3.0 200 OK
Sender: matsuri
Charset: UTF-8
Value: \0\s[0]\1\s[10]\0おはー\1らっきー\e

とりあえず、これくらいの長さの台詞ならちゃんと喋ってくれるようになってくれました。
しかし、長い台詞を表示しようとすると結局途中で切れてしまいます。
それにCROWでは相変わらず何も喋ってくれず。
まー、それは置いといて、CLANNAD AFTER第2話が放送されました。
ほんと良かった。もう毎週木曜がたのしみでなりません。
どうやら有紀寧さんシナリオもちゃんとやりそうだし楽しみ。
ただ相変わらず風子分が足りない。
1話に続いて、本来風子の出るところにことみが出てきてます。
そして、それも置いといて昨日のリリカルの続き