Looking for C developper

[lucasart]

I'm starting to be bored of developing DiscoCheck:

• As with any advanced program, I only use my brain only 1% of the time, and the remaining 99% I use time and electricity...
• Code is becoming messy, and many design choices I wish (in hindsight) I had done them differently. Now it's getting hard to modify this mess. Perhaps I still can, but it's boring.

So I decided to rewrite it from scratch. From a pure productivity point of view, this is stupid. But I don't do this for productivity anyway, only for fun. Let's face it, DiscoCheck is never going to be the top dog, or even close. It gives me the opportunity to make different design choices, that experience has taught me are better.

Is anyone interested to develop it with me? Obviously someone with strong C programming skills and prior experience in chess programming. Will be GPL free software. Here is the code:
https://github.com/lucasart/DiscoCheck
Now is the time to join, because:

• the code base is still simple, and easier to fully understand.
• the exciting stuff begins: really chess related code and design choices. All the penance of writing hundreds of lines of boring boiler plate code are out of the way, thoroughly tested, and profiled to death.

Anyone?

[zamar]

I'm starting to be bored of developing DiscoCheck:

• As with any advanced program, I only use my brain only 1% of the time, and the remaining 99% I use time and electricity...
• Code is becoming messy, and many design choices I wish (in hindsight) I had done them differently. Now it's getting hard to modify this mess. Perhaps I still can, but it's boring.

So I decided to rewrite it from scratch. From a pure productivity point of view, this is stupid. But I don't do this for productivity anyway, only for fun. Let's face it, DiscoCheck is never going to be the top dog, or even close. It gives me the opportunity to make different design choices, that experience has taught me are better.

Is anyone interested to develop it with me? Obviously someone with strong C programming skills and prior experience in chess programming. Will be GPL free software. Here is the code:
https://github.com/lucasart/DiscoCheck
Now is the time to join, because:

• the code base is still simple, and easier to fully understand.
• the exciting stuff begins: really chess related code and design choices. All the penance of writing hundreds of lines of boring boiler plate code are out of the way, thoroughly tested, and profiled to death.

Anyone?

I like your code It's clean and elegant.

But I'm not the person that you're looking for...

[elcabesa]

Hi Lucas,
good luck with your rewrite of discoCheck! I restarted my rewrite of Vajolet some month ago and got very good result and some very exciting months!!

[Evert]

Unfortunately I'm not bored yet of tinkering with my own brain-childs, or I'd be interested. As it is, I have too much fun (and honestly not enough time) tinkering with my own programs.

I'm curious to know what you feel are some of the bad design choices that you'd wish you'd done differently (apart from writing in C++).

Also, if I can make a suggestion that goes off on a bit of a tangent, if you get bored of tuning your new version of DiscoCheck, you may wish to consider making it able to play chess variants. There are various aspects of this that I personally find very fun: evaluation terms are different, it's not so obvious what the good ideas are so there's more room to innovate, there is a much smaller pool of programs to compete against, which is both good and bad (it's relatively easier to become one of the better programs, but once you've passed Fairy-Max it gets more complicated to find other programs to compare yourself with). Personally I find it fun to try to come up with "variant agnostic" evaluation terms, so that I don't have to write a completely new evaluation function in each case (evaluation weights may need to be tuned differently for different variants, of course). Unfortunately once you get past Fischer Random Chess, chess variants are a bit of a niche market, so you have to be able to deal with there being only a handful of people who are interested in what you're doing.

The downside to some chess variants is the peculiar board sizes. Capablanca/Gothic (10x8) is probably one of the more popular ones, and then there's regional variants like XiangQi (9x10) and Shogi (9x9). Makruk (Thai chess) is 8x8, however, as are historical games like Shatranj. More recently there's Seirawan chess, and of course you have games like bughouse and crazyhouse. The larger board sizes are much more tricky to handle with bitboards (not impossible though, but if you're not married to the bitboard way of thinking, mailbox is a very good alternative).

[lucasart]

I'm curious to know what you feel are some of the bad design choices that you'd wish you'd done differently (apart from writing in C++).

* using an "eval class" with 2 int's for opening/endgame score, instead of vectorizing (int16_t, int16_t) <-> int32_t as done Stockfish, Critter (and probably most top engines).
* putting too much intelligence into the board class. in particular calculating tons of stuff after playing a move, that can be skipped in many nodes of the search due to early pruning (before move generation).
* hardcoding some limitations inside the board and movegen code. using some nasty global arrays where a recursive approach is more elegant and SMP-friendly.
* writing a single threaded program, and thinking that one day, maybe (ie. never), I will find the courage to parralelize it. better to parralelize it when you have an extremely simple alpha/beta, and add stuff and make design choices with SMP in mind.

I suppose I could rewrite large portions of my code to retrofit these things into it. But it would be hard and not very fun. Seems more exciting to restart and keep an open mind. Try to do things differently, with the experience and gained from the previous attempt. Fix some wrong design choices, as well as experiment with other ones.

[Rein Halbersma]

The downside to some chess variants is the peculiar board sizes. Capablanca/Gothic (10x8) is probably one of the more popular ones, and then there's regional variants like XiangQi (9x10) and Shogi (9x9). Makruk (Thai chess) is 8x8, however, as are historical games like Shatranj. More recently there's Seirawan chess, and of course you have games like bughouse and crazyhouse. The larger board sizes are much more tricky to handle with bitboards (not impossible though, but if you're not married to the bitboard way of thinking, mailbox is a very good alternative).

I maintain a game library for draughts variants on arbitrary boards, and have created a C++ class similar to std::bitset but with full iterator support and other niceties. It allows for seamless bitboard support for arbitrary board size (beyond 256 squares there is some compiler-limits tuning required). All the bitwise operators are overloaded. The only limitation is that magic move generation is not supported because multiplication of large integers was too annoying to code (plus magic on huge boards require probably too large tables anyway). For king moves in draughts, I use simple flood-fill based techniques instead. Due to heavy dependence on C++11/14, it is currently only supported on Linux and Clang >= 3.4.

[Evert]

* using an "eval class" with 2 int's for opening/endgame score, instead of vectorizing (int16_t, int16_t) <-> int32_t as done Stockfish, Critter (and probably most top engines).

I agree that using a vector is more elegant. I never got the impression it was actually worth that much in practice though...

* putting too much intelligence into the board class. in particular calculating tons of stuff after playing a move, that can be skipped in many nodes of the search due to early pruning (before move generation).

Do you have attack tables? I once experimented with those - you get the in-check test for "free" and you can do clever tricks with hanging pieces and safe time for mobility calculation in the evaluation. I never got it to do more than break even though, and it makes the code significantly more complicated (so I scrapped it).

* hardcoding some limitations inside the board and movegen code. using some nasty global arrays where a recursive approach is more elegant and SMP-friendly.
* writing a single threaded program, and thinking that one day, maybe (ie. never), I will find the courage to parralelize it. better to parralelize it when you have an extremely simple alpha/beta, and add stuff and make design choices with SMP in mind.

Yes, building an SMP engine from the ground up is definitely a better idea than trying to put SMP into an existing framework that doesn't take to it very well. I think Don rewrote all of Komodo for the same reason (but maybe I remember wrong).
It's one of the things that was much easier in Jazz than I thought it would be, due to having no global state at all.

I suppose I could rewrite large portions of my code to retrofit these things into it. But it would be hard and not very fun. Seems more exciting to restart and keep an open mind. Try to do things differently, with the experience and gained from the previous attempt.

That is certainly much more fun, and it's great to see the rapid improvement once you put in the transposition table, null-move, piece square tables (versus no piece square tables). Do you plan to keep the evaluation basically the same? You spent quite a lot of time tuning it very thoroughly, seems like a shame to throw that away.

[Evert]

I maintain a game library for draughts variants on arbitrary boards, and have created a C++ class similar to std::bitset but with full iterator support and other niceties. It allows for seamless bitboard support for arbitrary board size (beyond 256 squares there is some compiler-limits tuning required). All the bitwise operators are overloaded. The only limitation is that magic move generation is not supported because multiplication of large integers was too annoying to code (plus magic on huge boards require probably too large tables anyway). For king moves in draughts, I use simple flood-fill based techniques instead. Due to heavy dependence on C++11/14, it is currently only supported on Linux and Clang >= 3.4.

Nice!
In Sjaak I have two move generators (actually, two of everything), one operating on 8x8 boards stored in a uint64_t, and one operating on a uint128_t (which I think is a GCC extension). It works, but it's extremely ugly that almost everything is if (small board) { 64 bit stuff } else { equivalent 128 bit stuff }.
So I rewrote the move generator last year using C++ templates. It now does boards based on 16, 32, 64 and 128 bit integers transparently. I have yet to port the rest of the program over though, which is the boring part: writing the general move generator was fun.

I don't do magic move generation though, but I use what CPW calls "kindergarten" bitboards, for which I just need to extract the relevant occupancy, which is doable without using a multiply. Still, for (very) large boards it's probably better to not use a lookup table at all but use some kind of floodfill technique.

[Rein Halbersma]

In Sjaak I have two move generators (actually, two of everything), one operating on 8x8 boards stored in a uint64_t, and one operating on a uint128_t (which I think is a GCC extension). It works, but it's extremely ugly that almost everything is if (small board) { 64 bit stuff } else { equivalent 128 bit stuff }.
So I rewrote the move generator last year using C++ templates. It now does boards based on 16, 32, 64 and 128 bit integers transparently. I have yet to port the rest of the program over though, which is the boring part: writing the general move generator was fun.

I don't do magic move generation though, but I use what CPW calls "kindergarten" bitboards, for which I just need to extract the relevant occupancy, which is doable without using a multiply. Still, for (very) large boards it's probably better to not use a lookup table at all but use some kind of floodfill technique.

Hopefully, this Spring gcc 4.9 will come out with support for the features that I require (constexpr in particular). If you are interested, I can see if I can get my bitboard class to work in your engine then.

[Rebel]

I'm starting to be bored of developing DiscoCheck:

• As with any advanced program, I only use my brain only 1% of the time, and the remaining 99% I use time and electricity...

I share the sentiment, nowadays development (although responsible for hundreds of elo) is boring indeed.

An alternative is the old (romantic) approach, to improve via hundreds of selected positions your engine performs weak (usually because of missing eval knowledge). Using the strategic testset from Swamithan would be a good starting point.

But it will cost you elo points.