#速報: FreeBSD 8.2R上で、HEADのtestが失敗します。control.thread-pool内:
#test forced shutdown, expects killed ==> ok
failed.
discrepancies found. Errors are:
test error results: expects (ng ng ng ng ng) => got (ng ng ng ng)
#後で時間がとれたら追ってみます。
#バグです。直しました > construct-json-string
#そのテスト失敗、たまーにLinuxでも見るので、タイミング絡みじゃないかと思うんですが尻尾をつかめてません。
#なるほど
#後で追えたら追ってみます。
#(worker pool) で (thread-specific-set! self #f) してから (~ pool'result-queue) に結果をいれてるからじゃないですかね？ wait-all は thread-specific が #f になるまでを待っているので。
#あーそれっぽいです。
#コミットしました (385e49c)。試してみてください＞(び)
#通りました(FreeBSD 8.2R)。ありがとうございます。
#まはろー>enami
#予想があたってよかったです。
#こんちわ
#aとbを返すメソッドがほしい。
#一方でaとcを返すメソッドも欲しい。
#それぞれ関連してるんだけど、それなりに時間がかかる。
#つまりaとbだけがほしい時にはcまで計算して返すのは無駄に思える。
#そういうのって何度か経験してるんだけど、こういう場合ってどういう風にデザインします？
#あ、関連があるっていうのはつまり全く別々ではなく
#一緒に計算するなら、若干得する。
#例えばaだけ返す=10
#bだけ返す=10
#cだけ返す=10
#かかるけど
#a,bを返す=15
#お、Haskeller来場?w
#a,cを返す=15
#a,b,cを返す=20みたいな
#いや、今はC#で書いててちょっとどうしたものかと
#CLならオプショナルな引数で買えすものを切り替え。SchemeならAPIとしては別々に用意して、共通処理だけ内部でくくり出しとく、かな。
#確かにHaskellとかだとa,b,c返すようにしておいて、使う方が必要なものだけ使えばいいってなるわけですが
#共通のところまで計算するメソッド書いて、+メモワイズ
#でしょうか
#ああ、そうか引数でどれを返すかを選択するんだ。
#サンキュー！！
#いつも思うけどC#ってtupleを簡単に作れないからどうしても返り値の構造を決めちゃって、
#それでつい考えがそっちに凝り固まってしまう
#引数でどれ返すか切り替えるっていうのは静的型な人は嫌だと思うけど。CLはどっちかというと関数の数を減らして、細かい差異をオプショナルやキーワード引数でカスタマイズできるって方向が多いように思う。
#Gaucheでもそれに引きずられてるAPIがいくらかあるけれど、Scheme的には戻り値の型が定まってる方が綺麗だなと最近は思ってて、なるべく分けるようにしてる。
#DPとメモ化の違いって何でしょうか？
#「こんちわ」っていうと「・・・・」
#「こういう場合どうすればいい？」っていうと「わいやわいや」
#こだまじゃないよね・・・
#人工無脳(たぶん)
#あーあとまあ、a,b,cのどれを使いたくなるか後になるまでわからない、ってやつなら、「呼んだらaを返すthunk」「呼んだらbを返すthunk」「呼んだらcを返すthunk」を返すって場合もある。内部で状態を共有してるので途中結果は共有できる、みたいな。
#DPって何だっけ(そこかよ...)
#ああ、遅延評価そのものだ。
#DPとメモ化 < 同じものだって立場もあるみたいだけど、印象としてはメモ化の方が目的が広い感じを受ける(DPはその一部)んだが、実装まで考えるとやっぱり同じかもしれない。
#DPの印象は最初に
#「曖昧性を許すシーケンスのマッチング」みたいので学んで、それでイメージがついちゃってるからかな。
#DPは動的計画法の略です
#ああなるほど
#メモ化は再帰で書くイメージでDPは配列を使うイメージがあります
##それです。DPの実装例です
#私もDPと聞くと配列ってイメージなんだけど、それは単に適用する問題の定義域が決まってて連続してる場合は単に配列が効率よいってだけなんじゃないかなと。
#Packrat parserってメモ化してるけど、あれの動作ってDPと思ってみればDPに見えない? どうなんだろ。
#DPは配列を使うとはかぎらないわけでHaskellの"fib = 1:1:zipWith (+) fib (tail fib)"もDPです
#おお、それはメモ化っぽくないな
#メモ化とDPって違うっちゃ違うのか
#実装技法としては同じようなもんだけど、DPの方が「探索」を目的にしてる感じがする?「メモ化」は単にキャッシュによる効率化を見てて。
#それもイメージかなあ。
#言われてみるとDPはたしかに最適解を探すみたいな感じもありますね
#この質問を前に人にぶつけたことがあるんですけど表の埋め方が違うみたいな答えをもらいました。
#厳密なちがいはなくて、イメージの違いなんですかねぇ。
##動的計画法は、「ある状態までの計算結果を記憶させる」ものであるのに対し、メモ化再帰は「ある状態以降の計算結果を記憶させる」ものとなります。
#っておっしゃっておられるがいかが？
#なんかあんまり本質的じゃない気もするな
#うーん、それも視点の問題でイメージのような…
#ひょっとして、関数データ引数か継続渡しかの問題と同質では？という気がしてきました
##なんかこの人もまとめで似たようなことを
#あんまり良く分からん
#これかなぁ
>メモ化再帰が目的値から依存してる値に向かうのに対して、DPは必要な値から目的の値、という計算方向をもつものを指す
#ああ、その文章もあったな
##これもよさそうだけど、途中で脱落
#メモ化「ふむふむその計算か。その結果なら持っておるぞ」動的計画法「旦那！そこまでの計算ならあっしが保存しときましたぜ」
#やっぱ書かないとついていけない
#確かに典型的な例ではそうなると思うんだけど、問題によっては解を求める方向が本質的に足元から進んでゆくって形になってて、そしたらメモ化とDPは(コード上は)同じになっちゃうんじゃなかろうか。例えばパーザとか状態機械みたいなもので、途中結果も解の一部みたいなもの。徐々に入力を食わせて徐々に出力が出てくる。
#その時に、途中状態が記憶されてて「お、ここは計算済みだから再利用しよう」ってなるのは、DPともメモ化とも言えるような…
#あと、shiroさんがちょっといってた事とかぶるかもしれませんが、DPは貪欲法と組み合わせることが多いような
#さっきのfibにしても、fib!!100を計算しようとすると目的値から依存してる値に向かうけど、fibを無限列として最初から食べてこうとするとDP的になるとか。
#あ、そんなことないか。fib!!100は最初から舐めることになるか。
#どちらも動機としては乗数オーダーになるものを線形オーダーに抑えたいという所からきてますしね。
#さっきのはそうですね。おまけに全部記録するから遅い><
#こういうのって擬似多項式アルゴリズムっていうんんですね。しらなかった。
#私の感覚では、DPにはおおざっぱにいって2通りの手法があって、1つはボトムアップに構成するもの、もう1つはトップダウンに構成するものです。メモ化法はどちらかというと後者のイメージですね。半年ほど前に書いた記事 > http://d.hatena.ne.jp/nobsun/20101217/1292515309 
Gauche > Archives > 2011/05/31