More novice questions....

[Kempelen]

I am sorry, but I have been posting a lot of beggining questions, so hinder the normal forum activity....

I am near releasing my first engine version. During progamming, there appear more questions:

1) Supose I have two variants that arrives to the same posicion and same evaluation, where there is a move in bethween of difference.

V1: W1, B1, W2, B2
v2: W1, B3, W2, B2

(B1, B3 and B2 move the same piece)

These two lead to the same evaluation, so my engine pick one..... but what about if white not play W2 move??, then one of the variante could be better than the other, because the move in betheen lead to a better evaluation. Is there any way to know what's the better path, even if the two lead two same evaluation? I susspect engines pick one in accordance with move ordering and not what is better.

2) I suspect the 1) issue can be a problem too for hash tables. How two identical possitions can store the different eval resulting of the path choosen?

2) Are there books to buy about computer chess programming? It would be a good idea to make one by top people here

3) It is safe to make two or more null moves in the same path? (of course, avoiding two in a row) Must I do it only at a certain depth (i.e. >=3)

4) How many extensions it is safe to allow in the path? I am ussing two for depth <= 8 and if make more the search tends to exploit. Is there any good way to implement this?

5) Supposing ordering in root is OK. What about if after 7 or 8 iterate depth we search the last 1/3 of moves with a depth -1 with respect at the first ones in the move order? it looks to me a good way of save time. (this is a reduction, and feel it could be done in any node in the tree if the conditions match)

6) I am not sure about draw rules for insufficient material. I have read that some national federations consider K+minot piece vs King a theorical draw, and others don't, so you must play until 50 move rule or draw agreement. I have doubts here. Any site that explains exactly when the engine can stop and make a result command or when must play until end? The problem I see is if the engine has the autorithy to make result command

7) for global vars I have read in a forum that it is better to group them in a struct, so compiler can caching them better, but I doubt about this affirmation. any opinion?

8) does anybody know how can I tell MinGw not to show some warnings I dont want to be showed?

9) After so many years of advances in computer chess.... is there room for improvements? (i.e?) It looks like all is yet invented....

10) This point is not a question, but a issue I'm having. I use TSCP for test my engine, and I have null move and more chess knowledge, but TSCP continue scoring as if I had the same characteristics than TSCP. It looks to me that making new chess knowledge is a very difficult task, above all to make compatible with existing one...... and more difficult if that knowledge are refinement and not basic knowledge.

11) to compare chess knowledge bethween engines, is fixed depth level tournaments a good way of comparation?

12) do you use case tools or any other ways of analysis/design your program? or do you directly write code?

13) apart from compiler and editor/ide, what other tool do you find useful? I have read about lint..... do you use any other?

14) are there profile tools for programs made for windows OS ?

thx in advance..... sure I will bother more with my questions in the future.....

[hgm]

With (1) you hit on a weak spot in the minimax algorithm: it always assumes perfect play by the opponent, (i.e. score of position = score of best move from that position) and does not weight in at all how difficult it might be to find that best move (e.g. if there are many moves of the same score, or just one), or how risky the situation is (e.g. is the second-best move nearly as good, so that we can fall back on it if the original plan on deepr thought turns out fatally flawed). It also doesn't care through which path it reaches a final node (i.e. do the intermediate positions have good or bad evals, that we get stuck with if we have to abort the plan).

2) If you are prepared to abandon pure minimax, there are ways to do this without path dependence and hash inconsitencies. For instance, you could define the score of a nod a 0.95*scoreOfBestMove+0.05*currentEval or 0.95*scoreOfBestMove+0.05*QS_score. That would not lead to any inconsitencies, profided you precompensate the search window used to obtain the score of the moves for how you are going to modify them later.

3) Making an unlimited number of null moves in one path is not safe. But it is still better than only allowing a small number, so it is what people do. It makes you very blind against threats with many silent moves in it, but that then is a calculated risk.

5) This is known as Late-Move Reductions. Usually LMR is done in an even more aggressive way then you suppose, reducing all moves except 3 or 4. There is one refinement, though: if the move gives a good score (above alpha) despite the reduction, search it again unreduced, because apparently the move ordering was wrong (sorting this apparently best move too far in the back). And better not reduce captures. (Not even if they seem bad, because they will not be bad unless you recapture, thus severly restricting your choice, and making this a risky branch if trouble would show up deeper in the tree. So you want to make sure it doesn't.) And do not reduce passer pushes and checks (if you did not sort these in front).

6) KBK and KNK are draw. KBKB with like Bishops is draw. In none of these positions there is a checkmate possible, not even if the opponent would be helpful.

10) TSCP's game is characterized by being very aggressive with Pawns. Perhaps your engine isn't. More Chess knowledge doesn't always mean correct Chess knowledge. A better search depth will still lose if the evaluation is lousy, causing the engine to make fatal strategical errors that in the end make its position so inferior that even its larger search depth can not find solutions to threats that even the low search depth of the opponent can see.
Watch soem fast games, and try to figure out why your engine loses the games it loses. Does it let TSCP march its Pawns to 6th and 7th rank before trying to stop them? Does it 'hide' its pieces on squares where they are inactive? Does is create a lousy Pawn structure, which is undefendable in the end-game?

[Kempelen]

Hi HGM, thanks for your long answer.......

3) Making an unlimited number of null moves in one path is not safe. But it is still better than only allowing a small number, so it is what people do. It makes you very blind against threats with many silent moves in it, but that then is a calculated risk.

I dont have clear have many null moves must I allow. I will thinking on it.

5) ....And better not reduce captures.

even if the captures looks bad by SEE? (I avoid qsearch nodes with this kind of captures also?

6) KBK and KNK are draw. KBKB with like Bishops is draw. In none of these positions there is a checkmate possible, not even if the opponent would be helpful.

What I ask is not if the possition is draw, but the correct way the engine claim a draw. What is the protocol/correct way to operate:
- The possition is draw, but must wait until operator/GUI award it.
- The possition is draw and you can make a "result xxx" command, no matter what is the GUI state.

thx again.

[hgm]

The positions I mentioned are draw by rule (no mate position possible against any sequence of legal moves). They can be claimed by the WinBoard RESULT command (e.g. "1/2-1/2 {insufficient mating material}") just like you would claim a stalemate or a checkmate.

You have to be careful, though, to make the claim really in the position where it applies. So if it is your move, and you capture the last Pawn of the opponent in KBKP, you must _first_ make your move, and then send the RESULT command. This is not very dangerous for insufficient material, as the RESULT claim will always remain valid, as the opponent cannot make new material appear on the board by magic.

But it is a bit more tricky in the case of a 3-fold repetition or 50-move draw, as there the opponent might throw in a quick move between sending your move that caused the repetition, and sending the RESULT claim. If his move then would have destroyed the draw condition, the GUI will recieve your claim in a position where it is no longer valid.

The recommended protocol for such a case is to send an "offer draw" command before the move that creates the draw condition. The GUI or ICS often interpret a draw offer (which would remain valid after your move) in a position where you have the right to claim as a claim.