Winboard Forum

http://koti.mbnet.fi/~ilaripih/sloppy/

It's a Xboard/Winboard chess engine, and also my first release-worthy C application. The goal was to really learn C programming, so I thought a chess engine would be a good challenge.

Sloppy uses bitboards and Pradu's magic move generator. I've only tested it on my PC and compiled it only with GCC (in Linux) and Mingw (in Windows). So it might not be straightforward to compile it with VC++ for instance. But if someone would like to compile faster Windows or Linux binaries I'd very much appreciate it.

The #1 priority was to write bug-free, easy-to-read and easy-to-improve code and use sane data structures and algorithms. So I just took a look at the Fruit 2.1 evaluation function and pretty much rewrote a simplified bitboard version of it. When I get the time I'll start focusing on the evaluation.

Anyway, I'm pretty happy with what I've created. Sloppy isn't the strongest engine out there (prolly somewhere between 2000 and 2600 ELO), but I think it's a solid base for new features and experiments. It's not that fast either. For example it only generates legal moves, which takes time but also makes things a lot simpler.

I'd appreciate any feedback. Cheers, Ilari.

Hi,
I just compiled it and typed bench.

White: bench
Running benchmark at search depth 8...
100% [========================]

Benchmark finished in 31.15 seconds.
Main nodes searched: 10298009
Quiescence nodes searched: 17290626
Total nodes per second: 885670
Average branching factor: 2.72
Hash table hit rate: 12.35%

Looks pretty good.
Your goals are reasonable.
Keep up the good work

greetings
Bernhard

Thanks. It sure took me a long time to release this engine, mostly because of the constant rewrites and changing goals. Now the project is at a stage where it's very easy to add or remove features.

I of course have to thank the great programmers here and over at TalkChess.com for their contributions to computer chess. I learned a lot by reading their posts and the source code of their engines. Dr. Hyatt's online publications of bitboards were also tremendously helpful. Releasing Sloppy under an open source license was the easiest way to give something back.

Hi Ilari!
From which country you come?
Greetings, Ciro

I'm from Finland. Not much chess programming happening in this part of the world, so I guess I just wrote Finland's best chess engine.

Hello Ilari,

Do you have a more specific estimate of the strength than 2000-2600?

I was thinking of running a few CCRL games but with that kind of estimate it's hard to find opponents that is reasonable.

Martin Thoresen wrote:Hello Ilari,

Do you have a more specific estimate of the strength than 2000-2600?

I was thinking of running a few CCRL games but with that kind of estimate it's hard to find opponents that is reasonable.

Sure, my estimate is about 2550 ELO. I just didn't want to throw in such a precise number because the estimate isn't reliable. I've only tested blitz games, only against a few opponents, and only low numbers of games. So even though bliz games indicate that Sloppy is a lot closer to 2600 than 2000, longer time controls could change it.

Hi Ilari,

I've compiled an Intel compiler 10 PGO version here >

http://myfreefilehosting.com/f/cb580b8e15_1.43MB

Also includes 'Core-duo' build and modified src to compile also under Msvc++ and Intel.

Rgds,
Jim.

Thanks a million! Those are a lot faster than my puny Mingw build. I uploaded the all processors build to my site.

Looks like the source didn't have to be changed as much as I had feared. Maybe I'll be able to keep it Msvc++ and Intel -friendly.

I noticed that your binaries don't give the same node counts in bench as mine do, but that's very likely just a floating point precision thing that doesn't affect anything.

Hi Ilari and all

We are always happy to have a new engine to play with...

But, in your opinion (engine authors, tournament directors, and other people), should Sloppy be allowed to play in tournaments ?

What Ilari did is perfectly legal, and he hides nothing at all. This is not the point.

The annoying part in Sloppy is :

Evaluation weights and terms are pretty much borrowed from Fruit 2.1

Olivier

Hi Olivier,
you may write "I am always happy ..." instead of "We are ...".
That way you speak for yourself.

IMHO there is nothing annoying with sloppy. It is perfectly ok to take the best weights and terms you know. Why should anybody use worse terms?

I will encourage Ilari to continue!

regards
Bernhard

Olivier Deville wrote:But, in your opinion (engine authors, tournament directors, and other people), should Sloppy be allowed to play in tournaments ?

I'm not going to enter Sloppy to any tournaments myself, but if people want to include it in their own tournaments, why shouldn't they?

The annoying part in Sloppy is :

Evaluation weights and terms are pretty much borrowed from Fruit 2.1

The reason for this is that Sloppy was a programming challenge, not a chess challenge. The evaluation function is a somewhat simple thing programming-vise, but it requires a lot of testing and chess-knowledge. So to get a release out before I die of old age, I decided to use Fruit's weights. And as I said, I'm going to rewrite the eval as I'm sure it's not optimal for Sloppy.

Ilari Pihlajisto wrote:

Olivier Deville wrote:But, in your opinion (engine authors, tournament directors, and other people), should Sloppy be allowed to play in tournaments ?

I'm not going to enter Sloppy to any tournaments myself, but if people want to include it in their own tournaments, why shouldn't they?

The annoying part in Sloppy is :

Evaluation weights and terms are pretty much borrowed from Fruit 2.1

The reason for this is that Sloppy was a programming challenge, not a chess challenge. The evaluation function is a somewhat simple thing programming-vise, but it requires a lot of testing and chess-knowledge. So to get a release out before I die of old age, I decided to use Fruit's weights. And as I said, I'm going to rewrite the eval as I'm sure it's not optimal for Sloppy.

Thanks Ilari

I have no doubt you put a lot of personal work in Sloppy. When the eval is rewritten, I will certainly take it in ChessWar.

Olivier

Ilari Pihlajisto wrote:http://koti.mbnet.fi/~ilaripih/sloppy/

It's a Xboard/Winboard chess engine, and also my first release-worthy C application. The goal was to really learn C programming, so I thought a chess engine would be a good challenge.

Sloppy uses bitboards and Pradu's magic move generator. I've only tested it on my PC and compiled it only with GCC (in Linux) and Mingw (in Windows). So it might not be straightforward to compile it with VC++ for instance. But if someone would like to compile faster Windows or Linux binaries I'd very much appreciate it.

The #1 priority was to write bug-free, easy-to-read and easy-to-improve code and use sane data structures and algorithms. So I just took a look at the Fruit 2.1 evaluation function and pretty much rewrote a simplified bitboard version of it. When I get the time I'll start focusing on the evaluation.

Anyway, I'm pretty happy with what I've created. Sloppy isn't the strongest engine out there (prolly somewhere between 2000 and 2600 ELO), but I think it's a solid base for new features and experiments. It's not that fast either. For example it only generates legal moves, which takes time but also makes things a lot simpler.

I'd appreciate any feedback. Cheers, Ilari.

I also made a Win32 build:

C:\pgn\WINBOA~1\SLOPPY~1\sloppy\Release>sloppy.exe
Sloppy 0.1.0 by Ilari Pihlajisto

Build date: Oct 8 2007
Debugging level: 1
Optimized for 32-bit

Initializing...
Found 1 CPUs
Using "book in memory" book mode
Loading opening book to memory...
Book learning ON
Hash table size: 48 MB
...Done

Type "help" to display a list of commands
White: bench
Running benchmark at search depth 8...
100% [========================]

Benchmark finished in 53.45 seconds.
Main nodes searched: 9952504
Quiescence nodes searched: 16679877
Total nodes per second: 498220
Average branching factor: 2.66
Hash table hit rate: 12.61%
White: quit

But Jim's is faster:
C:\pgn\WINBOA~1\sloppy_010_intel_win32_ja\all processors>sloppy.exe
Sloppy 0.1.0 by Ilari Pihlajisto

Build date: Oct 7 2007
Debugging level: 1
Optimized for 32-bit

Initializing...
Found 1 CPUs
Using "book in memory" book mode
No opening book was found
Book learning ON
Hash table size: 48 MB
...Done

Type "help" to display a list of commands
White: bench
Running benchmark at search depth 8...
100% [========================]

Benchmark finished in 50.56 seconds.
Main nodes searched: 10297975
Quiescence nodes searched: 17290695
Total nodes per second: 545619
Average branching factor: 2.72
Hash table hit rate: 12.35%
White:

Hi Dann,

But Jim's is faster:

I'm not sure you can trust the built-in bench with regards to my
Intel build. Maybe some precision/accuracy has been lost in the
conversion. I would expect your build to be much closer than that.

Jim.

Jim, I looked at your changes more closely and found a few problems:
- INT64_MAX is defined in sloppy.h as 10000000. Should be 0x7fffffffffffffff.
- In GNU C I use the PRIu64 constant to print uint64_t values. You're using %d which is for type int. Should probably use %llu. This problem can be verified by running perft 7 from the starting position.
- In perft.c (line 218) the "divide" node count is multiplied by 3. I don't understand why.

Jim Ablett wrote:Maybe some precision/accuracy has been lost in the
conversion. I would expect your build to be much closer than that.

Yup, Dann's node counts seem to be very different. Perhaps perft would be an appropriate benchmark here. The smp perft seems to get into a deadlock occasionally in Windows, so it's best to run Sloppy with the "-t 1" parameter to use just one thread.

Ilari Pihlajisto wrote:The #1 priority was to write bug-free, easy-to-read and easy-to-improve code and use sane data structures and algorithms. So I just took a look at the Fruit 2.1 evaluation function and pretty much rewrote a simplified bitboard version of it. When I get the time I'll start focusing on the evaluation.

Just two questions.

1. Isn't Fruit 2.1 released under GPL?
2. Doesn't GPL imply distribution of source code for any derivatives of GPL'd software?

3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)

Hello Vladimir!

Vladimir Medvedev wrote:Just two questions.

1. Isn't Fruit 2.1 released under GPL?
2. Doesn't GPL imply distribution of source code for any derivatives of GPL'd software?

The answer to both questions is "yes". But because Sloppy 0.1.0 is also released under the GPL (version 3), everything appears to be OK.


Tord

Hello Ilari,

Thanks a lot for Sloppy! It compiled straight out of the box with GCC on my Mac. Trying to compile with the Intel compiler (which is more than twice as fast as GCC for my own engine) gave some errors, but I hope the problem will be easy to fix. I'll send you a Mac OS X executable and the modified source code as soon as I succeed.

I am very happy to see another GPLed chess engine appear.


Tord

Tord Romstad wrote:The answer to both questions is "yes". But because Sloppy 0.1.0 is also released under the GPL (version 3), everything appears to be OK.

Oops, did not notice that
Of course, it's definitely OK, I agree.