おまいら最強の将棋プログラムしてみろよ part7

1 ： ◆pOLJNwccDs ：2008/08/21(木) 14:38:37

できたらよろこんでやる。
前スレ
おまいら最強の将棋プログラムしてみろよ part6
http://pc11.2ch.net/test/read.cgi/tech/1175841191/

572 ：デフォルトの名無しさん：2009/10/22(木) 00:15:05

困難な点は、500msの予定が1秒かかった場合、呼び出した親は処理待ちになる点だな。
探索中に、終了予定時間を更新していき、
時間かかりそうな所は再び500ms程度ごとに分割すればいいかもしれない。

573 ：デフォルトの名無しさん：2009/10/22(木) 00:21:59

なるべく500msが小さい方が直列読みに近づくけど、
小さすぎるとスレッド生成コストでロスする。
αかβか(どっちかは忘れた)　カットが起きれば、
別スレッドは破棄して上ノードへ戻していい。
長い時間を計算したものを破棄すると無駄になるから、小さい方がいい。

574 ：デフォルトの名無しさん：2009/10/22(木) 11:26:00

残りの深さ、確率が少ない局面　= 短時間で探索が終了する局面で
いかに速く解を得るかという事だ。
想定するのは、通常探索、1CPUで5秒かかる局面くらいでいいと思う。
並列処理で何秒に縮められるか。

575 ：デフォルトの名無しさん：2009/10/22(木) 21:55:14

言いたいことはなんとなくわかるけど、国語力が弱すぎる

576 ：デフォルトの名無しさん：2009/10/22(木) 23:44:44

ようするに、末端を並列読みすればいいって事。末端の集まりが全体。
末端の探索速度が1/2に出来たら、
上位が並列でなくても、全体の速度も1/2になるだろう。
なるべく末端近くまで並列にしない方が無駄が無くせるけど
あまりに処理時間が短すぎると、スレッド生成コストが無駄になる。

577 ：デフォルトの名無しさん：2009/10/23(金) 00:31:29

それはわかってて
そこからどう工夫すればいいだろうかって話

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にした

ただそれだけだけどねｗ

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
俺はバカじゃない！俺はばｋじゃない！
ｊふぃおｈｄるおｂ

つかαβ探索は探索の時間計算量削減には寄与するが、得られる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
と＿)_)
ちょっと休憩｡