A bug is squashing me. HELP!

[odomobo]

Oh my bad, you said it gives 100 or -100 from the initial position. It should give 0 for depths 1 and 2 (maybe even 3), but 100 or -100 for the rest (since it's easy to capture, e.g. a pawn with a queen on a given move, if you don't have to worry about the consequences).

Something else that you might consider is adding a triangular pv table. It's extra work, but it lets you see the entire line that your engine is considering. However, not really worth it until you add qsearch

[odomobo]

Also, one other thing to note: if you have qsearch (so the engine understands that captures have consequences), then a simple material-only evaluation won't encourage the engine to make any progress, in general. It'll take advantage of guaranteed tactics, but otherwise will essentially do random moves. At the beginning of the game, I would expect to see it play extremely passively, essentially preventing the opponent from taking advantage of any tactics it can see within its search window.

This is the point of piece-square tables -- a very naive but cheap and effective way of encouraging the engine to make developing moves, when it has no tactics.

[Michael Sherwin]

Yes, these are the next steps I was planning to implement.

I have added Qsearch() and it is acting much better now. In the initial position searched to ply 8 and ply 9 it returns 0 as expected. However, there is still a problem. In the following position.

[d]r1bqkbnr/1ppp1ppp/p1n5/1B2p3/4P3/5N2/PPPP1PPP/RNBQK2R w KQkq - 0 4

A 5 ply search returns -100.

[Michael Sherwin]

Also I should mention that this is in the early stages an experiment for a new kind of AB engine. In the experimental phase it will not have an evaluation function of any kind. Instead there will be a pointer to the current root node. There are statistics fields in each root move. During the search, stats are collected to the root move. The first experiment will play the highest material score. If there are more than one move with material equal scores the move with the best stats will be played. Then in the second phase of the experiment thresholds will be developed that represent material compensation. The stats will also be used to order moves. Shallow searches to order the moves further up the tree will be tried after that. I want the engine to be a statistical driven search. Eventually the stats will be converted to a winning probability score.

Edit: After it is working I plan on putting it on Github or whatever it's called for an open source project!

[odomobo]

That sounds like a bug. A triangular PV table could help you debug it. If it helps, I have an implementation here that you could use/modify: https://bitbucket.org/odomobo/gearheart ... vTable.hpp

[Michael Sherwin]

I will take a look right now! ty

[Sven]

So far all I have is a material searcher. From the initial position it returns a score of either 100 or -100 depending upon the modification or search depth. Never any other value. I update material on the fly in make and unmake. When a search is done the board and all starting data is the same as at the beginning of the search. The only thing that is off is the score returned. I made an endleaf material summation function in place of the on the fly summation. It did not have an effect on the score returned. I must be doing something wrong in the search. But, what?

Code: Select all

s32 Search(s32 alpha, s32 beta, u32 depth) {
  u32 i;
  s32 score;
  
  if (!depth) {
    score = Material();
    //return (wtm ? wMat - bMat : bMat - wMat);
    return (wtm ? score : -score); // Qsearch(alpha, beta);
  }

Print the return value of Material() whenever it is different from 100 or -100. If the output is empty then the bug is in the Material() function, otherwise in the search.

[pijl]

Yes, these are the next steps I was planning to implement.

I have added Qsearch() and it is acting much better now. In the initial position searched to ply 8 and ply 9 it returns 0 as expected. However, there is still a problem. In the following position.

[d]r1bqkbnr/1ppp1ppp/p1n5/1B2p3/4P3/5N2/PPPP1PPP/RNBQK2R w KQkq - 0 4

A 5 ply search returns -100.

Did you test you quiescense search independent from your main search?
Depending on how you created your quiescense search, a 0-ply search (so just quiescense) should return 100 here as white can win a pawn with just capture moves.
Next step is really to examine the searchtree, which is quite doable when things already go wrong with 5 ply searches.
Richard.

[Michael Sherwin]

Thanks Sven and Richard. All good ideas!

[Michael Sherwin]

I found one bug and it works better but it still is not quite right. It might be because I'm interpreting what I see in the debugger incorrectly because of fail hard therefore the scores I see are not the true score. So I'm going to switch to fail soft while debugging. However, I was able to play a few moves. And it did punish the last move I made on purpose to see if it would find the correct move and if it would score it correctly. And it did!

[pgn][Event "Computer chess game"] [Site "MASTER"] [Date "2019.05.03"] [Round "?"] [White "Mike Sherwin"] [Black "Mike Sherwin"] [Result "*"] [BlackElo "2400"] [ECO "C57"] [Opening "Two Knights"] [Time "14:15:27"] [Variation "4.Ng5"] [WhiteElo "2400"] [Termination "unterminated"] [PlyCount "11"] [WhiteType "human"] [BlackType "human"] 1. e4 e5 2. Qh5 Nc6 3. Nf3 Nf6 4. Qh4 h6 5. Bc4 g5 6. Nxg5 * [/pgn]

So I am making progress. Hopefully my next report will be even more positive! I'm also wondering why it is taking several seconds to look 6 ply deep with quiescence and move ordering. But one step at a time. Also it played kind of logically even though it has no evaluation function of any kind. To get it to play the moves it did from the white side I just counted beta cuts for both sides and subtracted them (favorable for computer - favorable for opponent). Which is the point of this experiment--a searcher based on material and statistics. I hope it is interesting!

P.S. I'm confident that once it can search deeper in a reasonable time it won't play 2 Qh5 as the stats won't remain as good.