Frustrations of a mediocre chess programmer. What next?

[Uri Blass]

Doesn't PSWBTM accept time in the format mm:ss ? If not, we should inform Pradu.

As concerning the fixed number of nodes: Is it possible to ask for this in the Winboard protocol at all?

If you don't want any graphics, an adapter to play two programs a number of times is almost trivial to write.

1)As far as I see it does not accept mm:ss format and when I try to replace 1 by 0:30 it simply correct 0:30 to 1

2)I think that it is not possible in original winboard to do it based on the engine protocol.

Maybe it is possible to do it in winboard_x and I did not check it.
I know that winboard_x support uci engines and it is possible to have fixed number of nodes in the uci protocol.

Uri

[Matthias Gemuh]

Hi Jesper,
your "isready" tip helped me fix the memory usage problem.
ChessGUI was sending "isready" before having received "uciok" .
Thanx,
Matths.

[Alessandro Scotti]

Hello TalkChess!

I wonder how many of you have had the same frustrating experience as me.

You can definitely add me to the club!

When i started writing my engine, Pupsi, it was steady improvements for roughly a year and a half! It was wonderful! Thrilling! Exciting!

But after the latest release, v0.18, I hit a road block.

Nothing gives any improvement! I have tried many, many things, but all of them resultet in roughly zero ELO points, so they were all discarded. Countless hours down the drain.

The frustration have set in!

In my experience, this depends on bugs in the code. I lived the same situation with Kiwi, where rewriting the whole evaluation function from scratch gave absolutely no elo change: not better, not worse. It took me a lot of time to find a _huge_ bug in the hash table implementation, but solving that bug gave me 120 elo instantly. The bug was dominating all other changes, by changing the evaluation in a sort of random way.
BTW I recently (after 1.5 years) had another look at the code and could immediately find another obvious bug... in the hash code! I must be beyond redemption...
With Hamsters, I did a complete rewrite using entirely different data structures and algorithms. This engine is considerably simpler and faster than Kiwi, yet barely stronger and I got to this point only by... fixing bugs! In case of Hamsters, I must add: "...and small details".
Like Tord said once, there can be hundreds of tiny bugs or unoptimal details in a chess program, and even if they are worth 2 or 3 elo each we are talking about a huge difference in the end. I spent a lot of time looking for these, but eventually this (boring) job did pay out in terms of elo strength.
If I compare say Hamsters and Fruit I wonder: where's the difference? We have more or less the same feature set at a high level yet there are 250+ elo points between the two... it makes sense to look at bugs and details IMO.

[Uri Blass]

As far as I can see I do not see how to use it because even after giving this exe the details it does not start engine matches for me.

Uri

[jesper_nielsen]

Maybe I should spend a little time on making a few bug-hunting tools.

A simple fen string "flipper" should be easy to make. That way I can at least ensure that all my bugs are symmetrical!

Kind regards,
Jesper

[Alessandro Scotti]

A simple fen string "flipper" should be easy to make. That way I can at least ensure that all my bugs are symmetrical!

Uri put some portable code on this forum a while ago, so make sure to check it.
I did a lot more in Hamsters, including for example instrumenting Glaurung so that it would read FEN positions from a file and output a series of position "features" for each of them, including for example: isolated, double, passed pawns, open files, rooks on 7th, SEE result for each possible move and so on. Then I did the same with Hamsters and compared the results (manually, because of structural differences between the two programs). To be honest so far it lead to "only" one bug but I am happy with it and I learned a lot in the process.
Another very useful thing is to listen carefully to practical bits of wisdom that Tord, H. G. and other authors post daily on this forum. I remember one post by Tord spotting a few very minor bugs in Crafty and guess what? I had one of them. Then H. G. said it's probably a good idea to return beta from null move, I tried that too. Eventually the "package" that includes the above three modifications and nothing else was worth a 15-20 improvement... not bad for three lines of code I would say!
I also implemented a tree dump and tree browse tool for analyzing search trees... it was fun to program and a good, relaxing diversion when you are designing the next killer chess feature!

[Ron Murawski]

My advice is:

• turn warnings up to maximum
  use other compilers

When I turned up the warning level to max I had more than 200 of them. Although many warnings were quite silly I found a way to correct each of them and make the compiler "happy". While I was in this process I shook out about a dozen genuine coding errors! The bug corrections gave me about a 50 Elo increase.

In the past my program was always compiled using the Microsoft compiler only. When I tried to compile using GCC I found a very bad bug -- two globals with the same name in separate files! That bug shocked me. (I'm not sure how the Microsoft compiler allowed this mistake in a pure C program but perhaps it had to do with C++'s name-mangling, which was new at the time. And perhaps there were compiler patches that corrected this problem that I neglected to apply?) GCC also forced me to do some additional casting in the move generator. I don't believe the additional casts changed the results of any calculations, but I made the changes because they were technically correct from a pure C-language perspective.

When I tried to compile using the Open Watcom compiler I discovered a portability issue where I had assumed that char without signed/unsigned defaulted to signed. Not true!

Ron

[bob]

PSWBTM does allow you to start from arbitrary positions: you just have to specify a file with the moves leading to them in PGN, or FENs, and your match uses those as initial position. I always run matches from the Nunn positions for testing. If the specified file contains 10 positions, and you ask for 200 games, it plays every position 10 times with white and 10 times with black.

I think others already suggested how you could disable the display in Winboard.

I am not sure if you could make it very fast, though, as it starts up the engines anew for each game. On some Operating Systems starting up an engine takes dozens of seconds.

Winboard/xboard can do all of that. you can load starting positions for matches from a file, you just tell it the filename, and the position index (starting at 1) to load from the file... I used to use it on my cluster, but the overhead for playing 256 games at a time is just too much. I wrote my own specific code for the cluster to play matches with zero overhead...

[swami]

ord Romstad, the author of Glaurung has his third engine already.
Edsel

I guess the Viper is an abridged version of Glaurung, So it's hardly a rewrite or a new engine,isn't it?Tord can clarify this.

Gothmog, Glaurung 1 and Glaurung 2 (a complete rewrite in everything except name). Viper is indeed a simplified Glaurung 1.

Thanks for this info,Teemu.

[YL84]

Hi,
what I could add to that the others said is just ask to a high rated human player (if you are not yourself a GM ) to say you what are the weaknesses of your engine. Could help,
Yves (an other frustrated programmer)