TalkChess.com

Ferdy wrote:

CRoberson wrote:The 2011 Fifth Annual ACCA World Computer Rapid Chess Championships is tentatively scheduled for the weekend of July 23/24 2011. It is tentative only to give others a chance to tell me of a serious timing conflict. After looking around the usual tournaments, I couldn't find a conflict.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I will have the web pages up this week. You can respond here or PM me if you have any questions, comments or requests.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I changed binary almost every after game, to adjust time control codes and adjust evaluation values. In this case I have to send everytime I change binary.

Just a suggestion, organizer to request source codes of engines (not necessarily all participants). Commecial engines are optional, good if they submit source codes (understandable product protection). Organizer to identify and inform paticipants of the person who knows the submitted source codes.
One person is probably enough as a source code reviewer (the only person who knows the source code). It is up to the reviwer wether engine will ultimately enter the tournament. It is also helpful if reviewer informs participants of what is allowed and not allowed although it is really up to him to decide (participants should just trust this person).

bob wrote:

Ferdy wrote:

CRoberson wrote:The 2011 Fifth Annual ACCA World Computer Rapid Chess Championships is tentatively scheduled for the weekend of July 23/24 2011. It is tentative only to give others a chance to tell me of a serious timing conflict. After looking around the usual tournaments, I couldn't find a conflict.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I will have the web pages up this week. You can respond here or PM me if you have any questions, comments or requests.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I changed binary almost every after game, to adjust time control codes and adjust evaluation values. In this case I have to send everytime I change binary.

Just a suggestion, organizer to request source codes of engines (not necessarily all participants). Commecial engines are optional, good if they submit source codes (understandable product protection). Organizer to identify and inform paticipants of the person who knows the submitted source codes.
One person is probably enough as a source code reviewer (the only person who knows the source code). It is up to the reviwer wether engine will ultimately enter the tournament. It is also helpful if reviewer informs participants of what is allowed and not allowed although it is really up to him to decide (participants should just trust this person).

Here's another suggestion. Do _not_ change your program between rounds. You introduce more bugs than you fix. From someone that has been doing this a _long_ time...

Ferdy wrote:

bob wrote:

Ferdy wrote:

CRoberson wrote:The 2011 Fifth Annual ACCA World Computer Rapid Chess Championships is tentatively scheduled for the weekend of July 23/24 2011. It is tentative only to give others a chance to tell me of a serious timing conflict. After looking around the usual tournaments, I couldn't find a conflict.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I will have the web pages up this week. You can respond here or PM me if you have any questions, comments or requests.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I changed binary almost every after game, to adjust time control codes and adjust evaluation values. In this case I have to send everytime I change binary.

Just a suggestion, organizer to request source codes of engines (not necessarily all participants). Commecial engines are optional, good if they submit source codes (understandable product protection). Organizer to identify and inform paticipants of the person who knows the submitted source codes.
One person is probably enough as a source code reviewer (the only person who knows the source code). It is up to the reviwer wether engine will ultimately enter the tournament. It is also helpful if reviewer informs participants of what is allowed and not allowed although it is really up to him to decide (participants should just trust this person).

Here's another suggestion. Do _not_ change your program between rounds. You introduce more bugs than you fix. From someone that has been doing this a _long_ time...

Witnessing an engine play for the whole game is one of the best way to catch obvious bugs and suspect engine behaviour. I was only fixing the obvious. I run the fixed version in another computer for a verification of the fix, while the buggy engine was still playing. I recheck code related to suspect engine behaviour a day after.

bob wrote:

Ferdy wrote:

bob wrote:

Ferdy wrote:

CRoberson wrote:The 2011 Fifth Annual ACCA World Computer Rapid Chess Championships is tentatively scheduled for the weekend of July 23/24 2011. It is tentative only to give others a chance to tell me of a serious timing conflict. After looking around the usual tournaments, I couldn't find a conflict.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I will have the web pages up this week. You can respond here or PM me if you have any questions, comments or requests.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I changed binary almost every after game, to adjust time control codes and adjust evaluation values. In this case I have to send everytime I change binary.

Just a suggestion, organizer to request source codes of engines (not necessarily all participants). Commecial engines are optional, good if they submit source codes (understandable product protection). Organizer to identify and inform paticipants of the person who knows the submitted source codes.
One person is probably enough as a source code reviewer (the only person who knows the source code). It is up to the reviwer wether engine will ultimately enter the tournament. It is also helpful if reviewer informs participants of what is allowed and not allowed although it is really up to him to decide (participants should just trust this person).

Here's another suggestion. Do _not_ change your program between rounds. You introduce more bugs than you fix. From someone that has been doing this a _long_ time...

Witnessing an engine play for the whole game is one of the best way to catch obvious bugs and suspect engine behaviour. I was only fixing the obvious. I run the fixed version in another computer for a verification of the fix, while the buggy engine was still playing. I recheck code related to suspect engine behaviour a day after.

I have been playing in computer chess events since 1976. I can guarantee you that more games have been lost by bugs introduced between rounds than for any other single reason. I've not fallen into this trap in 20 years. I do my development somewhat like the Linux (or other) projects. A month or so before a tournament, we freeze new changes. At the 2 week mark, we freeze any tuning or adjustments we are working on. From that point to the tournament, the only changes that get in are those that fix actual bugs that pose a significant risk. As a result, you don't see Crafty crashing, or doing other silly things, due to last-minute changes. Being bug free is just as important as being good...

bob wrote:

Ferdy wrote:

bob wrote:

Ferdy wrote:

CRoberson wrote:The 2011 Fifth Annual ACCA World Computer Rapid Chess Championships is tentatively scheduled for the weekend of July 23/24 2011. It is tentative only to give others a chance to tell me of a serious timing conflict. After looking around the usual tournaments, I couldn't find a conflict.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I will have the web pages up this week. You can respond here or PM me if you have any questions, comments or requests.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I changed binary almost every after game, to adjust time control codes and adjust evaluation values. In this case I have to send everytime I change binary.

Just a suggestion, organizer to request source codes of engines (not necessarily all participants). Commecial engines are optional, good if they submit source codes (understandable product protection). Organizer to identify and inform paticipants of the person who knows the submitted source codes.
One person is probably enough as a source code reviewer (the only person who knows the source code). It is up to the reviwer wether engine will ultimately enter the tournament. It is also helpful if reviewer informs participants of what is allowed and not allowed although it is really up to him to decide (participants should just trust this person).

Here's another suggestion. Do _not_ change your program between rounds. You introduce more bugs than you fix. From someone that has been doing this a _long_ time...

Witnessing an engine play for the whole game is one of the best way to catch obvious bugs and suspect engine behaviour. I was only fixing the obvious. I run the fixed version in another computer for a verification of the fix, while the buggy engine was still playing. I recheck code related to suspect engine behaviour a day after.

I have been playing in computer chess events since 1976. I can guarantee you that more games have been lost by bugs introduced between rounds than for any other single reason. I've not fallen into this trap in 20 years. I do my development somewhat like the Linux (or other) projects. A month or so before a tournament, we freeze new changes. At the 2 week mark, we freeze any tuning or adjustments we are working on. From that point to the tournament, the only changes that get in are those that fix actual bugs that pose a significant risk. As a result, you don't see Crafty crashing, or doing other silly things, due to last-minute changes. Being bug free is just as important as being good...

bob wrote:

hgm wrote:How could it be guaranteed that what the participants submit is actually the binary they use?

Would it be an idea to let the organizers pack the submitted binaries into a 'wrapper' that would kibitz some ID tag derived from each move (through an algorithm only know to the organizers)? And then send the thus modified binary back to the user, so he could use it during the tournament?

We've had this discussion within the ICGA investigation. The binary has to be validated during the event by running it on a few positions and comparing the output to the kibitzed scores during the game. Otherwise, as you point out, it would be worthless and could be a binary of anything.

michiguel wrote:

bob wrote:

Ferdy wrote:

bob wrote:

Ferdy wrote:

CRoberson wrote:The 2011 Fifth Annual ACCA World Computer Rapid Chess Championships is tentatively scheduled for the weekend of July 23/24 2011. It is tentative only to give others a chance to tell me of a serious timing conflict. After looking around the usual tournaments, I couldn't find a conflict.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I will have the web pages up this week. You can respond here or PM me if you have any questions, comments or requests.

The time control and rules are mostly as they have been. The only change may be that all participants provide a binary of the version entering. This is for tracking purposes and ease of catching clones. I haven't completely decided on that rule yet. It is open for discussion.

I changed binary almost every after game, to adjust time control codes and adjust evaluation values. In this case I have to send everytime I change binary.

Just a suggestion, organizer to request source codes of engines (not necessarily all participants). Commecial engines are optional, good if they submit source codes (understandable product protection). Organizer to identify and inform paticipants of the person who knows the submitted source codes.
One person is probably enough as a source code reviewer (the only person who knows the source code). It is up to the reviwer wether engine will ultimately enter the tournament. It is also helpful if reviewer informs participants of what is allowed and not allowed although it is really up to him to decide (participants should just trust this person).

Here's another suggestion. Do _not_ change your program between rounds. You introduce more bugs than you fix. From someone that has been doing this a _long_ time...

Witnessing an engine play for the whole game is one of the best way to catch obvious bugs and suspect engine behaviour. I was only fixing the obvious. I run the fixed version in another computer for a verification of the fix, while the buggy engine was still playing. I recheck code related to suspect engine behaviour a day after.

I have been playing in computer chess events since 1976. I can guarantee you that more games have been lost by bugs introduced between rounds than for any other single reason. I've not fallen into this trap in 20 years. I do my development somewhat like the Linux (or other) projects. A month or so before a tournament, we freeze new changes. At the 2 week mark, we freeze any tuning or adjustments we are working on. From that point to the tournament, the only changes that get in are those that fix actual bugs that pose a significant risk. As a result, you don't see Crafty crashing, or doing other silly things, due to last-minute changes. Being bug free is just as important as being good...

I think it is even more important to be lucky

Miguel

CThinker wrote:

bob wrote:

hgm wrote:How could it be guaranteed that what the participants submit is actually the binary they use?

Would it be an idea to let the organizers pack the submitted binaries into a 'wrapper' that would kibitz some ID tag derived from each move (through an algorithm only know to the organizers)? And then send the thus modified binary back to the user, so he could use it during the tournament?

We've had this discussion within the ICGA investigation. The binary has to be validated during the event by running it on a few positions and comparing the output to the kibitzed scores during the game. Otherwise, as you point out, it would be worthless and could be a binary of anything.

Does Charles have a comparable hardware that the Rybka or Sjeng cluster use? Unless he has, then no real validation will happen.