michiguel wrote:
I second Bob's suggestion, but I would not call it draconian if N is reasonable. If is unfortunate, but the connection is part of the "chess entity" that is participating.
In fact, it follows the concept that the operator should have the minimum interference in the game. If the operator "decides" not to claim the win, it is in fact a huge interference, not only in that particular game, but in the whole tournament. It could easily benefit or harm a third party.
Miguel
I have changed the rule to:
Disconnection/Forfeit Rules
1. In the event of a disconnection, the party will be given 10 minutes to return to complete the game; and no more than 2 disconnections per game will be allowed. On the third time, the game will be a forfeit. This is absolute. Under no circumstances will the game continue.
Peter
I think that is a good rule. It avoids the situation where 2 different programs take 15 minutes but one is forfeited and the other isn't and this makes the results rather arbitrary and unfair.
I would suggest that if the next round has already begun it's too late to "notice" that this happened.
Is there a way to quickly determine and check each program before you schedule another round? Can't you grep the logs looking for the key word that represents a disconnection? Maybe the log says something like this: "Program Komodo disconnected" and you can just grep for the string "disconnect"?
I would also suggest that the rule not be based on how many disconnections but the total length of them. It is common when suffering Internet glitches to get several short disconnects then it's ok - not 1 long one. If you disconnect for 3 times but they are only for a few seconds, is it that really big a deal?
I don't know what the logs look like, but I would be willing to write a simple script that would scan them and add up the total length of all the disconnects for each program and also how many disconnects and any other relevant statistics. That would make it trivial for you to handle it. I would of course need an example of the logs where program disconnected.
I don't like the time idea. Allows manipulation of results. If your opponent disconnects, and you are using xboard, your program is terminated and restarted to prepare for the next game. No pondering. Losing hash and everything else. If we allow 10 minutes total time, I could have crafty disconnect right before each move it makes, to kill opponent's ponder hits. And it can reconnect in a fraction of a second since it runs on a gigabit (all the way to internet backbone) connection.
If my program disconnects on the server does it stop your program? The programs are not connected to each other, just to the server, right?
If I am wrong about this then I agree with you - there should be a limit. But I don't think disconnecting affects the other program.
michiguel wrote:
I second Bob's suggestion, but I would not call it draconian if N is reasonable. If is unfortunate, but the connection is part of the "chess entity" that is participating.
In fact, it follows the concept that the operator should have the minimum interference in the game. If the operator "decides" not to claim the win, it is in fact a huge interference, not only in that particular game, but in the whole tournament. It could easily benefit or harm a third party.
Miguel
I have changed the rule to:
Disconnection/Forfeit Rules
1. In the event of a disconnection, the party will be given 10 minutes to return to complete the game; and no more than 2 disconnections per game will be allowed. On the third time, the game will be a forfeit. This is absolute. Under no circumstances will the game continue.
Peter
I think that is a good rule. It avoids the situation where 2 different programs take 15 minutes but one is forfeited and the other isn't and this makes the results rather arbitrary and unfair.
I would suggest that if the next round has already begun it's too late to "notice" that this happened.
Is there a way to quickly determine and check each program before you schedule another round? Can't you grep the logs looking for the key word that represents a disconnection? Maybe the log says something like this: "Program Komodo disconnected" and you can just grep for the string "disconnect"?
I would also suggest that the rule not be based on how many disconnections but the total length of them. It is common when suffering Internet glitches to get several short disconnects then it's ok - not 1 long one. If you disconnect for 3 times but they are only for a few seconds, is it that really big a deal?
I don't know what the logs look like, but I would be willing to write a simple script that would scan them and add up the total length of all the disconnects for each program and also how many disconnects and any other relevant statistics. That would make it trivial for you to handle it. I would of course need an example of the logs where program disconnected.
I don't like the time idea. Allows manipulation of results. If your opponent disconnects, and you are using xboard, your program is terminated and restarted to prepare for the next game. No pondering. Losing hash and everything else. If we allow 10 minutes total time, I could have crafty disconnect right before each move it makes, to kill opponent's ponder hits. And it can reconnect in a fraction of a second since it runs on a gigabit (all the way to internet backbone) connection.
If my program disconnects on the server does it stop your program? The programs are not connected to each other, just to the server, right?
If I am wrong about this then I agree with you - there should be a limit. But I don't think disconnecting affects the other program.
It would not effect Hiarcs if the opponent disconnects it would continue to ponder.
I would think it would be more constructive from your side to lay down a specific case and do let the discussion start. If I have correctly guessed what you are aiming to, it could be an interesting case to open new ground and collect people opinions and sentiments in this point in time, June 2010.
Well my case is this which I repeat:
According to rule 1 in Clone/Derivatives Rules, Stockfish should not be allowed to participate in this tournament, because it contains GPL code from people who are not part of the team. Thus SF is not an original work and it can not participate.
SF does not contain code from any other program, AFAIK. Glaurung does not count because SF is Glaurung. The authors changed the name. Otherwise, my program cannot participate because version 0.75.7 has code from version 0.33.
CC are basically a programmer's competition, not an engine's competition. That is why one author cannot have two entries. Most of the rules derive from this concept.
I still do not see the relationship between the license and these rules.
Miguel
Hint: Not me nor Joona (very probably) have the will to join this tournament, as all the others before BTW. I dont know about Tord, he has been silently in the last weeks, but I guess he will not participate too.
Please do not make it personal. I do not plan to participate in this CCT or other similar events. If I want your permission, or others I would ask for it. Basically I want to encourage interested people to use SF as basis of other works. In this regards, it would be nice to make things clear now, better than later IMO.
1. Each participant (engine) must an original work. No entry can contain code from another program, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
To make my point clear I propose a change like the following:
1. Each participant (engine) must be an original work or a license compliant derivative of an original work. No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
michiguel wrote:
I second Bob's suggestion, but I would not call it draconian if N is reasonable. If is unfortunate, but the connection is part of the "chess entity" that is participating.
In fact, it follows the concept that the operator should have the minimum interference in the game. If the operator "decides" not to claim the win, it is in fact a huge interference, not only in that particular game, but in the whole tournament. It could easily benefit or harm a third party.
Miguel
I have changed the rule to:
Disconnection/Forfeit Rules
1. In the event of a disconnection, the party will be given 10 minutes to return to complete the game; and no more than 2 disconnections per game will be allowed. On the third time, the game will be a forfeit. This is absolute. Under no circumstances will the game continue.
Peter
I think that is a good rule. It avoids the situation where 2 different programs take 15 minutes but one is forfeited and the other isn't and this makes the results rather arbitrary and unfair.
I would suggest that if the next round has already begun it's too late to "notice" that this happened.
Is there a way to quickly determine and check each program before you schedule another round? Can't you grep the logs looking for the key word that represents a disconnection? Maybe the log says something like this: "Program Komodo disconnected" and you can just grep for the string "disconnect"?
I would also suggest that the rule not be based on how many disconnections but the total length of them. It is common when suffering Internet glitches to get several short disconnects then it's ok - not 1 long one. If you disconnect for 3 times but they are only for a few seconds, is it that really big a deal?
I don't know what the logs look like, but I would be willing to write a simple script that would scan them and add up the total length of all the disconnects for each program and also how many disconnects and any other relevant statistics. That would make it trivial for you to handle it. I would of course need an example of the logs where program disconnected.
I don't like the time idea. Allows manipulation of results. If your opponent disconnects, and you are using xboard, your program is terminated and restarted to prepare for the next game. No pondering. Losing hash and everything else. If we allow 10 minutes total time, I could have crafty disconnect right before each move it makes, to kill opponent's ponder hits. And it can reconnect in a fraction of a second since it runs on a gigabit (all the way to internet backbone) connection.
If my program disconnects on the server does it stop your program? The programs are not connected to each other, just to the server, right?
No. The _game_ is stopped and saved in a "to be resumed" state. But when you disconnect, my program is instantly stopped by xboard and the server as the game is no longer in process. You would not want the game to continue if the opponent won't be back until tomorrow, with you sitting all night not playing.
If I am wrong about this then I agree with you - there should be a limit. But I don't think disconnecting affects the other program.
Give it a try. It _instantly_ affects the other program.
1. Each participant (engine) must an original work. No entry can contain code from another program, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
To make my point clear I propose a change like the following:
1. Each participant (engine) must be an original work or a license compliant derivative of an original work. No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
This I do not think will work or be allowed. One team could enter several engines. I could enter 100+ different Hiarcs engines. They would all be slightly different... Or taking your words literally 100+ stockfish or Fruit based programs.
Last edited by Harvey Williamson on Sun Jun 20, 2010 8:04 pm, edited 1 time in total.
michiguel wrote:
I second Bob's suggestion, but I would not call it draconian if N is reasonable. If is unfortunate, but the connection is part of the "chess entity" that is participating.
In fact, it follows the concept that the operator should have the minimum interference in the game. If the operator "decides" not to claim the win, it is in fact a huge interference, not only in that particular game, but in the whole tournament. It could easily benefit or harm a third party.
Miguel
I have changed the rule to:
Disconnection/Forfeit Rules
1. In the event of a disconnection, the party will be given 10 minutes to return to complete the game; and no more than 2 disconnections per game will be allowed. On the third time, the game will be a forfeit. This is absolute. Under no circumstances will the game continue.
Peter
I think that is a good rule. It avoids the situation where 2 different programs take 15 minutes but one is forfeited and the other isn't and this makes the results rather arbitrary and unfair.
I would suggest that if the next round has already begun it's too late to "notice" that this happened.
Is there a way to quickly determine and check each program before you schedule another round? Can't you grep the logs looking for the key word that represents a disconnection? Maybe the log says something like this: "Program Komodo disconnected" and you can just grep for the string "disconnect"?
I would also suggest that the rule not be based on how many disconnections but the total length of them. It is common when suffering Internet glitches to get several short disconnects then it's ok - not 1 long one. If you disconnect for 3 times but they are only for a few seconds, is it that really big a deal?
I don't know what the logs look like, but I would be willing to write a simple script that would scan them and add up the total length of all the disconnects for each program and also how many disconnects and any other relevant statistics. That would make it trivial for you to handle it. I would of course need an example of the logs where program disconnected.
I don't like the time idea. Allows manipulation of results. If your opponent disconnects, and you are using xboard, your program is terminated and restarted to prepare for the next game. No pondering. Losing hash and everything else. If we allow 10 minutes total time, I could have crafty disconnect right before each move it makes, to kill opponent's ponder hits. And it can reconnect in a fraction of a second since it runs on a gigabit (all the way to internet backbone) connection.
If my program disconnects on the server does it stop your program? The programs are not connected to each other, just to the server, right?
If I am wrong about this then I agree with you - there should be a limit. But I don't think disconnecting affects the other program.
It would not effect Hiarcs if the opponent disconnects it would continue to ponder.
A GUI _can_ do this if it wants, it can just ignore the indication from ICC that the game has temporarily ended. And it can ignore the indication from ICC that the game has been re-started as well. But most GUIs do not do this. None I am aware of, in fact. Certainly not xboard that most of us Unix users depend on. I would not want it to behave like that, personally. If a human opponent disconnects and won't return until tomorrow, do I want to not play any more games until he returns?
michiguel wrote:
I second Bob's suggestion, but I would not call it draconian if N is reasonable. If is unfortunate, but the connection is part of the "chess entity" that is participating.
In fact, it follows the concept that the operator should have the minimum interference in the game. If the operator "decides" not to claim the win, it is in fact a huge interference, not only in that particular game, but in the whole tournament. It could easily benefit or harm a third party.
Miguel
I have changed the rule to:
Disconnection/Forfeit Rules
1. In the event of a disconnection, the party will be given 10 minutes to return to complete the game; and no more than 2 disconnections per game will be allowed. On the third time, the game will be a forfeit. This is absolute. Under no circumstances will the game continue.
Peter
I think that is a good rule. It avoids the situation where 2 different programs take 15 minutes but one is forfeited and the other isn't and this makes the results rather arbitrary and unfair.
I would suggest that if the next round has already begun it's too late to "notice" that this happened.
Is there a way to quickly determine and check each program before you schedule another round? Can't you grep the logs looking for the key word that represents a disconnection? Maybe the log says something like this: "Program Komodo disconnected" and you can just grep for the string "disconnect"?
I would also suggest that the rule not be based on how many disconnections but the total length of them. It is common when suffering Internet glitches to get several short disconnects then it's ok - not 1 long one. If you disconnect for 3 times but they are only for a few seconds, is it that really big a deal?
I don't know what the logs look like, but I would be willing to write a simple script that would scan them and add up the total length of all the disconnects for each program and also how many disconnects and any other relevant statistics. That would make it trivial for you to handle it. I would of course need an example of the logs where program disconnected.
I don't like the time idea. Allows manipulation of results. If your opponent disconnects, and you are using xboard, your program is terminated and restarted to prepare for the next game. No pondering. Losing hash and everything else. If we allow 10 minutes total time, I could have crafty disconnect right before each move it makes, to kill opponent's ponder hits. And it can reconnect in a fraction of a second since it runs on a gigabit (all the way to internet backbone) connection.
If my program disconnects on the server does it stop your program? The programs are not connected to each other, just to the server, right?
If I am wrong about this then I agree with you - there should be a limit. But I don't think disconnecting affects the other program.
It would not effect Hiarcs if the opponent disconnects it would continue to ponder.
A GUI _can_ do this if it wants, it can just ignore the indication from ICC that the game has temporarily ended. And it can ignore the indication from ICC that the game has been re-started as well. But most GUIs do not do this. None I am aware of, in fact. Certainly not xboard that most of us Unix users depend on. I would not want it to behave like that, personally. If a human opponent disconnects and won't return until tomorrow, do I want to not play any more games until he returns?
Hiarcs would claim the win when his flag dropped. However I do not like the multiple disconnect rule either. I think the 2 disconnect rule is just fine.
1. Each participant (engine) must an original work. No entry can contain code from another program, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
To make my point clear I propose a change like the following:
1. Each participant (engine) must be an original work or a license compliant derivative of an original work. No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
Don't like that wording. The intent of the rule is "one author, one entry" plain and simple. I do not want to allow entries that copied a "public domain" source as that violates the very idea we are trying to adhere to, "one author, one entry".
1. Each participant (engine) must an original work. No entry can contain code from another program, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
To make my point clear I propose a change like the following:
1. Each participant (engine) must be an original work or a license compliant derivative of an original work. No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.
Don't like that wording. The intent of the rule is "one author, one entry" plain and simple. I do not want to allow entries that copied a "public domain" source as that violates the very idea we are trying to adhere to, "one author, one entry".
