Winboard Forum

Hi Alessandro,

Your new chess program Hamsters looks spectacular! I am playing a Nunn2.pgn match between Hamsters and my program RomiChess as I am writing this. The little buggers are nipping away at Romi's ankles quite efectively, even for such an incomplete program. I will include the results when the match is finished. I am going to assume that at least one of the reasons that you made such an early release of Hamsters is that you are hoping for some feedback. I might be wrong about this, but I am going to assume it anyway.

The score is now +5 -1 =3.

The first thing that strikes me is that you claim that Hamsters has no evaluation function! This is believeable, because, I also have written a program called Carnivor that has no evaluation function. However, Carnivor does have evaluation, just not in a function. Carnivor has static piece square tables that are hand tuned and uses them to maintain a couple of positional variables 'on the fly' that can be accessed whenever the values are needed. Of course material is also kepted track of this way. RomiChess also uses this method, however, Romi has an evaluation function for pawn structure and the piece square tables are dynamicly created before each search. Is Hamsters using a method similar to this? There is one thing of concern here, if this is the case and that is the node rate that you are achiving. Romi is achiving about double the node rate of hamsters and it is a bitboard engine on a 32 bit machine. Carnivor achives about ten times the node rate (carnivor has no hash tables). How much will you loose in node rate if you add a moderate evaluation function? Have you created a way of doing pawn structure analysis on the fly? I tried but failed -- it was just too complicated.

The score is now +12 -5 =5. A very fast time limit of 70 moves in 1 minute, repeating is being used. Hamsters is handleing this time limit just fine.

One thing that I am very envious about is Hamsters displayed principle variation. Romi displays a lot of very short lines and is not very consistant when it comes to displaying the pv. Can you please give me some insight on what might be causing this? Also the move ordering seems really good. Will you give a description of the move ordering?

The score is now +19 -5 =5. The match is much closer than the score indicates. A lot of long games are being played. This is about the same margin that Romi beats Olithink by and Hamsters is doing better than Faile.

I think that if Hamsters is as incomplete as you make it sound then I will expect to see Hamsters knocking at the door of the WBEC premier section very soon. This is just my impression from haveing just watched Hamsters playing a few games. Good luck with your new program Hamsters!

Best wishes,
Mike

P.S. The final score issssssssssss..., Oh no, a time loss for Hamsters for game 40 in a drawn king and pawn endgame ..., Wow! Hamsters really caught fire towards the end, +29 -11 =10. Romi does better against Olithink.

Hello Michael,
thanks a lot for your feedback... wow that's a lot more than I could ever ask for!

You are right about Hamsters' evaluation: it uses material plus some piece/square tables that are updated incrementally. Those are currently set to zero for pawns, so there's no pawn evaluation whatsoever.

With respect to that, I plan to add evaluation for isolated and doubled pawns and see what happens. In Kiwi, I used to have a rather sophisticated function to evaluate the pawn structure, but when tested one at a time, only the two features above seemed to have an impact on the playing strength. Maybe because of bugs! At any rate, that seems a good starting point.

The reason the principal variation is long is I don't use TT or null move cutoffs at PV nodes (in my case, when beta != alpha+1), something that I learned from Fabien and Tord. A while ago Daniel posted some stats here where it's shown that PV nodes are only a very small fraction of the tree, so that doesn't really cost much.

With respect to move ordering, it's based on Ed's suggestions (http://members.home.nl/matador/chess840.htm) with a few differences, but I will definitely keep working on it, there are still many things to try! BTW, I always use SEE for weighting and pruning captures in the qsearch.

I don't know what to think about the node rate... Hamsters seemed pretty snappy to me before you quoted your figures!
I think there's still room for "design improvements" (things that cleanup the code AND make it faster) but I'm not particularly worried about it 'cause it's going to drop like a stone anyway, as soon as I start adding evaluation terms... will still go thru the code and see if there's something I missed though!

I certainly hope that Hamsters gets better in the future, but I want it to stay a 100% fun project, and with a story to tell! In fact, my next goal is not making it stronger but rather adding support for multiprocessing, which is something I could never do in Kiwi (too messy)!

BTW Cristophe Theron wrote in a old post at CCC that a piece/square program would get about 2400 elo. I think Hamsters is at least 200-240 elo shorter on that goal...

P.S. Could you send me the time loss game?!?

Alessandro Scotti wrote:With respect to that, I plan to add evaluation for isolated and doubled pawns and see what happens. In Kiwi, I used to have a rather sophisticated function to evaluate the pawn structure, but when tested one at a time, only the two features above seemed to have an impact on the playing strength.

Backward pawns had no impact on strength? This is very surprising. In my experience, backward pawns are at least as important as isolated pawns.

I don't know what to think about the node rate... Hamsters seemed pretty snappy to me before you quoted your figures!

I guess it will seem pretty snappy again if I give you my figures for Glaurung: With material and piece square tables only, Glaurung searches only about 570 kN/s on the Pentium IV 2.4 GHz in my office. I prefer to regard this as a good thing. If I ever reach the stage where I cannot find any improvements in my search or eval, I should still be able to improve the strength by another 50 Elo points just by improving the speed.

I certainly hope that Hamsters gets better in the future, but I want it to stay a 100% fun project, and with a story to tell!

I look forward to reading the continuation of the story, and to the day you release a Mac OS X version of Hamsters.

In fact, my next goal is not making it stronger but rather adding support for multiprocessing, which is something I could never do in Kiwi (too messy)!

Good luck! Multiprocessing is great fun.

Tord

Hi Alessandro,

Thank you for the information on Hamsters. I will send you the game lost on time as soon as possible. It is still in the recycle bin. This is something that Microsoft did correctly.

Mike