ブロック崩し 1
ブロック崩しをGAで学習させる方法を考える
sasamijp/breakout_solver · GitHub
まず評価関数を出すためにブロック崩しのシミュレーターが必要。スピードが命なので、めっちゃ速いのを作った。
これは乱数でバーの跳ね返り角度を決めてゲームをやらせているところで、ブロックが全部壊れると辿った軌道が表示される。
ステージは124本の１次方程式でできていて、軌道との交点を算出して傾きを反転した線を再定義する処理を繰り返してボールの動きを出している。
ボールの大きさとか考えてないけど、ひとまずこれでやる。
遺伝子の設計をする。
スーパーマリオブラザーズを学習させてみた（1-1） ‐ ニコニコ動画:GINZA
この動画を参考に設計した。
マリオの遺伝子は大体こんなんなってる。tが時間で、aが行動だと思ってほしい。ある時間に対して、ある行動が定義される。
ブロック崩しの遺伝子。eはボールがバーに当たる瞬間のことで、aが行動。ある衝突に対して、ある行動が定義される。要は、ボールが上にいる間も遺伝子に基づいた行動をしてたら無駄なので省いたことでtがeに変わった。
このモデルをいい感じにバイナリにして一個体を表現する。
遺伝子にそれぞれ6ビットの行動が入っている。n番目の衝突まで遺伝子を持たせようとすると、6nビットのビット列が遺伝子として必要。
交叉方法を考えた。
赤いとこ始点からずっと一緒やん！青いとこ交換したろ！みたいな感じ。正直自分でもよくわかってない。ここはもう少し考えなくてはいけない。
動かしてみる。
進化しとるやんけワレ！導き出された個体を見てみる。
まあなんか早いっちゃ早いんだけどもうちょっとがんばれない君？みたいな感じですね。
乱数で跳ね返り位置決めるとどんなもんになるか試す。
ん...？
GAの解超えとるやんけワレ！
乱数でもGAと同じぐらいいいやつ出ることがわかった。よく考えてみたら3回跳ね返すパターンは21万ぐらいしかないので乱数でも出てきそうなものである そりゃそうだろ
反省
GAを使う意味があまりないことがわかった。全体的に考えなおしていきたい 。
天海春香さんと会話したい 17
こう言われたらこう返すというデータを蓄積して返答させる方法を考えてきた。その方法だと、返答を選びとるにあたって「今話しかけられた文章」というデータしか手がかりにならない。そこで、文脈を読み取る仕組みを考えてみた。
入力とSSをどこまで比較するかの問題なのだが、「こう言われたらこう返す」の「こう言われたら」の部分だけ比較するのではなく、「こう言われてこう言ってこう言われてこう返す」の「こう言われてこう言ってこう言われて」ぐらいの部分までより深く比較することで、少しでも文脈を読み取らせることができるのではないかと考えた。
どういうデータ形式でSSを保存しておけばスピーディに文脈を比較できるかについて考えてみる
Neo4jというグラフデータベースを使って会話の繋がりをグラフにしてみる
こう言われたらこう返す、の連続で繋がった線になる。これだけでも従来の仕組みでいくなら割と充分なのだが、どの単語がどの発言に属しているかみたいな情報も参照できるようにしたかったのでもう少し複雑にしてみる。
mecabに文章をパースさせて単語につく情報を木にしてみた。この部分だけを生成するのに4分ぐらいかかった ちょっと必要以上に複雑にしすぎた感がある。もう少しシンプルにいきたい。
ちくわ大明神
ちくわ大明神とその他について書いていく
ちくわ大明神
はるアイコン鯖ちくわ建築のパイオニアであり、ちくわの神様が祀ってある
我々はるアイコン鯖民のちくわに対する溢れんばかりのリスペクトを感じさせられる 本殿の屋根に設置されたちくわは気品さえ漂わせる
ｷﾞｮｴｰ鳥
らこさんに手伝ってもらい3羽作った
口から卵を発射する機構がある ちくわは発射できない
自宅
緑豊かだがちくわはない ちくわは植物じゃない
ちくわエクスプレス
ちくわ色の路線、ちくわを走る鉄道、ちくわエクスプレス
役場前駅
始発駅 でかいけどちくわがない
ちくわ大明神前駅
ちくわ大明神の前に設置された駅
二本のちくわが織りなすちくわリズムが美しい、全てがちくわになってしまえばいい
ささみ温泉駅
大規模温泉 でかいがちくわはない
練馬駅
ちくわ型ホームが練馬という地に潤い、安らぎ、情緒をもたらしている
ちくわが一品あるだけでこうも影響を与えるのだ
雪見町駅
終点駅 巨大ちくわが雪見町の景観をぶち壊し、申し訳ないがこれもちくわのためである ちくわと調和しろ ちくわを作れ ちくわであれ
天海春香さんと会話したいシリーズ16
基本情報落ちた
作り直した
前々回ぐらいの記事で文章表現を増幅することで細かいニュアンスの変化に対応できるとかいうことを書いたが、色々とやり方が悪くて効果が出なかったのでそれを踏まえて作り直した
DB設計
単語に対して品詞データを全て保存しておくよりも、助詞かどうか、接続語かどうかだけ、と使う分だけ保存しておいて方がよい気がした 厳密な測定をしてないので効果はなんとも言えない
返答部分
https://github.com/sasamijp/Amami16/blob/master/roid/responder.rb
Aと言われたらBと返すという会話コーパスの集合があって、入力が与えられた時それがAである確率が最も高いものを選んでBを返すという基本的な部分は変えない
入力がAである確率を出すにあたって、単語を1単位として編集距離を出すのが一番強い気がした 例えば
["今日","の","ごはん"]と
["今日","の","うんこ"]
の編集距離は1である
しかしこれには弱点があって、例えば
["死ね"]と
["好き"]の編集距離が1である 意味が全然違うのに文章として近いと判定されてしまう
これを避けるため、助詞以外の品詞が最低1つ一致しない場合そのコーパスを除外する 残ったコーパスでそれぞれ入力との編集距離を算出する
効果
@whywaita いや、考えなくてもわかるよね？ 当たり前の事だよね？
— 天海春香 (@sa2mi) 2014, 11月 13
@sasamijp なんでそうなる
— 天海春香 (@sa2mi) 2014, 11月 12
@sasamijp ありがと！！
— 天海春香 (@sa2mi) 2014, 11月 12
