Next steps for my engine?

[plattyaj]

Well, I don't think I have it, but once or twice I have discovered that I had implemented something well known without realizing it. I understand the basic concept, but perhaps you can tell if it's there by a quick perusal of my engine code. I believe my search is an example of depth-first sarching, if that tells you anything about iterative deepening.

Nope, it's not in there. You would have an outerloop in makeMove that would keep increasing ply from 1 to the maximum depth. You would then iterate through CMove cm1 : list1 within that loop - calling it with a progressively higher ply count. Doesn't make any sense to do that without a hash table, though.

Andy.

[xsadar]

I agree with all advice that says get qsearch working before anything else - and, personally, you can ignore ordering of captures for now. Just having qsearch so you won't hang your Queen is such a big boost.
Andy.

Based on past experience, I think ignoring move ordering when doing qsearch is a bad idea. The first time I implemented qsearch I had just LVA order instead of MVV/LVA order because it was easier to generate moves in that order; and the result was a HUGE explosion in nodes once I added qsearch (in some positions it took forever just to search two ply). But sorting in MVV/LVA order is really simple, so there's no need to ignore it. You just sort by the value of the captured piece, and if that's the same, sort by the value of the moved piece. I now generate captures in that order, but a simple bubble sort should work ok (and might even be faster than my method since there are usually few captures available).

[mjlef]

As an experiment I tried a 200 game auto switch fixed depth (5 ply) match against my program with and without a qsearch. The qsearch version won every game.

[jesper_nielsen]

I agree with all advice that says get qsearch working before anything else - and, personally, you can ignore ordering of captures for now. Just having qsearch so you won't hang your Queen is such a big boost.
Andy.

Based on past experience, I think ignoring move ordering when doing qsearch is a bad idea. The first time I implemented qsearch I had just LVA order instead of MVV/LVA order because it was easier to generate moves in that order; and the result was a HUGE explosion in nodes once I added qsearch (in some positions it took forever just to search two ply). But sorting in MVV/LVA order is really simple, so there's no need to ignore it. You just sort by the value of the captured piece, and if that's the same, sort by the value of the moved piece. I now generate captures in that order, but a simple bubble sort should work ok (and might even be faster than my method since there are usually few captures available).

If you pack the move data into an int32 or similar datatype, it is pretty easy to do it in such a way that sorting for MVV/LVA is just a simple standard comparrison of ints.

And you don't necessarily need to do a full sort. You can just pick the highest one from the list of captures for each move generation. Kind of a one iteration of the time lazy sort.

If you get a quick cut off the lazy sort might be faster. But then again, if you need to go through the full list of moves, it might be faster to sort the moves up front.

Kind regards,
Jesper

[Will Singleton]

I lent that book to someone and never got it back, and I still yearn for it Maybe the book chapter is online somewhere. I'll bet you would benefit from reading it. It's extremely readable.

It's available on Amazon.

[Sean Evans]

Greetings. I'm looking for a few suggestions on next steps, where to take my engine from here. Thanks.

I would suggest changing the name of the program to FredChess.

You are welcome

Sean

[Fguy64]

Greetings. I'm looking for a few suggestions on next steps, where to take my engine from here. Thanks.

I would suggest changing the name of the program to FredChess.

You are welcome

Sean

Now that's something I can get my head around, Maybe I'll just call it Fred, or Barack. At one point I was thinking of calling it Fredder.

[F. Bluemers]

Greetings. I'm looking for a few suggestions on next steps, where to take my engine from here. Thanks.

I would suggest changing the name of the program to FredChess.

You are welcome

Sean

Now that's something I can get my head around, Maybe I'll just call it Fred, or Barack. At one point I was thinking of calling it Fredder.

Fredder is cool,associates with Shredder but also Eddie Vedder

[Fguy64]

OK, there has been lots of good stuff in this thread, so I'll keep it going. The general consensus is that a quiescence search should come next, and I am working towards that by reviewing my negamax/alphabeta search to reinforce on the basics.

I'm using Bruce Borland's pages as a guide. I like his stuff because it is not too technical for me.

I think the way I have coded my negamax/alpha-beta search is hindering my progress. I believe my algorithm is correct, I have had good success with WAC Suite, but my algorithm is expressed in a non-standard way and I can't really relate it to the things Borland, and others, say about Alpha-Beta. In particular he passes alpha, beta, and depth to his recursibe function, and mine seems a little different. I also seem to use ply a little differently than most, though it all seems to come out in the wash.

So as a first next step I'd like to start a dialog for the purpose of reconciling the difference between my approach and Borland's. Maybe I should rewrite my negamax if it will make my life easier.

Borlands alpha-beta page is here.
http://web.archive.org/web/200404200223 ... habeta.htm
my engine code is here


in my code. From makeMove() I first do a non-recursive possibleMoves. Then I evaluate each move recursively by calling a method called evaluate. Note this is not an eval method. I suppose I should have called it negamax. There is another method called evalPos which adds up material and also does a little central control thing. I see line 171 as the key line of code for pruning.

Anyways. I'll leave it at that. I'm hoping people will take a look at my code and provide some suggestions for bringing it into line with standard ways of design, if there is such a thing in the first place. Naturally I can provide further explanations of my code if needed.

[tano-urayoan]

Just a note is not Boreland is Moreland.