Fermin Serrano wrote:1) Some times my engine play a good game and then don't make any progress. I mean, it takes adventage of the 50 move rule to play something only at 45, 46 or so move. Is it there any safe way to tell the engine to do something without the need of play a lot of useless moves?
Some programs scale down the scores when they get close to the 50 move limit, in order to avoid the problem you describe. This seems to make sense, but I have never been able to make it work well.
2) With only alpha-beta and null techniques, my engine spend near 70% time in eval function. is that normal?
I think it is probably a bit above average, but it is not very unusual. How much time an engine spends in the evaluation function depends on how much knowledge it contains, and on whether the evaluation function is used at internal nodes.
3) I have made an easy move detection routine. If score of move no.1 - MARGIN > score of move no.2, and current iterative depth >=5 then I consider the move is an easy one and play inmediacy, saving time. Usually MARGIN is around 180. Do you think this is a safe method?
How do you know that move number 1 is 180 points better than the others? If you use something similar to the alpha-beta algorithm, all you know is that the first move is
better than the rest; you can't say by how much.
My own method for easy move detection works like this:
At the first iteration, I search all moves with an open window. If one move is at least two pawns better than all the rest, that move is a
candidate to be an easy move. If there is an easy move candidate, this candidate has remained the best move for at least eight iterations, at least 85% of the total time has been spent searching this move, and at least 1/16 of the allocated thinking time for this move has been spent, the move is played.
A candidate easy move is considered "very easy" if at least 98% of the time has been spent searching this move. Very easy moves are played after 1/32 of the allocated thinking time.
4) For alpha-beta with null move, my engine is calculating the same number of nodos than qnodes. Is that normal?
I'm not sure. It probably depends on where you increment your node counters, on the shape of your tree, and on the phase of the game.
5) Do you think a strong eval function with tactical detection feautres can replace the tactical power of the search?
To some extent they can, but at least on modern computers, it seems that relying on the search for tactics is usually faster and safer (and much easier for the programmer, of course).
6) I dont know if it is a questions of compilers, but I have experienced problems using "unsigned int" in differents compilers. Have you experienced problem with this?
As far as I know, I haven't experienced such problems, but I very rarely use unsigned ints.
7) In quiesce search function, I generate all moves if in check, but I dont know if that is sound. I.e., in TCSP only caps are generated, even in check. What is right? why?
Not generating check evasions in the quiescence search sounds extremely risky to me, and because the nodes with checks are quite rare, you don't save a lot of time by not searching check evasions. I guess TSCP ignores check evasions in the quiescence search just to make the program smaller and simpler.
8) How many consecutive extensions do you allow in a search? Must I limit them?
I have no restrictions on them, except that I never extend a move by more than one ply.
9) What is LMR and how it works?
An old selective search technique, which has become popular again in recent years. See the link in Pedro's post for details about how it works.
Tord