Colin wrote:Thanks, I heard of fail-soft before, but never looked into it.
Looking at this code... http://www.brucemo.com/compchess/progra ... shing.htm?
It can be seen alpha/beta is stored, I don't understand C/C++ code properly yet, so I'll have to learn it before I can make proper sense out of the record/probe functions given.
Is this pseudocode good to use? And I guess I need to also play the hash move obtained from the probe before I generate/play the other moves, but it doesn't say this in the code.
Bruce is using fail-hard, I think this won't work well with a null window.
Also, if playing hash-move first, I may end up playing it again since the move generator will find it if theres no cut off and it ends up generating and playing all the moves.... so is it best to avoid replaying the hash move?
Thanks
You probe the hash table first because you can have a usable exact score or a cutoff.
Then you generate your moves, but to play the hash move first you want your sort fucntion to give it a high score.
HJ.
I use fail-hard myself, and it works well with null-window (PVS) searches.
Searching the hash move twice is probably going to be almost free if you have a reasonable hash implementation. However, I take pains in crafty to avoid doing this on the general principle that I don't want to do anything twice.
bob wrote:THe way I update scores and bounds causes the same thing. I never spend/waste time searching for mates that are outside the window. Of course there is always wasted effort in a depth-first approach, but so long as the bounds are properly maintained, the longer-than-desired (or shorter-than-desired if you are losing) mates end up outside the A-B window and are not considered.
You might be amazed how many 2700+ engines do not handle this well. Several of my opponents at WCCC 2007 needed more than a minute to play the mate-in-one move...
I am not sure how you could prune branches leading to a shorter-than desired mate if you are losing. This seems to require a crystal ball.
bob wrote:Searching the hash move twice is probably going to be almost free if you have a reasonable hash implementation. However, I take pains in crafty to avoid doing this on the general principle that I don't want to do anything twice.
In uMax I simply search the hash move twice (to save the characters needed to remember and suppress it). Despite the shaky hash implemetation (always replace, so entries can get lost easily) it hardly seems to hurt. The second one is still almost always a hash hit.
I even retained this strategy in my currently smallest (rather than best Elo/size ratio) version, uMax 1.6, where I deleted the hash code entirely. One would expect that to really hurt, as a second instance of the best move is the most difficult to refute of all moves (even with best play it scores exactly equal). But it still plays a quite reasonable game, not that much weaker than uMax 4.0 (which does have the hash table). Except when it comes to end-games of course, then it plays like an idiot.
bob wrote:THe way I update scores and bounds causes the same thing. I never spend/waste time searching for mates that are outside the window. Of course there is always wasted effort in a depth-first approach, but so long as the bounds are properly maintained, the longer-than-desired (or shorter-than-desired if you are losing) mates end up outside the A-B window and are not considered.
You might be amazed how many 2700+ engines do not handle this well. Several of my opponents at WCCC 2007 needed more than a minute to play the mate-in-one move...
I am not sure how you could prune branches leading to a shorter-than desired mate if you are losing. This seems to require a crystal ball.
that's not a hashing issue. that's simply a poor decision on when to stop trying to find a shorter mate. I use the old mate in N requires 2*N-1 iterations at an absolute max and stop there.
hgm wrote:But it still plays a quite reasonable game, not that much weaker than uMax 4.0 (which does have the hash table). Except when it comes to end-games of course, then it plays like an idiot.
Or when a sub-promotion is involved SCNR. I wonder if uMax 4.8 would do the same (see other thread).
bob wrote:that's not a hashing issue. that's simply a poor decision on when to stop trying to find a shorter mate. I use the old mate in N requires 2*N-1 iterations at an absolute max and stop there.
I suppose you refer to a limit on the ID (or IID) iterations.
But even someone wouldn't have that limit, I just don't see how you could burn 1 min on a tree that has just a couple of nodes. The iterations would take less than a microsecond, and your program would crash due to stack overflow in seconds. Unless there was some hard upper limit to the depth (like 100, or 1000 ply), in which case you would hit it in a fraction of a second.
If they are not searching in some branches past the already proven mate, what could they possibly spend that time on???
bob wrote:that's not a hashing issue. that's simply a poor decision on when to stop trying to find a shorter mate. I use the old mate in N requires 2*N-1 iterations at an absolute max and stop there.
I suppose you refer to a limit on the ID (or IID) iterations.
But even someone wouldn't have that limit, I just don't see how you could burn 1 min on a tree that has just a couple of nodes. The iterations would take less than a microsecond, and your program would crash due to stack overflow in seconds. Unless there was some hard upper limit to the depth (like 100, or 1000 ply), in which case you would hit it in a fraction of a second.
If they are not searching in some branches past the already proven mate, what could they possibly spend that time on???
they don't go by that quickly... And the non-mate branches get deeper and deeper...
bob wrote:that's not a hashing issue. that's simply a poor decision on when to stop trying to find a shorter mate. I use the old mate in N requires 2*N-1 iterations at an absolute max and stop there.
I suppose you refer to a limit on the ID (or IID) iterations.
But even someone wouldn't have that limit, I just don't see how you could burn 1 min on a tree that has just a couple of nodes. The iterations would take less than a microsecond, and your program would crash due to stack overflow in seconds. Unless there was some hard upper limit to the depth (like 100, or 1000 ply), in which case you would hit it in a fraction of a second.
If they are not searching in some branches past the already proven mate, what could they possibly spend that time on???
they don't go by that quickly... And the non-mate branches get deeper and deeper...
Then I don't understand anymore what we are talking about.
I thought the whole point was that the non-mating branches never could get any deeper than N-2 ply, when there is a mate-in-N. At least, that was my point.
Come to think of it, I already don't understand your remark "that's not a hashing issue". Of course it is not a hashing issue, nothing is ever a hashing issue. Hashing is transparant, just a trick to reproduce a search result at lower cost than redoing the search. But the results are the same. So why mention the obvious? I must be missing something...
bob wrote:that's not a hashing issue. that's simply a poor decision on when to stop trying to find a shorter mate. I use the old mate in N requires 2*N-1 iterations at an absolute max and stop there.
I suppose you refer to a limit on the ID (or IID) iterations.
But even someone wouldn't have that limit, I just don't see how you could burn 1 min on a tree that has just a couple of nodes. The iterations would take less than a microsecond, and your program would crash due to stack overflow in seconds. Unless there was some hard upper limit to the depth (like 100, or 1000 ply), in which case you would hit it in a fraction of a second.
If they are not searching in some branches past the already proven mate, what could they possibly spend that time on???
The only possible reason except what you say is in case that it takes significant time to the interface to print the main line in every iteration
Suppose that the interface use only 0.03 seconds for printing the main line
and suppose that the engine print the main line twice(one time when it finds it and one time in the end of the iteration).
If the engine get depth 1000 then it can spend 0.03*2000 seconds=60 seconds.
I guess that this is not the reason and the reason is simply not handling mate scores correctly like you say.
SCNR. I wonder if uMax 4.8 would do the same (see other thread).