おまいら最強の将棋プログラムしてみろよ part7
- 1 : ◆pOLJNwccDs :2008/08/21(木) 14:38:37
- できたらよろこんでやる。
前スレ
おまいら最強の将棋プログラムしてみろよ part6
http://pc11.2ch.net/test/read.cgi/tech/1175841191/
- 578 :pgBqBmlfItEeX:2009/10/23(金) 00:41:43
- But she has been more recently stressed out because of work, and rightfully so. ,
- 579 :まともに動いてない:2009/10/23(金) 02:54:38
- http://wdoor.c.u-tokyo.ac.jp/
死んでる?
- 580 :デフォルトの名無しさん:2009/10/23(金) 03:11:18
- 囲碁のモンテカルロ碁は3段が限界みたいだな
囲碁ソフトはこの三、四年間ほとんど棋力が上がってない
- 581 :デフォルトの名無しさん:2009/10/23(金) 03:55:53
- 寝言は寝て言え
- 582 :デフォルトの名無しさん:2009/10/23(金) 04:06:32
- いや、実際に販売している囲碁ソフトは全然進歩してない
- 583 :デフォルトの名無しさん:2009/10/23(金) 04:57:03
- なにこの情弱
- 584 :デフォルトの名無しさん:2009/10/23(金) 05:14:32
- 当然とはいえ、棋力相応の読みしか入っていないと感じる。
今の延長線上じゃKGS2〜3dくらいで頭打ちじゃないのかな。
zenはd持ちだけど一手15秒なんで半分インチキだし。
- 585 :デフォルトの名無しさん:2009/10/23(金) 06:48:18
- 囲碁板でやれよ
- 586 :tgiyzLCYNBgN:2009/10/23(金) 22:12:39
- Yet, these same opponents would trust gov- ernment to provide the coinage. ,
- 587 :デフォルトの名無しさん:2009/10/24(土) 00:40:58
- futility cutってprobcutの簡易版ですよね
- 588 :デフォルトの名無しさん:2009/10/24(土) 02:34:08
- >>587
Lazy Evaluation(評価関数内で駒割など差分計算可能な処理だけを
先にやり、重い処理をサボれそうだったらサボる)の過激版っぽい。
ttp://chessprogramming.wikispaces.com/Lazy+Evaluation
- 589 :デフォルトの名無しさん:2009/10/24(土) 09:31:49
- probcut、Lazy Evaluation、どっちの側面もあるよ
- 590 :デフォルトの名無しさん:2009/10/25(日) 11:45:12
- >>589
Lazy Evaluation
という概念で考えたことはなかったので勉強になったよ
言われてみればその通りだな。
ProbCutは予想が甘いとリスクがある
futilityCutは評価関数の一部と考えればいいな
- 591 :デフォルトの名無しさん:2009/10/25(日) 12:08:10
- Futility Cutだってマージンが甘いとリスクがある
Probcutだって人間の裁量で調整できるんだから結局同じ事
- 592 :デフォルトの名無しさん:2009/10/25(日) 21:21:39
- 初心者なのでようわからんのですが
FPGAによる局面生成ってどこらへんにメリットがあるの?
局面だけポンと生成されても評価値計算のためには結局CPUが9x9=81マス読まなくてはならなくて
差分計算も糞も無くなる木がする、
一方FPGAに評価値計算までやらせる話になると、
評価ロジックの自由度は大幅に増すかもしれないけど(H/Wの並列性を生かせば差分計算に依存する必要が薄れる)、
演算精度のために支払うLE数が壁になりそうな
(1局面の指し手数が平均80として、6手先で0.26兆局面あってそいつらに有意な順序づけを行うには
浮動小数点でも仮数部40 bitぐらい要ることは論をまたない)
- 593 :592:2009/10/25(日) 21:27:10
- >浮動小数点でも仮数部40 bit
なおこれは学習を安全に収束させる前提の話
ゲーム木全体をAND/OR木的に読み切って必勝局面を与えるだけなら1 bitでいいだろうけど
- 594 :デフォルトの名無しさん:2009/10/25(日) 22:10:41
- 速い
そんだけ
- 595 :デフォルトの名無しさん:2009/10/25(日) 23:39:41
- >>592
試合のときに浮動小数点なんか使わないぞ。
学習はC++でエンジン書いてやればいいだけ。
FPGAなら少なくとも手生成がマスや駒ごとに並列に行える。
位置評価も並列に行える。
探索自体は再帰だから結局はコアの数だけの並列になるけどな
- 596 :デフォルトの名無しさん:2009/10/26(月) 06:34:24
- 今までにない将棋を作ってみた
将棋のGUIを3Dにした
ただそれだけだけどねw
- 597 :デフォルトの名無しさん:2009/10/26(月) 07:00:36
- 残念、「3D将棋」でググれ
- 598 :デフォルトの名無しさん:2009/10/26(月) 13:31:16
- >>592
> 浮動小数点でも仮数部40 bitぐらい要ることは論をまたない)
Bonanzaですら16bitしか使ってないけどな。40bitって何を根拠に言ってるんだ?
またプログラムが一行も書けない妄想バカのおでましか。
- 599 :デフォルトの名無しさん:2009/10/27(火) 02:46:55
- 昼間のヒキコモリが言ってても
- 600 :デフォルトの名無しさん:2009/10/27(火) 10:49:24
- >>599
プログラムが一行も書けないことがバレると人を引きこもり扱いか。とんでもないクズだな。
- 601 :デフォルトの名無しさん:2009/10/27(火) 10:55:16
- >>599
夜中のヒキコモリが言ってても
- 602 :デフォルトの名無しさん:2009/10/27(火) 22:53:34
- >592さん
6手先で0.26兆局面あって、それら全てを順序づけるためには
40bitも必要になるのは認めるとしても、それらの局面すべてに
対してことごとく異なる評価値を与える必要は無いのでは?
現状、任意の局面に対してそんなに細かく厳密な評価が出来るとは思えません。
つまり、幾つかの局面がグループにまとめられて同じ評価値を
持ったとしても大した問題では無いはず。
実際、数手先まで読むと同じ局面が異なる手順で何回も出てきたりするし、
16bit整数(-32767 から +32767)で表せる値以上に細かく評価値を与える
意味と言うか、実用性が私には良く分かりません。
- 603 :デフォルトの名無しさん:2009/10/28(水) 00:08:37
- α-β法くらい勉強すればいいのにね
- 604 :デフォルトの名無しさん:2009/10/28(水) 23:03:09
- 性能評価のため、共通のフレームワークでアルゴリズムの研究するか。
ボード、評価関数は同一にする。
- 605 :592:2009/10/29(木) 00:56:22
- >>602
>それらの局面すべてに
>対してことごとく異なる評価値を与える必要は無いのでは?
逆に、同じでいいというのもあまり根拠の無い話に思える感じ
>現状、任意の局面に対してそんなに細かく厳密な評価が出来るとは思えません。
確かに現状壁が3つぐらいある(と思う)
(1) 学習パターン自体のノイズ
(2) 学習時間の壁 (パターン数に対して指数オーダー)
(3) 次元の壁 (評価因子を増やすと球面集中現象でヤられる)
これらの壁がほどよく立ちふさがってくれているから整数演算で通用しているのだと思う
>実際、数手先まで読むと同じ局面が異なる手順で何回も出てきたりするし、
それはそうだけども、サイクル手順を除去しても6手先までの指し手が数十万のオーダーまで降りるとは思えない感じ
一方評価関数の高精度化による指し手の最適化とは、その中から常にα最大かβ最小のものを選ばねばならないから
16 bit整数では足りない、というプログラム前の皮算用
- 606 :デフォルトの名無しさん:2009/10/29(木) 01:23:42
- 違う局面で同じ評価値の場合はあってもいいに決まってんだろ
- 607 :デフォルトの名無しさん:2009/10/29(木) 01:27:01
- >>602
一つ反応し忘れたス、
>つまり、幾つかの局面がグループにまとめられて同じ評価値を
>持ったとしても大した問題では無いはず。
評価関数の高精度化による指し手の最適化では(非常に単純化して言うと)指し手は評価関数の値のみに依存するから、
局面をいくつかのグループにまとめて問題ないかどうか決めるのは評価関数自体なんであって、
上記主張は、評価関数の精度が低くていいことの根拠としては循環論理めいて聞こえる
もちろん実際は序盤・中盤・終盤その他のモード分けをプログラマがやってるから評価関数依存一辺倒ではないのは承知してる
つもりだが、最強コンピューター棋士はその手のフレーム問題も適当に解決する強いAIたるべき、
- 608 :デフォルトの名無しさん:2009/10/29(木) 07:34:10
- いまからつくりはじめたぞ。共同フレームワーク開発するぜ。
- 609 :デフォルトの名無しさん:2009/10/29(木) 12:26:38
- さいはつめい?
- 610 :デフォルトの名無しさん:2009/10/29(木) 20:32:50
- >>602
何故598でとっくに結論が出ているのにそんなに長々と意味の無い文章を書くんだ。
- 611 :デフォルトの名無しさん:2009/10/29(木) 20:34:32
- >>605
>>対してことごとく異なる評価値を与える必要は無いのでは?
> 逆に、同じでいいというのもあまり根拠の無い話に思える感じ
あんた(592=605)は、αβ法すら自分で書けない妄想バカだな
- 612 :デフォルトの名無しさん:2009/10/30(金) 06:21:21
- あたりの生成は、各ますにどのコマから利きがあるかを記録しておくんですか。
- 613 :612:2009/10/30(金) 06:29:24
- どのコマの利きかを記録するか、2手前の位置を調べるかと思います。
詰将棋に限定したら、前者の方が速いですか。
- 614 :デフォルトの名無しさん:2009/11/01(日) 04:19:15
- Wikipediaで将棋プログラム関連技術の記事を充実させません?
- 615 :デフォルトの名無しさん:2009/11/01(日) 04:25:40
- 何の項目?
- 616 :デフォルトの名無しさん:2009/11/01(日) 22:47:22
- >>611
俺はバカじゃない!俺はばkじゃない!
jふぃおhdるおb
つかαβ探索は探索の時間計算量削減には寄与するが、得られるmax{min{...}}の値自体は完全探索と一致するのだから
αβ探索を作れること(及びαβ探索を採択すること)は評価関数の精度が低くていいことを担保しない
評価関数の計算精度の十分条件とは全く関係ない話
- 617 :デフォルトの名無しさん:2009/11/02(月) 00:52:14
- 現時点では評価関数の精度が低いから現在のような広い値域が必要なわけで
今後精度が高くなればなるほど値域は狭くていい
まあ別に広くしてもいいけどね
無駄なだけで
- 618 :デフォルトの名無しさん:2009/11/02(月) 09:43:43
- 完璧な評価関数なら-1、0、+1ですな。
- 619 :デフォルトの名無しさん:2009/11/02(月) 14:05:21
- 将棋に引き分けってあるんだっけ?
- 620 :デフォルトの名無しさん:2009/11/02(月) 14:16:06
- 千日手、持将棋、同時反則
- 621 :デフォルトの名無しさん:2009/11/06(金) 18:37:55
- >>558
`∧_∧
(´・ω・)
( つ旦O
と_)_)
ちょっと休憩。
- 622 :デフォルトの名無しさん:2009/11/10(火) 22:49:28
- 水平線効果は静止探索で対処しているものがいくつかあるが、
静止探索は遅いので困る。
もっと良い水平線効果はないのだろうか?
しかし、もし静止探索以外で水平線効果を対処できたとしても
静止探索には水平線効果以外のメリットがあるのかな?
良く分からないが、とりあえず静止探索以外の水平線効果対処方法を考えてみると
- 623 :デフォルトの名無しさん:2009/11/12(木) 00:40:26
- >>621
∧ ∧ 彡
ミ ( ^ω^ )っ 彡
O ノ タタタタ…
ミ| (_) 彡
ミ し´ 彡
- 624 :デフォルトの名無しさん:2009/11/14(土) 11:10:53
- >>618
二人零和有限確定完全情報ゲームである以上2値でおk3値もイラン、
というのは次局面のどれが神の手筋に乗ってるか否か、それだけわかればいいから
仮に神の手筋の分岐する先に引き分けの局面があっても2値でいいことは変わらない(もしそうなら、
引き分けは保証されるが相手がミスしない限り勝てないこともあるゲームだったと認める他ない)
もっとも、先手がどうがんばっても神の手筋が後手の手番から始まってしまうゲームにおいて
初手からしばらくは先手後手ともに神の手筋に乗っていないから、どの手がベストかを確率的に判断
する他ないというのはある(が、そのこと自体は3値が必要十分とする根拠にはならない)
- 625 :デフォルトの名無しさん:2009/11/14(土) 14:02:15
- αβ法もわかってないゴミは黙ってな
- 626 :デフォルトの名無しさん:2009/11/15(日) 00:05:10
- 神の手筋を知っている前提で解くやり方はαβ探索というよりむしろdf-pn探索(証明木の取得)の領分
残念ながら将棋は完全な証明木を現実的手段で取得したり記憶できたりするほど単純でないから
(何しろ局面数が10^220もある)
αβ探索(と評価関数のヒューリスティックな作り込み or 統計的最適化の組み合わせ)が幅を効かしてゐるのだけどね
故に漏れ涙目
統計的手法を駆使して勝利の蓋然性を積み重ねていったらぴったり敗着の穴がふさがれちゃった
(それより優れた手筋を示す解法は存在しない)という可能性もあるっていやーあるが、
- 627 :デフォルトの名無しさん:2009/11/15(日) 00:19:21
- そいつは無限の猿定理
163 KB
[ 2ちゃんねる 3億PV/日をささえる レンタルサーバー \877/2TB/100Mbps]
■ おすすめ2ちゃんねる 開発中。。。 by FOX ★
このスレを見ている人はこんなスレも見ています。(ver 0.20)
▲コンピュータ将棋スレッド52▽ [将棋・チェス]
激指総合スレッド3 [将棋・チェス]
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 05.0.7.8 2008/11/13 アクチョン仮面 ★
FOX ★ DSO(Dynamic Shared Object)