|
Main
Date: 16 Aug 2006 20:31:29
From:
Subject: my wrong understanding for negamax with depth=1
|
Consider the following game tree with depth 1. The bottom most is the result from eval (white's score - black's score) (max) /
|
|
|
Date: 17 Aug 2006 22:51:52
From:
Subject: Re: my wrong understanding for negamax with depth=1
|
Simon Krahnke wrote: > * <[email protected]> (05:31) schrieb: > > > or do i need to flip the sign of the score re-inside the eval function? > > > > eval() > > { > > if(one side turned to move) > > white's score - black's score > > else > > black's score - white's score > > } > > Yes. > > mfg, simon .... l If there any technique, to eliminate the need to flip the sign of the score in eval function? At the same time, still perserve the usage of recuirsive version of negamax, or even recuirsive version of alpha-beta? Thanks
|
| |
Date: 18 Aug 2006 13:45:24
From: Anders Thulin
Subject: Re: my wrong understanding for negamax with depth=1
|
[email protected] wrote: > If there any technique, to eliminate the need to flip the sign of the > score in eval function? At the same time, still perserve the usage of > recuirsive version of negamax, or even recuirsive version of > alpha-beta? Mu. There are one or two rather esoteric techniques that may help you realise that it doesn't matter. Profile your move generation/retraction code. Compare time and complexity. I stringly ssu -- Anders Thulin ath*algonet.se http://www.algonet.se/~ath
|
| |
Date: 18 Aug 2006 11:48:36
From: Dr A. N. Walker
Subject: Re: my wrong understanding for negamax with depth=1
|
In article <[email protected] >, <[email protected] > wrote: >If there any technique, to eliminate the need to flip the sign of the >score in eval function? At the same time, still perserve the usage of >recuirsive version of negamax, or even recuirsive version of >alpha-beta? Thanks You have a really fundamental decision to make at the start of your chess programming career. It doesn't much matter which way you decide, but once you've decided you must stick to it, or you will get mightily confused. You must either: (a) Do all evaluations from the point of view of the player to move. In this case, a dynamic evaluation is always the maximum of the negatives of the child evaluations, so your negamax/alpha-beta code is always the same and is simpler, but the static evaluation has to "know" who is to move. Or (b) Do all evaluations from [eg] White's point of view. In this case, a dynamic evaluation is either the max [White to move] or the min [Black to move] of the children, so your negamax/min/alpha-beta code needs two versions, but the static evaluation is simpler. Whichever you choose, you finish up with an annoying number of places in your code where it says "if white_to_move then ...", and you wish you'd done it the other way, but that's a programmer's version of the fact that the other superket checkouts all run faster than yours. -- Andy Walker, School of MathSci., Univ. of Nott'm, UK. [email protected]
|
|
Date: 17 Aug 2006 08:39:29
From: Simon Krahnke
Subject: Re: my wrong understanding for negamax with depth=1
|
* <[email protected] > (05:31) schrieb: > or do i need to flip the sign of the score re-inside the eval function? > > eval() > { > if(one side turned to move) > white's score - black's score > else > black's score - white's score > } Yes. mfg, simon .... l
|
| |
Date: 18 Aug 2006 18:55:50
From: Simon Krahnke
Subject: Re: my wrong understanding for negamax with depth=1
|
* <[email protected] > (07:51) schrieb: > If there any technique, to eliminate the need to flip the sign of the > score in eval function? At the same time, still perserve the usage of > recuirsive version of negamax, or even recuirsive version of > alpha-beta? Thanks Negamax ist a reformulation of MiniMax, that uses only one recursive function instead of two, but always flips the signs to keep the values right for the side to move. You can do alpha-beta with MiniMax too, max-nodes maximize alpha, min-nodes minimize beta. Here all the values are from white's pov. But if you want to use the negamax scheme, which is easier to implement, you have to make sure all scores are always for the side to move of currently examined node. So you will have to do that in eval too. mfg, simon .... l
|
|