Discussions (not only) about Xboard/Winboard, Computer Chess and Chess Programming
by Sune Fischer » 06 May 2002, 14:26
by Richard Pijl » 06 May 2002, 14:36
Use separate indexes for keeping track of the depth and the number of plies played.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Usually this happens in winning positions (argh).
I could use a good suggestion on how to fix this.
Building the PV from the hash is a possibility, are there others?
Thanks,
-S.
by Uri Blass » 06 May 2002, 14:37
I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
by Sune Fischer » 06 May 2002, 14:43
That is good advice, I think I will do thatUse separate indexes for keeping track of the depth and the number of plies played.
When starting the search, I set ply=0, and increase ply with every move played, and decrease again on each takeback. This is also useful for other searchdepth dependent stuff like killer heuristic, depth dependent pruning etc.
When generating the pv from the hashtables you will have to overcome a lot of problems. You need to be really sure your hashtable implementation is correct and that all PV moves are in there and remain in there until you need them. If done correctly it does give a small speed increase though ...
Richard.
by Sune Fischer » 06 May 2002, 14:45
My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
by Richard Pijl » 06 May 2002, 14:58
It got me about 5% more nodes a second, but it also took me a considerable amount of time to get it right. Especially lower bounds hashentries with a move in it that were inherited from a previous search ruined things.I've tried removing the PV collection scheme, but I didn't really see any speedup, but of course anything that can be done at the root is *free*
by Uri Blass » 06 May 2002, 14:59
I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
by Sune Fischer » 06 May 2002, 15:01
I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
by Sune Fischer » 06 May 2002, 15:07
Probably, but I was just considering the nps count, and I could notice any difference at all. I think maybe a more well tuned search will produce more pv moves so it becomes more important. At my stage, it isn't a problem and for the moment I just like having an accurate PV for debugging reasonsIt got me about 5% more nodes a second, but it also took me a considerable amount of time to get it right. Especially lower bounds hashentries with a move in it that were inherited from a previous search ruined things.I've tried removing the PV collection scheme, but I didn't really see any speedup, but of course anything that can be done at the root is *free*
Are you sure that when you tried this you didn't break moveordering?
Richard.
by Richard Pijl » 06 May 2002, 15:24
I still have both methods in my code, but activate only one of them with a compile-time flag. I've done the same with many other mechanisms as it is easier to debug a new mechanism if other things (pruning, nullmove etc) are turned off. And I'm still not 100% confident my pv-tracking from the hashtable is correct ...Probably, but I was just considering the nps count, and I could notice any difference at all. I think maybe a more well tuned search will produce more pv moves so it becomes more important. At my stage, it isn't a problem and for the moment I just like having an accurate PV for debugging reasonsIt got me about 5% more nodes a second, but it also took me a considerable amount of time to get it right. Especially lower bounds hashentries with a move in it that were inherited from a previous search ruined things.I've tried removing the PV collection scheme, but I didn't really see any speedup, but of course anything that can be done at the root is *free*
Are you sure that when you tried this you didn't break moveordering?
Richard.
-S.
by Uri Blass » 06 May 2002, 15:24
I did not say that my defintions are more logical but depth is always used in the meaning of distance from the root not only in tscp but also in bruce moreland pages.I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
-S.
by Sune Fischer » 06 May 2002, 15:31
That is how I use depth too, I believe you mean distance to end search?I did not say that my defintions are more logical but depth is always used in the meaning of distance from the root not only in tscp but also in bruce moreland pages.I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
-S.
Uri
by Richard Pijl » 06 May 2002, 15:33
You probably meant to say 'depth is always used in the meaning of remaining depth to search'I did not say that my defintions are more logical but depth is always used in the meaning of distance from the root not only in tscp but also in bruce moreland pages.I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
-S.
Uri
by Peter Fendrich » 06 May 2002, 15:39
I'm using 2 variables: depth and ply, where depth is the remaining depth and ply is just the ply counted from the root. Extensions are added to the depth but means no changes in the ply variable. I think you will need both when the program gets more compicated.I did not say that my defintions are more logical but depth is always used in the meaning of distance from the root not only in tscp but also in bruce moreland pages.I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
-S.
Uri
by Sune Fischer » 06 May 2002, 15:40
I haven't tried it, but is it that hard?I still have both methods in my code, but activate only one of them with a compile-time flag. I've done the same with many other mechanisms as it is easier to debug a new mechanism if other things (pruning, nullmove etc) are turned off. And I'm still not 100% confident my pv-tracking from the hashtable is correct ...Probably, but I was just considering the nps count, and I could notice any difference at all. I think maybe a more well tuned search will produce more pv moves so it becomes more important. At my stage, it isn't a problem and for the moment I just like having an accurate PV for debugging reasonsIt got me about 5% more nodes a second, but it also took me a considerable amount of time to get it right. Especially lower bounds hashentries with a move in it that were inherited from a previous search ruined things.I've tried removing the PV collection scheme, but I didn't really see any speedup, but of course anything that can be done at the root is *free*
Are you sure that when you tried this you didn't break moveordering?
Richard.
-S.
Richard.
by Uri Blass » 06 May 2002, 15:42
YesYou probably meant to say 'depth is always used in the meaning of remaining depth to search'I did not say that my defintions are more logical but depth is always used in the meaning of distance from the root not only in tscp but also in bruce moreland pages.I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
-S.
Uri
What Sune does here is probably keeping depth and extensions separate. That may be useful. I guess he calculates remaining searchdepth from depth+extensions in each node. TSCP's method doesn't give information about extensions given in previous plies (unless you keep it in a separate parameter).
I can imagine that keeping the extended plies in a separate counter can have its use in determining the amount the search is extended the next time ...
by Uri Blass » 06 May 2002, 15:47
I use both and need both.I'm using 2 variables: depth and ply, where depth is the remaining depth and ply is just the ply counted from the root. Extensions are added to the depth but means no changes in the ply variable. I think you will need both when the program gets more compicated.I did not say that my defintions are more logical but depth is always used in the meaning of distance from the root not only in tscp but also in bruce moreland pages.I do not see why yours is more logical than mine.I do not see why is it more logical.My counter is inversed.I do not understand how the depth can go below 0.I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Extensions only increase the remaining depth.
Uri
Depth means distance from root, more logical that way IMO
-S.
I have a variable with the name ply that gives the distance from the root in plies and another variable with the name depth that gives the remaining depth to search.
tscp is using these variables in the same way.
Uri
-S.
Uri
For example, in Terra each ply++ correspondes to deph += 64. When adding extensions I can add fractions of one ply to the depth variable.
Peter
by Sune Fischer » 06 May 2002, 15:49
Actually I just used one depth counter, a local variable describing the depth from root, it can go negative as I fiddle with the extensions simply by subtracting from it. It does explains a lot of the weird PVs I've seen lately.What Sune does here is probably keeping depth and extensions separate. That may be useful. I guess he calculates remaining searchdepth from depth+extensions in each node. TSCP's method doesn't give information about extensions given in previous plies (unless you keep it in a separate parameter).
I can imagine that keeping the extended plies in a separate counter can have its use in determining the amount the search is extended the next time ...
Well, this whole discussion smells like little-endian vs. big-endian to me
Richard.
by Richard Pijl » 06 May 2002, 15:59
Well, sometimes an entry is not inserted in the hashtable because the existing entry is more valuable (higher searchdepth, more nodes), for instance from a previous search, or closer to the rootnode. If a move will be part of a PV you need to force insertion, but you cannot prevent that it is overwritten later by a non-pv node that is considered more valuable at that time. When having a separate pv-table you can rely on the pv to be present, with generating the PV from the hashtable you cannot.I haven't tried it, but is it that hard?I still have both methods in my code, but activate only one of them with a compile-time flag. I've done the same with many other mechanisms as it is easier to debug a new mechanism if other things (pruning, nullmove etc) are turned off. And I'm still not 100% confident my pv-tracking from the hashtable is correct ...Probably, but I was just considering the nps count, and I could notice any difference at all. I think maybe a more well tuned search will produce more pv moves so it becomes more important. At my stage, it isn't a problem and for the moment I just like having an accurate PV for debugging reasonsIt got me about 5% more nodes a second, but it also took me a considerable amount of time to get it right. Especially lower bounds hashentries with a move in it that were inherited from a previous search ruined things.I've tried removing the PV collection scheme, but I didn't really see any speedup, but of course anything that can be done at the root is *free*
Are you sure that when you tried this you didn't break moveordering?
Richard.
-S.
Richard.
You follow the hashmove from entry to entry, make the move and find the next entry until your probe fails?
If its a fail-low node there is no hashmove, and a fail-high node you can tell by the flag?
-S.
by Miguel A. Ballicora » 06 May 2002, 19:21
I found a bug in frenzee.
It happens in about 1/20 games, and it will cause a crash.
The error is in collecting the PV.
When extending the search the depth might temporarely go below 0, and if at that position there is a PV move, then pv[depth].move=themove will cause a crash
Usually this happens in winning positions (argh).
I could use a good suggestion on how to fix this.
Building the PV from the hash is a possibility, are there others?
Thanks,
-S.
Return to Archive (Old Parsimony Forum)
Users browsing this forum: No registered users and 14 guests