question about SEE

[asanjuan]

Sounds more like there is something wrong with your PVS implementation.

well, is quite probable . Maybe i have to re-write my search functions and try without reductions to see if there is something wrong. The search function, and specially PVS, is simple in concept, but has some tricks.
I can copy the search from another program.... but i don't want to be another copy-paster. I prefer to do it myself... Trying to be "creative", you know...

[Don]

Your routine, assuming it is correct, will give you some of the benefit of a full blown see routine. However it's a mistake to only include moves > 0, it should be all captures >= 0. Throw out moves that look like they are losing and keep the rest. Throwing out moves which might actually be positionally good (such as captures than neither win or lose) can actually slow your search down and hurt your programs positional play.

Equal and up-captures do not need to be tested to see if they are losing, only down-captures. So a fairly good algorithm for a lazy programmer like yourself is to throw out all down-captures if the piece being captured is defended by a pawn. If you want to get slightly fancier, you can also test for knight defenses in the case of a queen doing the capture. In either case you are being conservative and safe but missing some opportunities to prune more moves.

But full see is still going to be much better - it really makes the quies lean and mean which is what you want. Old style chess programs with full quies and no pruning spent most of their time in the quies search, but modern program that use see for pruning losing captures spend only a little time in quies.

You said your program was blowing up with deeper searches. Check your extension and your move ordering. Move ordering is super critical here so look for bugs. Most people do this in the main part of the search:

1. hash table move
2 .MVV_LVA (not losing) captures
3. killer A (not captures)
4. killer B (not captures)
5. losing captures in MVV_LVA order
6. rest of the moves sorted intelligently

Komodo puts the bad captures at the end of list but I think most programs do it like I show here. I found no benefit to ordering the non-capture moves according to see() and I think it's because the history heuristic trumps that, if the history says it's good and see says it bad, the history seems to be the correct one. Look at stockfish for the right way to do history (Komodo does it differently than SF, but the general principle is the same.)

So you have to get quies right and move ordering right or your program will never go anywhere (at least not very fast.) After that there are a million things that are tradeoffs (speed vs quality), but move ordering is not a tradeoff. Quies using see is technically a tradeoff but it's a clearly good one and I view it as a must have. You should think about eventually taking the time to implement it.

This is my first post in this forum, so dont' be cruel with me...
I have a -maybe quite simple- doubt about SEE.
I have always refused to implement a SEE routine. (you can say i'm lazy)
In my engine, I use some kind of SEE at "one-level", only recognizing if a move is a good capture or not. This is the pseudo-code:

Code: Select all

if captured_piece is undefended then return TRUE  
else if  val&#40;attacking_piece&#41; < val&#40;piece_captured&#41; then return TRUE 
else //houston, we have a problem 
if val&#40;attacking_piece&#41; > val&#40;piece_captured&#41; 
   && val&#40;attacking_piece&#41;  <= 
   val&#40;piece_captured&#41; + val&#40;minimum_defender&#41; then return true //because i want to search on this move

else return False 

and depending of what is returning this function i update the "expected" material gain or loss for that move (from a table with MVV-LVA values). At the end i look for the moves with an expected material win >0.
I also use this routine for move ordering in the main search.
This is working very well in my tests, but I see some kind of node explosion when searching at depths over 10 and so on.

I believe that changing my simple routine to a more sophisticated SEE could improve this node explosion, but i'm not sure. So here is my question:
¿has anybody proven that SEE _WILL FOR SURE_ reduce the amount of nodes visited?