TalkChess.com

I'm debugging a run time error in some new code and found a situation that isn't intuitive.

entering a node i apply the PV test... in this test example, alpha = 123 and beta is 124, so, bIsPV is false, indication we are not in the PV

entering the move loop, the first move available is made, bumping the MoveCount variable from 0 to 1 and then we reach the PVS code. I coded the PVS code to what I "thought" was the correct way to do it, so.... Now wait a minute. the bIsPV test says we aren't in the PV, but the logic for the PVS indicates that the first move should be search full width. Which is correct? Should the PVS code actually read... is the bIsPV test 100% accurate?

this is my simplfied code for PVS

and do you use the same method that I described to determine if (PVNode) is true?

I'm not sure I've seen this representation of PVS code.
I am referencing the "node type" page
https://chessprogramming.wikispaces.com ... s#PV-Nodes
so,
(1) so on deeper nodes, it appears they can never be PV NODES again, is that true?

MOBMAT wrote: ↑Sat Jun 09, 2018 12:30 am and do you use the same method that I described to determine if (PVNode) is true?

not the same code but equivalent

Code: Select all

if(PVnode) {
	if(moveNumber==1) { //The first child of a PV-node is a PV-node, so search wide
		val = -alphaBeta( -beta, -alpha );
	}
	else { // The further children are searched by a scout search as CUT-nodes, so search zero windowsw
		val = -alphaBeta( -alpha-1, -alpha);
		if( val > alpha && val < beta ) { // PVS re-search is done as PV-node, so search wide
			val = -alphaBet( -beta, -alpha );(2)
		}
	}
}
else {
	val = -alphaBeta( -alpha-1, -alpha ); //non PVNODES are cut-nodes, so search narrow (1)
}		  	

(1) so on deeper nodes, it appears they can never be PV NODES again, is that true?

if a deeper node result is not failing low it will make fail his father, and so on until a (2) fail and the tree is researched as PV node.

only the child of a PV can be PV, a child of CUT orALL nodes cannot be PV

If you don't re-search when the score of the null-window ('scout') search is >= beta, then there is no need to treat PV nodes different from others. Non-PV nodes then will never perform a re-search, as the only way for later moves to score > alpha automatically scores >= beta if the node had a null-window to start with.

Scores above beta when beta != alpha+1 can only occur in a fail-soft framework, though. An even there then will occur only very rarely; as alpha-beta search is based on not wasting time to prove the score is better than you need, it will indeed harly ever do so.

And here comes the stupid question : how to implement PVS if score is float and not int ?

xr_a_y wrote: ↑Sat Jun 09, 2018 4:04 pm And here comes the stupid question : how to implement PVS if score is float and not int ?

I don't know, I asked it to myself too.

fixed point alpha beta has some beautiful properties ( i.e. null windows -> beta= alpha+1 ), floating point is a little trickier, you have to be really careful with > >= != end so on

hgm wrote: ↑Sat Jun 09, 2018 4:00 pm If you don't re-search when the score of the null-window ('scout') search is >= beta, then there is no need to treat PV nodes different from others. Non-PV nodes then will never perform a re-search, as the only way for later moves to score > alpha automatically scores >= beta if the node had a null-window to start with.

Scores above beta when beta != alpha+1 can only occur in a fail-soft framework, though. An even there then will occur only very rarely; as alpha-beta search is based on not wasting time to prove the score is better than you need, it will indeed harly ever do so.

you are right, but I like to have a clear code that some year later i can still understand, anbd this implementation is a little verbose but clear

xr_a_y wrote: ↑Sat Jun 09, 2018 4:04 pm And here comes the stupid question : how to implement PVS if score is float and not int ?

This should be unrelated to PVS, you will have many places in your engine where you compare two scores. And here comes the stupid answer: just don't do it Use integer scores representing centipawns, 1/256 pawns, millipawns, 1/1024 pawns, whatever you like.

However, if you really insist ... Check out google-test, I once read that they have a nice implementation for floating point comparison.

TODO: make Weini use int instead of float ...