Big new ideas in chess programming

[rtitle]

re: "Sorry, I meant Monte-Carlo based approaches, like those used in Go."

Thanks for the clarification. I don't know much about Monte-Carlo approaches, or about Go engines, so I can't comment in detail. Generally I don't like randomness though. I don't even like transposition tables in chess engines because of the random nature of what gets stored (i.e. it depends on your hash function and where collisions occur). I'm tinkering with storing explicit sub-trees instead, in my work-in-progress engine...

Rich

[Uri Blass]

Here is my take on it. Stockfish is strong primarily due to Tord's initial contribution and then later by Marco and Joona in no particular order. Look who is listed when you type "uci."

Almost one year ago, when Gary presented his testing framework I said this was a milestone due to enabling open development. You joked saying "please, let me be in the known" because you thought the achievement was the hardware part, not the open development one, and the hardware part was not a novelty (Crafty has used big hardware for testing since always).

Now, after almost one year, you still have not seen the light , you still think is the hardware...but is not. It is the people, not the hardware.

The hardware is instrumental in enabling a very resource consuming testing procedure that allows the people to fail safely.

And it is because the people can fail safely that we have many people, writing many patches and as a result we have a sustained small flow of good stuff filtered out from the cruft.

Modern engines are all about statistics, their behaviour and strength is all based on statistical rules (see LMR), now we have seen that also engine development is in some way a statistical game, and in this game to have many people playing around is a huge bonus as long as you are able to filtered out the few good shots.

That is not possible without a lot of hardware. So you could have a lot of people contributing ideas and testing on a single quad but only the hardware makes it possible to get to those idea's in a timely fashion.

It is the people, not the hardware ! ....perhaps it will be the 2014 the year when you'll come in the known.

You should at least consider adding the name of the biggest contributors to the list of authors. The program announces only the 3 of you as authors - so if the people are the most important thing why don't they get to be considered authors? Would they have to fork to get their names stamped on the program?

As one of the contributors
I agree with the opinion that the hardware is the important part.

Note that I do not understand most of the stockfish code and I guess that it is the same for at least part of the other contributors.
There are many ideas that I did not try because of not understanding how to implement them in the code.

When you test some idea in komodo you have the relative advantage of understanding the code.

[Masta]

Hardwares don´t have ideas.

For me Marco is right. The most important is the people involved. A good leader, a good system is important too.

The hardware and all the system created is in fact possible, made it cheaper, due to the number of people available to lend a bit of their energy in form of hardware or ideas.

For me Don just refuses to see the truth due to his pride. Understandable, we are just humans.

[lucasart]

Here is my take on it. Stockfish is strong primarily due to Tord's initial contribution and then later by Marco and Joona in no particular order. Look who is listed when you type "uci."

Almost one year ago, when Gary presented his testing framework I said this was a milestone due to enabling open development. You joked saying "please, let me be in the known" because you thought the achievement was the hardware part, not the open development one, and the hardware part was not a novelty (Crafty has used big hardware for testing since always).

Now, after almost one year, you still have not seen the light , you still think is the hardware...but is not. It is the people, not the hardware.

The hardware is instrumental in enabling a very resource consuming testing procedure that allows the people to fail safely.

And it is because the people can fail safely that we have many people, writing many patches and as a result we have a sustained small flow of good stuff filtered out from the cruft.

Modern engines are all about statistics, their behaviour and strength is all based on statistical rules (see LMR), now we have seen that also engine development is in some way a statistical game, and in this game to have many people playing around is a huge bonus as long as you are able to filtered out the few good shots.

That is not possible without a lot of hardware. So you could have a lot of people contributing ideas and testing on a single quad but only the hardware makes it possible to get to those idea's in a timely fashion.

It is the people, not the hardware ! ....perhaps it will be the 2014 the year when you'll come in the known.

You should at least consider adding the name of the biggest contributors to the list of authors. The program announces only the 3 of you as authors - so if the people are the most important thing why don't they get to be considered authors? Would they have to fork to get their names stamped on the program?

Everyone is important:
* Gary's framework obviously. Mostly Gary's work, but Marco also participates in the developpement of this great tool.
* People who write code patches. Even people who write patches that fail are important, and often overlooked. Often ideas derive from observing other people's testing results. This is very important, and there's no way a single person, however clever he may be, could generate that many ideas by himself.
* People who donate their CPU time. Without them none of this would be possible.

I don't think it's a good idea to add people to be copyright holders:
* it would trigger some unnecessary politics.
* it would make the "id author" command too long for GUI to display.

On the contrary, I would advocate to *remove* the current authors from the copyright notice, and surrender the copyrights to the FSF. Many free programs do that, because it makes the GPL easier to enforce. A notorious example is Fruit. Of course, this would require approval of the copyrights holders.

That being said, a list of *all* contributors could be mentionned in a readme file or something like that. All is better than selected few, as it avoids the politics.

[syzygy]

I don't think it's a good idea to add people to be copyright holders:

Those who contribute code ARE copyright holders, whether their names are added or not.

On the contrary, I would advocate to *remove* the current authors from the copyright notice, and surrender the copyrights to the FSF.

That would have no purpose whatsoever and create a huge administrative mess, because now *all* contributors would have to sign away their rights first. That would be not exactly be an invitation to contribute, I would think.

And should you succeed in getting all those who have contributed to sign the necessary papers, the FSF would suddenly be in control. Why would anyone trust the FSF? They could suddenly decide to change the license to GPLv17 with weird new restrictions and e.g. forbid new Stockfish releases for "non-free" devices (e.g. running iOS).

I'm reasonably sure that Fabien Letouzey did not fully realise the implications of him transferring the copyright on Fruit to the FSF.

[michiguel]

Hardwares don´t have ideas.

...and ideas on paper and pencil won't go anywhere, either. I find this discussion like the chicken and the egg problem. No solution, and not really interesting to find why.

Having a lot of people or not is not the point, I think. Having a big set of modifications to test in an organized environment with a lot of computing time is the key. Whether those modifications come from one person or 1000 is not relevant. Of course, more people, more chances to get more modifications, but the question is where the bottleneck is. Number of modifications generated? or testing resources?

If you multiply the number of contributors x100, will you speed up the process? maybe if each contributor comes with more hardware. Otherwise, there will be a pile of testing to be done.

This looks like a gigantic human "simulated annealing" experiment trying to get out of a local minimum? or more hands to help to converge faster to that minimum? Interesting experiment per se.

Miguel

For me Marco is right. The most important is the people involved. A good leader, a good system is important too.

The hardware and all the system created is in fact possible, made it cheaper, due to the number of people available to lend a bit of their energy in form of hardware or ideas.

For me Don just refuses to see the truth due to his pride. Understandable, we are just humans.

[Michel]

You should at least consider adding the name of the biggest contributors to the list of authors. The program announces only the 3 of you as authors - so if the people are the most important thing why don't they get to be considered authors? Would they have to fork to get their names stamped on the program?

The author names can be extracted from the git log.

https://github.com/mcostalba/Stockfish/commits/master

Again the beauty of open source!

[lucasart]

You should at least consider adding the name of the biggest contributors to the list of authors. The program announces only the 3 of you as authors - so if the people are the most important thing why don't they get to be considered authors? Would they have to fork to get their names stamped on the program?

The author names can be extracted from the git log.

https://github.com/mcostalba/Stockfish/commits/master

Again the beauty of open source!

And here's how to extract them:

Code: Select all

$ git log --format='%aN' | sort -u
Alexander Kure
Andy Duplain
Auguste Pop
Balint Pfliegel
Chris Caino
Dan Schmidt
Dariusz Orzechowski
Daylen Yang
Eelco de Groot
Gary Linscott
Hiraoka Takuya
homoSapiensSapiens
Jean-Francois Romang
jhellis3
Joona Kiiski
Joseph R. Prostko
jundery
Justin Blanchard
Kojirion
Leonid Pechenik
Linus Arver
Lucas Braesch
Marco Costalba
Ralph Stößer
Reuven Peleg
Ryan Schmitt
Ryan Takker
thaspel
Tom Vijlbrief
Tord Romstad
Uri Blass

So there are lots of people out there, as you can see