ToDo:
def f(a,b,c) l=[a,b,c] *q=[[a,0,0],[]] m={} until q.empty? s,h=q.shift next if m[s] m[s]=1 3.times{|f| 3.times{|t| x=s.dup x[t]+=y=[s[f],l[t]-x[t]].min x[f]-=y q.push([x,n=h+[[f,t]]]) if x.all?{|v|v<1||v==a*0.5} n.each do |f,t| puts %w(a b c)[f]+'=>'+%w(a b c)[t] end return end } } end end f(10,7,3)
こんなもんか。 ムダな計算しまくるけどメモアイズしてるからオッケー方針。
(01:34)
http://karetta.jp/article/blog/ll-spirit/033840
なんか一瞬答え違うなーと思ったけど、 一応 return 外すと同じ答え出てたからたぶん OK だろう。
(01:35)
http://alohakun.blog7.fc2.com/blog-entry-776.html
ここの syd_syd さんに同意だな。
結局皆さんが気にしてるのは〜からどの辺が「筋が良い」のか?
のあたり。
何がしたいか、っていう What はたぶんそれなりに 想像がつくというか割とプログラム書きの妄想の一つだと 思うんだけど、 How がよくわからないという。
という質問に対して返答が基本的に ふたたび What なのでよくわからなくなるんだな。 「できたプログラムの正しさが全て保証されるという点がブレイクスルーです」 とかそいう。 で How を知りたければ論文読むしか無いらしいのだけど、 それは残念なことで僕は文章読んでもコード書かないと さっぱりわからない人間らしいので。
(01:56)
アルファベットくらいだと甘いと思うので、 alnum の重複無しかつバイナリ無しくらいだとどんなもんだろうな。 まぁ記号ゴルフよりは簡単なので解けるのは間違いない。
(15:49)
初のフルタイム労働はまぁどうだったかなー と思い出してみる。
まぁ職場としては間違いなくいいんだろうな。 行く時間とか(俺は)適当だし 帰る時間とかも(俺は)適当だし (俺は)なんか斑鳩やってたりしたし。 結局クリアできんかったというか最後の方やってねえ。
で作業内容自体はまぁ(俺が)思ってたより 俺ちゃんと働くなーっていうか まぁそれなりにはやったような気が(俺は)した。 一応(俺は)今日で区切りをつけた気になってるし。 ただ内容自体は間違いなく Quine 書いたり ゴルフしたりしてる方がはるかに面白いんだよな。 まぁそんなもん元々期待してない。
あと飯とかボールとかスペースシップとかそのへんはまぁ、 どうでもいいや。 待遇は間違いなく豚に真珠的な感じとしか。
まぁそんなことよりやはり技術的な環境というか。 回りの人間が普通に話がわかる以上の エンジニヤばっかってのは嬉しいことだよなぁというのと、 あと次点は社内インフラに触れられることかなぁと。
話がわかるエンジニヤと仕事できるのが どのくらい良いことかっていうと、 つまり具体的に言うと不条理な要求があんまり来ないわけで。 あとちゃんとわかってる人に 評価されるってのは嬉しいことだよね、とかそういう。
気に喰わんのはアメリカぽいとかアメリカにあるとか デカいとか。
(16:19)
前 | 2007年 7月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
ようするに,僕もそっちにはそれほど深く関わってないのでよくわからない,という.要領を得ない解答しかできなくてすいません.
# 僕も,理論屋では無く,手を動かす方が好きなタイプなので.いつまでもそれではいかんのですが… 数学は難しいです (そもそも英語すらあまり読めないという.優秀な皆様がうらやましい).
論文を読んだのがだいぶ昔なのでいろいろ抜けてますけど,確定節からルールを作る際,その正しさが保証されることにより,かなり大きな可能性が広がるというのを実感して衝撃を受けた記憶があります.
一見大したことないように見えるかもしれませんが,他のパラダイムだと,(自動探索,あるいは人間のひらめきにより) 「一個一個ルールを作っていく」 という時点で,正しさの保証が困難だと思います.
あと,まだ抽象的な論文しか無いというのも悪いんでしょうね.具体的なツールが何かあれば良いのですが,まだまだそこまでは,なかなか.
問題の背景知識を確定節 (論理式の一種) で書いておいて,解きたい問題 (クエリ) の具体例を与える.そして,問題の具体例を簡単化できるルールを確定説から抽出していくことにより,正しさが保証されたプログラム (ルール) を段階的に蓄積していくことができるというのが,その本筋だったと思います.
論理式 = 面倒で冗長,プログラム書いた方が早い,という偏見があるようですが,僕は論理式よりも表現力が豊かな表記法を他に知りません.
表現力だけだったら,Haskell なども同じくらいリッチなのかもしれませんが.関数型の方面には,「どう書けるか」 ばかりで,「どう作るか」 という理論的なサポートが欠けていると感じます.
っと,また抽象論になってしまいましたね.すいません.
あー、うーん。またしてもこう少なくとも僕には What をおっしゃってるように見えるので理解するのは諦めようかなと思いますすいません。
例えば「問題の背景知識を確定節 (論理式の一種) で書いておいて,解きたい問題 (クエリ) の具体例を与える.そして,問題の具体例を簡単化できるルールを確定説から抽出していくことにより,正しさが保証されたプログラム (ルール) を段階的に蓄積していくことができる」で言うと、この文章全体として実現できたらスゴそう、ってのは全然わかるつもりです。ですが、「正しさが保証された」という点の実現がとても難しそうに見えるのにどうやってやるのかが全然わらない、という感じです。