A paper about parameter tuning

[Tord Romstad]

If we _distribute_ or _release_ the derived tunable version of SF we have to release with sources. But GPL does not forbids anybody to modify and keep for it's internal use the modified code.

Moreover, we are the copyright holders, and can do whatever we like with the source code. The GPL license applies to users of the software, not to the original authors. We could even make the next version closed source, if we wanted (but of course, we don't).

[diep]

If we _distribute_ or _release_ the derived tunable version of SF we have to release with sources. But GPL does not forbids anybody to modify and keep for it's internal use the modified code.

Moreover, we are the copyright holders, and can do whatever we like with the source code. The GPL license applies to users of the software, not to the original authors. We could even make the next version closed source, if we wanted (but of course, we don't).

Without saying i agree with anything that Marco Costalba / Pradu Kannan wrote, why do you release a version of stockfish source code that obviously is completely different than the versions you have on the cluster to tune?

As Marco/Pradu will have to do a lot of effort to maintain a bunch of code branches.

Vincent

[Aaron Becker]

If we _distribute_ or _release_ the derived tunable version of SF we have to release with sources. But GPL does not forbids anybody to modify and keep for it's internal use the modified code.

Moreover, we are the copyright holders, and can do whatever we like with the source code. The GPL license applies to users of the software, not to the original authors. We could even make the next version closed source, if we wanted (but of course, we don't).

Without saying i agree with anything that Marco Costalba / Pradu Kannan wrote, why do you release a version of stockfish source code that obviously is completely different than the versions you have on the cluster to tune?

As Marco/Pradu will have to do a lot of effort to maintain a bunch of code branches.

Vincent

Didn't Marco just explain this? They're maintaining separate versions to avoid disclosing their tuning methodology.

[diep]

If we _distribute_ or _release_ the derived tunable version of SF we have to release with sources. But GPL does not forbids anybody to modify and keep for it's internal use the modified code.

Moreover, we are the copyright holders, and can do whatever we like with the source code. The GPL license applies to users of the software, not to the original authors. We could even make the next version closed source, if we wanted (but of course, we don't).

Without saying i agree with anything that Marco Costalba / Pradu Kannan wrote, why do you release a version of stockfish source code that obviously is completely different than the versions you have on the cluster to tune?

As Marco/Pradu will have to do a lot of effort to maintain a bunch of code branches.

Vincent

Didn't Marco just explain this? They're maintaining separate versions to avoid disclosing their tuning methodology.

Tord obviously is not a psychopath, i met him in real life. He's a nice normal person who is old fashioned in behaviour and modern in relationships. So i asked HIM the question.

Am i making myself clear?

Thanks,
Vincent

[mcostalba]

As Marco/Pradu will have to do a lot of effort to maintain a bunch of code branches.

Marco/Pradu uses git merge ( http://www.kernel.org/pub/software/scm/ ... merge.html ) to almost effortless keep in sync the two development branches.

With this info that Marco/Pradu gave to you for free, Marco/Pradu expects you buy him a beer

[diep]

As Marco/Pradu will have to do a lot of effort to maintain a bunch of code branches.

Marco/Pradu uses git merge ( http://www.kernel.org/pub/software/scm/ ... merge.html ) to almost effortless keep in sync the two development branches.

With this info that Marco/Pradu gave to you for free, Marco/Pradu expects you buy him a beer

We use SVN.

[mcostalba]

We use SVN.

git is better, especially for merges and code shuffles (pick stuff from one branch and commit in another).

[Aaron Becker]

We use SVN.

git is better, especially for merges and code shuffles (pick stuff from one branch and commit in another).

I have to agree, git is pretty great. SVN is ok though; certainly a big step up from CVS.

[diep]

We use SVN.

git is better, especially for merges and code shuffles (pick stuff from one branch and commit in another).

I have to agree, git is pretty great. SVN is ok though; certainly a big step up from CVS.

I have GIT of course installed on my windows box, it looks very amateuristic (sorry Linus) under windows. Really total amateuristic.

SVN is the choice of the GUI project team, i'm not capable of any comments with respect to SVN. On the command line i'm not too impressed by it to be honest.

Thanks,
Vincent

[Dann Corbit]

Sorry for the selective snipping...

In chess engines testing numbers are more important then ideas (because they require much longer times to get properly), and much more important then struggle to be the first. In your paper experimental data is small, not clearly documented and too focused on the attempted direction.

Do i read this correct you say that persons who test things are more important than persons who have ideas?

Please confirm if so.

Vincent

It seems to me that you cannot make any progress at all, unless you have both people with new ideas and people who test things.

Of course, it is possible for one person to do both tasks admirably well, given the proper resources.