Looking for C developper

[mvk]

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.

I think the trick to keep it interesting is to focus on a niche: At 1elo progress / 4 hours effort, my rate, a 300 elo gap is way too frustrating. So do something different from the others and try to become good at that. Much more satisfying.

[tttony]

Come on Lucas!

The new DiscoCheck 5.2 its 2900+ in CCRL 40/40

Why make another engine?
Why do you want to be on top? Now your engine it's one of the top, it's not easy but nothing is easy

Take that energy to DiscoCheck, you know that it will the same as DiscoCheck dev, take a break, you can make a new version every six months or something like that, but doing another engine you will fall in an infinite loop

Don't be anxious, the (money+time+test) are not very well syncronised, just keep on work!!

[lucasart]

Come on Lucas!

The new DiscoCheck 5.2 its 2900+ in CCRL 40/40

Why make another engine?
Why do you want to be on top? Now your engine it's one of the top, it's not easy but nothing is easy

Take that energy to DiscoCheck, you know that it will the same as DiscoCheck dev, take a break, you can make a new version every six months or something like that, but doing another engine you will fall in an infinite loop

Don't be anxious, the (money+time+test) are not very well syncronised, just keep on work!!

You don't seem to understand. DiscoCheck 5.2 is discontinued. I will not write a single line of code on this code base. Not even bug fixes.

I've been taking a step back and asking myself this question: why do I continue to do chess programming? And the answer is NOT, because I want to be on top of the rating list. From the way you see things, I guess you've never written a chess program, so let me tell you how it works:

1/ first you write a fully fledged program from the ground up. this is an enormous amount of work, even for a skilled programmer (that I am NOT), and there is a lot to learn in the process (much more than by tuning an existing program). This is the interesting part that provides most of the intellectual challenge.

2/ then you improve your program, fix bugs, and fine tune it to gain ELO. This step is, by definition, infinite. Yet my interest and patience are finite. And this step has ever diminishing returns, both in terms of intellectual satisfcation and ELO gain.

I decided to make DiscoCheck an open source project, right from the start. I am not interested in money (and even if I was I would have to be really foolish to believe I can make a living of it, that's another topic). And I am not interested in "fame". Really "fame" is limited to a small population of talkchess geeks to start with. And the wrong subpopulation of it. If DiscoCheck was 200-300 elo stronger, all I would gain is more and more people sending my emails to request new features, ask my why "DiscoCheck is so stupid and play a wrong move here" and so on. I have no interest or patience to deal with that. It's not the reason I started an open source project.

The reason I started an open source project, is to build something bigger than myself. Something that will outlive me in the sense that other people will continue to develop it when I am bored of chess programming. So far, I have not seen anyone show interest in DiscoCheck's source code (apart from a few trolls looking for something there to wage a clone war). No one has ever forked my project on github or sent me a pull request. Basically no one cares about DiscoCheck, except myself, and those people (chess fans) I least want involved.

It would be far more interesting to co-develop a program with someone like minded, and a skilled programmer who could teach me things and we could develop some interesting ideas of our own, etc. This is not going to happen, as for 4 years, no one has shown any interest in the DiscoCheck source code, either for contributing (pull request) or writing their own DiscoCheck derivative. In other words, DiscoCheck is a complete failure as an open source project.

I know there's Stockfish, and I could push more patches in FishTest. But I am also bored of this. It's the same ratio 1% coding 99% waiting, with the added annoyance of the forum being spammed to death by non programmers. And more importantly, SF is so advanced that all the design is there and it's better than what I ever could do myself, so I can't really change anything beyond writing trivial patches. So really nothing interesting programming-wise.

In other words, unlike someone is willing to co-develop DiscoCheck with me, I will retire from computer chess. There are far more important things in life. And even in the programming world, there are far more interesting things to do. For example, I could learn Go (the board game) and Go (the programming language) and write a concurrent Go program, just so I can call it GoGo (or someone has already done it?). Now that would be a real challenge.

[kinderchocolate]

Lucas,

I understand your frustration. But to get more feedback on your works, your work will have to be more useful to the public. My open source project is simple, but it's extremely popular.

Lucas, I'm interested in co-writing the code with you. However, I'd want to use C++ as much as possible.

[tpetzke]

So do something different from the others and try to become good at that. Much more satisfying.

+1

[Henk]

If you can invent a new idea for a chess program that gives 80 ELO or more that may be a challenge too. But that may be too difficult.

[hgm]

In other words, unlike someone is willing to co-develop DiscoCheck with me, I will retire from computer chess. There are far more important things in life. And even in the programming world, there are far more interesting things to do. For example, I could learn Go (the board game) and Go (the programming language) and write a concurrent Go program, just so I can call it GoGo (or someone has already done it?). Now that would be a real challenge.

I completele agree with your analysis. The only critical note is that of course all this could have been foreseen even before you started. If there is one thing the world doesn't need it is another Chess engine, least of all another open-source Chess engine. Especially if it is just 'more of the same', using all the proven techniques. Only if you could do something radically different, and show that it is competitive, you could have any impact. But this is an almost impossible task in any area of technology. Stirling (hot-air) engines in theory are superior to internal-combustion engines, but the latter are so well developed that there is no hope the Stirling engine can ever close the gap. Fused silica is not theoretically the best medium for making optical transmission fibers, but by now we are so much better purifying it than for any theoretically superior material, that the latter will never catch up. And in Chess programming it is not different. The current top engines are unlikely to have the best possible search, and the best possible board representation. But they are so well tuned to get the best out of what they have, that any better concept will not be able to outperform them without an excessive amount of tuning.

In Go at least things are still happening. For me, switching to Go seemed too drastic a step, as I don't understand that game at all. After all, I do have a Chess background. But there are plenty of interesting games closer to Chess than Go, which still pose real problems that are begging for creative solutions. Where the performance depends much more on how you address these problems than on excessive tuning.

[PK]

as for criteria of being interested in DiscoCheck, You have omitted another one:

Rodent 1.3, perft.c, line 50, benchmark code:

Code: Select all

// test positions taken from DiscoCheck by Lucas Braesch

Rodent 1.3, search.c, line 363 onwards:

Code: Select all

  // EVAL PRUNING (aka "post futility pruning", inspired by DiscoCheck by Lucas Braesch) 
  if ( depth <= 3*ONE_PLY
  &&   flagCanPrune&#41; &#123;
	 if &#40;nodeEval == INVALID&#41; nodeEval = Eval.ReturnFast&#40;p&#41;;
	 int evalMargin = 40 * depth;
	 if &#40;nodeEval - evalMargin >= beta&#41;
		return nodeEval - evalMargin;
  &#125; // end of eval pruning code

+ a note on GitHub that method of scoring hanging pieces is modelled after Your code.

Unfortunately I'm not the kind of co-programmer You are looking for: mediocre skills, opposing philosophy (can't refrain from adding knowledge).

[Evert]

Ok, I may be taking leave of my senses, because god knows where I'll find the time, but I'm willing to give cooperating on a from-scratch program a go. But before I go into more details here, let me share something about my experience with open source projects.

A common mis-conception is that people will be interested in contributing to them. This is generally speaking not how it goes. What happens is that there is a core group of developers (where a group of 1 is also considered a group) who care enough to do the work of maintaining and updating the code and add new features. If enough people care about the software, they'll submit bug reports or feature requests. What they will typically not provide is working patches. On a library that I spend time on and off co-developing (more off than on, for the past couple of years) I once told people to either help (by submitting patches) or stop complaining about features they'd like to see included that aren't there.

This is the harsh reality of open source software: it needs a core developer driven enough to keep the project going, and maybe, maybe the project can attract enough interest from others to build up more of a team and ensure some continuity and keep things going when the main developer eventually gets bored. However, you do need to be able to motivate yourself sufficiently to keep going. Perhaps it's enough to just not care that it'll take you three years to add feature X rather than the two weeks it would take if you had one or two people with more time to help you.

Now, about this new from-scratch engine, something that needs to be decided up-front: what is the goal? Writing a from-scratch chess engine can't be it, since you've done it (and I've done it, five times already in fact, in the past 20 years). Writing the strongest engine in the world can't be it, since that's a moving target that will take an insane effort to catch. Writing a clean, easy to understand and modify engine that is "reasonably strong" (a vague term that needs defining) and that can serve as a base for other programs could be. I do have to say that this community has some pretty funny ideas about "original" programs, forks of other programs, "derivatives", "clones" or "from scratch" programs, and discussions can get pretty heated (and pointless). That's something to bear in mind if you're writing something with the purpose that others derive new programs from it.

Now, what are some of the things that I would like to see in a project like this?

• Parallel search, from day 1. This impacts the overall design of the datastructures. Of course, making it efficient is something that needs to happen incrementally. Optimal parallel search for an engine that has a minimalistic evaluation and no or poorly implemented reductions will (probably) not be an optimal search for an engine with a balanced and well-tuned evaluation and a good single-threaded search.
• A design that will naturally and easily lend itself to playing chess variants. This can take various forms. If limited to "standard" chess pieces, this could include things like atomic (different capture rules), losers/giveaway (very different evaluation weights), Fischer Random, Bughouse and Crazyhouse. I'm more interested in variants with "fairy pieces", but that forces you to make a few design decisions early on: how many fairy pieces will you support? Are they fixed or arbitrary? Can pieces be asymmetric? Can the king be different from the "standard" king? Can the pawns? What about promotion options? In normal chess, you need 6+6=12 bits to encode from/to squares, and 2 bits to encode promotion choices, giving you 14 bit in total, which fits into a standard 16 bit integer and leaves you 2 bits for other information (castling flag, say). If you have more piece types, this may not fit and you'll need to use a 32 bit integer. But then, you can store loads more stuff as well (the piece type, for instance, so you don't need to look that up on the board). This affects the data structures needed, as well as how you write the evaluation (it needs to be scalable to adding additional pieces). Can the board be different from 8x8? Can the topology be different from a square (say, a cylinder)?
  
  Personally, I would suggest a plain 8x8 board, and just add support, or at least the ability to support, a range of different fairy pieces (say, Archbishop, Chancellor/Marshal, Ferz, Elephant, Silver general, Berolina pawns) and rule extensions (atomic captures, giveaway, piece drops). That allows for Berolina Chess, Seirawan Chess, Atomic chess, Bug/Crazy house (whichever is the two-player version of the game, I get them mixed up), Giveaway chess, Fischer Random Chess, Makruk and Shatranj, which is a decent enough mix. It doesn't need to play all of them equally well, and Makruk and Shatranj are perhaps more for "because we can" sake (I don't think anyone plays Shatranj anymore).
• Bitboards, optimise for 64 bit machines.

Supporting variants pretty much implies supporting the XBoard protocol, but that's a minor technical detail. It's not very hard to support both protocols.

Now, about myself: I consider myself a decent enough C programmer, but I'm not a programmer by training or profession. I have a job, a family and a social life, and I'm not abandoning any of my other projects, so this will compete for a time-slice there.
(EDIT: oh, regarding chess programming: I've written five programs in all, the first in the mid/late nineties, in a mixture of Pascal and inline x86 assembler, the last three in the last five years, two of which play variants (Sjaak and Leonidas) and one of which I converted to multi-core (Jazz))

If you're still interested in going through with this, the first order of business is to get ourselves organised and hammer out a few details, like immediate goals and programming conventions (CamelCase? lowercase_with_underscores? Indentation style?). This all needs to be written down somewhere, including notes on the design of the various data structures, which include bitboards (uint64_t, I'd say), moves, board, search stack, evaluation, split points etc. If you like I can list what I've found works for me to get started and we can iterate on it to come up with something that works for both of us.

[lucasart]

Ok, I may be taking leave of my senses, because god knows where I'll find the time, but I'm willing to give cooperating on a from-scratch program a go. But before I go into more details here, let me share something about my experience with open source projects.

A common mis-conception is that people will be interested in contributing to them. This is generally speaking not how it goes. What happens is that there is a core group of developers (where a group of 1 is also considered a group) who care enough to do the work of maintaining and updating the code and add new features. If enough people care about the software, they'll submit bug reports or feature requests. What they will typically not provide is working patches. On a library that I spend time on and off co-developing (more off than on, for the past couple of years) I once told people to either help (by submitting patches) or stop complaining about features they'd like to see included that aren't there.

This is the harsh reality of open source software: it needs a core developer driven enough to keep the project going, and maybe, maybe the project can attract enough interest from others to build up more of a team and ensure some continuity and keep things going when the main developer eventually gets bored. However, you do need to be able to motivate yourself sufficiently to keep going. Perhaps it's enough to just not care that it'll take you three years to add feature X rather than the two weeks it would take if you had one or two people with more time to help you.

You seem to have more experience than me in the matter. And you're probably right. I've been a bit naive...

Now, about this new from-scratch engine, something that needs to be decided up-front: what is the goal? Writing a from-scratch chess engine can't be it, since you've done it (and I've done it, five times already in fact, in the past 20 years). Writing the strongest engine in the world can't be it, since that's a moving target that will take an insane effort to catch. Writing a clean, easy to understand and modify engine that is "reasonably strong" (a vague term that needs defining) and that can serve as a base for other programs could be.

Sounds like a plan.

I do have to say that this community has some pretty funny ideas about "original" programs, forks of other programs, "derivatives", "clones" or "from scratch" programs, and discussions can get pretty heated (and pointless). That's something to bear in mind if you're writing something with the purpose that others derive new programs from it.

Engine would be GPL compliant. Nothing less, and nothing more. That means we can use GPL code from other sources if we want. Of course, we would give credit where credit is due. For example, I don't want to waste my time looking for magics. I already have a codebase for that, which I took the from GPL engine Umko (now called MinkoChess), and I see no reason to change it (unless we make a more elegant one, but that's really not where I want to start spending time, more interested in higher level stuff).

Parallel search, from day 1. This impacts the overall design of the datastructures. Of course, making it efficient is something that needs to happen incrementally. Optimal parallel search for an engine that has a minimalistic evaluation and no or poorly implemented reductions will (probably) not be an optimal search for an engine with a balanced and well-tuned evaluation and a good single-threaded search.

Totally agreed. That being said, I have no experience in writing an SMP engine myself. But you have.

A design that will naturally and easily lend itself to playing chess variants. This can take various forms. If limited to "standard" chess pieces, this could include things like atomic (different capture rules), losers/giveaway (very different evaluation weights), Fischer Random, Bughouse and Crazyhouse. I'm more interested in variants with "fairy pieces", but that forces you to make a few design decisions early on: how many fairy pieces will you support? Are they fixed or arbitrary? Can pieces be asymmetric? Can the king be different from the "standard" king? Can the pawns? What about promotion options? In normal chess, you need 6+6=12 bits to encode from/to squares, and 2 bits to encode promotion choices, giving you 14 bit in total, which fits into a standard 16 bit integer and leaves you 2 bits for other information (castling flag, say). If you have more piece types, this may not fit and you'll need to use a 32 bit integer. But then, you can store loads more stuff as well (the piece type, for instance, so you don't need to look that up on the board). This affects the data structures needed, as well as how you write the evaluation (it needs to be scalable to adding additional pieces). Can the board be different from 8x8? Can the topology be different from a square (say, a cylinder)?

Personally, I would suggest a plain 8x8 board, and just add support, or at least the ability to support, a range of different fairy pieces (say, Archbishop, Chancellor/Marshal, Ferz, Elephant, Silver general, Berolina pawns) and rule extensions (atomic captures, giveaway, piece drops). That allows for Berolina Chess, Seirawan Chess, Atomic chess, Bug/Crazy house (whichever is the two-player version of the game, I get them mixed up), Giveaway chess, Fischer Random Chess, Makruk and Shatranj, which is a decent enough mix. It doesn't need to play all of them equally well, and Makruk and Shatranj are perhaps more for "because we can" sake (I don't think anyone plays Shatranj anymore).

I don't know anything about chess variants (except Chess960). But I think we shouldn't goo for too much generality or we risk to never complete the project. Better stay with 8x8 board using bitboards. As for piece types, I would prefer to limit ourselves to normal chess pieces, for simplicity and efficiency. That way move can fit in 16 bits (which is useful for TT). Also, adding "fairy" pieces means we need to go back to computing magics for those

Supporting variants pretty much implies supporting the XBoard protocol, but that's a minor technical detail. It's not very hard to support both protocols.

Yes. XBoard is the only way to go for chess variants (beyond Chess960).

If you're still interested in going through with this, the first order of business is to get ourselves organised and hammer out a few details, like immediate goals and programming conventions (CamelCase? lowercase_with_underscores? Indentation style?). This all needs to be written down somewhere, including notes on the design of the various data structures, which include bitboards (uint64_t, I'd say), moves, board, search stack, evaluation, split points etc. If you like I can list what I've found works for me to get started and we can iterate on it to come up with something that works for both of us.

I will send you a more detailled PM with what I have in mind.