A Crime by a Board of Old Imposters

Sidney Cadot wrote:

Robert Hyatt wrote:

So, if I understand correctly: it is your opinion that the human player
is just an I/O device, but the GUI isn't (it's "part of the same single
entity").

Correct. Just as much as the monitor is a part of the computer player.
Remove the monitor, no game.

I have no issue with the human player being seen as an I/O device. But
to me, it seems natural to see the GUI in the same light.

I think that is a strange position to take. I feel that the GUI is also
just an external I/O device, like the human operator; For most bare
engines, the GUI is driven by a protocol and runs as a separate process.
To me, it's pretty clear who's in charge.

Actually not. Look at the UCI GUI protocol. THe GUI tells the engine
what to search, what to ponder, when to move, etc...

Yes, I've seen the UCI protocol and I think it is flawed in several
ways. Most importantly, it puts some responsibilities for abiding by the
laws of chess with the GUI (most specifically: claiming and offering
draws, detecting end-of-game), that should be with the engine in a
well-designed system. In general, the engine knows much more about chess
than the GUI; it is, too me (and I'm a software engineer by profession)
bizarre to see that this responsibility is left with the GUI.

The xboard spec is better in this respect:

(start quote)

"RESULT {COMMENT}
When your engine detects that the game has ended by rule, your engine
must output a line of the form "RESULT {comment}" (without the quotes),
where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is
the reason. Here "by rule" means that the game is definitely over
because of what happened on the board. In normal chess, this includes
checkmate, stalemate, triple repetition, the 50 move rule, or
insufficient material; it does not include loss on time or the like.
Examples:
0-1 {Black mates}
1-0 {White mates}
1/2-1/2 {Draw by repetition}
1/2-1/2 {Stalemate}


xboard relays the result to the user, the ICS, the other engine in Two
Machines mode, and the PGN save file as required."

(end quote)

Clearly, the engine can end the game with a result command, claiming
draw by repetition or 50-move rule, which is unambiguous. While the
xboard standard leaves much to be desired, this is how it should be.

While technically, the xboard standard can handle this situation quite
well, the wording of this is a bit slippery: "...the game is definitely
over because of what happened on the board. In normal chess, this
includes checkmate, stalemate, triple repetition, the 50 move rule, or
insufficient material"

Of the reasons given, only checkmate, stalemate, and insufficient
material (which is a special case of the rule as given in Article 9.6 of
the Laws of Chess) make that the game is "definitely over". A legal game
can proceed beyond triple repitition and the 50 move rule.

To offer an example (which I brought up recently here):

Suppose the chess engine detects a draw based on Article 9.6 in the
following position (probably no current engine can, but in principle,
it's possible):

8/3k4/8/1pBp1p1p/1P1P1P1P/5b2/2K5/8 w - -

... Now the GUI (with limited chess capability) will surely think the
game is still ongoing. How is an engine using the UCI protocol to notify
the GUI that the game is, in fact, over, with result 1/2-1/2 ?

You pointed out some examples from your own experience where the engine
and the GUI disagreed. What should be the course of action in cases like
that?

Somehow the engine has a concept of "playing a move". With a GUI, that
concept is moving the piece on the graphical chess board. That has to
be the move it plays. In the case of my old experience, the "my move
is B-qb4" was the way to display a move. That was the right thing to
look at.

With all due respect, I disagree.

Should we follow the engine or the GUI? Or should we ask the TD (or toss
a coin)?


The engine hides behind the GUI. You really have little choice.

Sid,
good to know that your name is Sidney and not Jaap, otherwise people would
attend a good demonstrations of the lack of flexibility of Jaap vd Herik.
Smartness often makes circles and this is such a circle here. You simply don't
or won't get it what Bob hyatt is telling you. Reason? Because you have the
prejudice that you want to prove that jaa, the TD, has done a good job. Like
Orof. Ingo Althofer made the brown-nosing commentary that Jaap is the best
possible TD and he should certainly do that same good job next year in
Israel... LOL

Idon't know why but I have a suspicion. For reasons I will keep secret, because
I can't reveil the technology, I think that you are Jaap. I can't help it.

Let me tell you that your position, based on the split between engine and GUI
is completely nonsense. I know that many make the same mistake. But do also
note what Amir has written. You made a decision and then you heard what the
Jonny author said in Graz. Suddenly you knew that you had made a stupid
decision. But - you had declared that the decion "would be a final one"! So by
definition you saw no way out other than leaving the decision untouched.

You see? Your fault is not one out of smartness, lack of smartness. It's
something else. That is psychologically and interesting problem. You were
unable to simply say this:

"Folks, under these aspects now our former decision _of course_ can't be held
up. We must make a new decision. I admit that my fault was, not to talk to
Johannes Zwanzger. Next year I will engage Rolf as my personal psychologist and
consultant."

All the best to you,
Rolf

[Expert for cases where experts are blocked or inhibited because they think
that their correction could cost the whole job.]



It is the engine that's playing chess, not the GUI. Most engines
(including your Crafty) can play an excellent game of chess without a
GUI attached. So, often, you _do_ have a choice.

Best regards,

Sidney

In article ,
(Rolf Tueschen) wrote:


good to know that your name is Sidney and not Jaap, otherwise people would
attend a good demonstrations of the lack of flexibility of Jaap vd Herik.
Smartness often makes circles and this is such a circle here. You simply
don't
or won't get it what Bob hyatt is telling you. Reason? Because you have the
prejudice that you want to prove that jaa, the TD, has done a good job.

Look, Rolf, this is getting boring. Everytime someone says something
that you disagree with, you attack his motives. yet the whole argument
that you are trying to present is an attack on the motives of Jaap. At
least try to be consistent.

If you have arguments, present them. Ad hominem arguments prove nothing.
Personally I don't know any of the people involved, but I know Bob Hyatt
from reading this newsgroup, and I respect him, but like some others, I
happen to disagree with him in this case. In your mind, everyone who
happens to disagree with you is either dishonest or stupid.

Please change the tune.

Henri

darrz wrote:
On Tue, 02 Dec 2003 00:27:35 GMT, "Znarf" wrote:
The ICGA could only access and review the source code upon an accusation of
"cheating." The Accuser must provide a factual basis for the accusation
(e.g., it must be more than "The accused program performed the same two
moves as program x."). This would protect entrants from unfounded
accusations.

Not really. Read your statement again. Where are the facts in the
accusation? What facts can you have as a cc tournament entrant, about
another program?

You have no source code, no performance of the suspect program on any
critical positions or test suites. Nothing!

All you have is a suspicion, based on the play you see the suspect
program make at the tournament WHICH IS ALREADY IN PROGRESS.

Are you going to stop the whole tournament and examine the suspect
program for a few hours? Based on someone's _suspicions_ ??

I don't think there is a good answer anywhere in this rat hole!

You either run the risk of someone cheating and winning a tournament
with a program like Crafty, or you disrupt the tournament and make
unfounded accusations.

I have another idea, which may not be popular, but here goes:

In an open tournament, any program competes. Bring your open source
program, modified or not. You're in like a porch climber!

Open source authors, like Dr. Hyatt, would just need to keep their
strongest version under wraps until after that year's championship.

It seem's odd that someone would make bikes, give them away freely,
and then say "but you can't race with this bike, against me".

the problem with that logic is that the next event will have 1000+
participants, and a Swiss big enough to find the best "program"
will take a long while. I don't see the use in allowing 100 modified
versions of a single program to participate. How would you host an
event with 1000 programs? Where do you find 1000 computers to run it
on? Where do you put 'em?

just having 40 is a big enough problem.


Phooey! Every "bike" can "race" in an open tournament. Every program
can compete with different settings or "personalities" that Joe or
Jill Consumer have discovered, and care to enter into the open
tournament.

If you (as a chess programmer) make your program open source, you need
to make one version stronger than the source you released, and keep it
confidential, to compete with an edge in the next open cc tournament.

Result?

Lots of people make lots of little modifications to Crafty and other
open source chess programs. Most will be bad, but some will be good.
More competitors, more interest in cc, and any good modifications that
prove valuable may expand our knowledge of what makes a stronger chess
program.

Note that I'm not saying anyone has the right to take open source code
and sell it commercially. I'm only saying for an open tournament,
every program, of every type, should be allowed to compete.

That clears the air of any claims of cheating, and is in the true
spirit of an open tournament. IMO


What about pure copies? No changes? What would the point be in
that participating?


It also makes computer chess more interesting, to more people.

If current open source chess program authors are offended by that, I
believe they should not make their program open source, anymore, and
really ask themselves "why did I make this program open source?".


Your thoughts?


Darrz



--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170

On Tue, 2 Dec 2003 14:46:13 +0000 (UTC), Robert Hyatt
wrote:

darrz wrote:
I have another idea, which may not be popular, but here goes:

In an open tournament, any program competes. Bring your open source
program, modified or not. You're in like a porch climber!

Open source authors, like Dr. Hyatt, would just need to keep their
strongest version under wraps until after that year's championship.

It seem's odd that someone would make bikes, give them away freely,
and then say "but you can't race with this bike, against me".

the problem with that logic is that the next event will have 1000+
participants, and a Swiss big enough to find the best "program"
will take a long while. I don't see the use in allowing 100 modified
versions of a single program to participate. How would you host an
event with 1000 programs? Where do you find 1000 computers to run it
on? Where do you put 'em?

just having 40 is a big enough problem.

It may need refinement, but I'd love to see a large participation
especially in a North American chess computer tournament.

As you've mentioned, the tournament could be run on a local net, with
a tournament match software. TD is a human of course, but all the
rules are in the match software, and it runs all matches,
automatically, hopefully with few hiccups.

I don't know about thousands willing to pay some entrance fee,
especially if they have added nothing to the program they're entering.
Seems like the entrance fee covers some expenses, and also serves to
deter the less-than-serious entrants.

Another scenario is to have the preliminary matches on a chess server
on the net (ICC, FICS, whatever). The top 50 (pick a suitable number),
qualify for the championships.


What about pure copies? No changes? What would the point be in
that participating?

Say we had such a tournament next year. You had version 20 of Crafty
under wraps. But others wanted to enter "pure" Crafty ver. 19.7. So we
would see some versions of 19.7, and your new ver. 20, competing
against some altered Crafty ver. 18.3, (whatever), along with other
programs, both altered or pure.

A broader base of interest than we currently have in North America
would be the goal, surely.

Holding a championship tournament in a cave may work in Europe, but we
need all the interest and participation we can muster in the U.S. -
and in a location like Chicago, not the wilds of Canada.

Perhaps the whole tournament needs a different name to let one and all
know that not every entrant is a top chess programmer, and that would
be great to differentiate this type of tournament, from the norm.

If John Doe, a non-programmer from Moscow, Idaho, should win with a
pure copy some year - well, wasn't that lucky AND interesting?!
Odds would be slim, of course.

I don't believe I'd want this to be the ONLY type of tournament, but I
know I don't want a North American tournament run anything _like_ the
WCCC in Graz, (especially with the claim of cheating), and a broader
base of interest would be very helpful.


Darrz

David Richerby wrote:

I think that is a strange position to take. I feel that the GUI is also
just an external I/O device, like the human operator

What you're saying is true but impractical. I agree with you that the GUI
is a distinct piece of software that relays status from the engine, which
plays chess, to the operator, who interfaces with the world. However, if
the rules are to be based on whether the engine or the GUI claimed a draw,
for example, there must be a clear distinction between the two.

I think it would be a great idea to formalize this distinction in the
rules, by defining a well-designed mandatory protocol for inter-computer
games. You could build a GUI on top of that; the litmus test whether
your protocol definition is OK would be to see if you can make a GUI
which has essentially *no* knowledge of chess other than that it is
played on an 8x8 board with 13 possible types of status per field.

tournament organizers must be able to tell instantly which actions were
the engine's and which the GUI's -- otherwise, it would be very hard to
disprove a claim that a particular bad move was really chosen by the
engine and not a bug in the GUI.

It's a mess. I truly believe that a good protocol would help this,
together with an open source GUI that speaks this protocol (which could
be mandated for cc-games). I'm going to think about this for a bit.

So, while distinguishing between the GUI and the engine sounds like a
good idea, it is not possible to police and
would, therefore, make a bad rule.

The hurdle is a technical one. There should be no mix-ups between the
GUI and the engine, and I almost feel like proving this point by taking
this project on.

Best regards,

Sidney

Rolf Tueschen wrote:

Sidney Cadot wrote:

Sid,
good to know that your name is Sidney and not Jaap, otherwise people would
attend a good demonstrations of the lack of flexibility of Jaap vd Herik.
Smartness often makes circles and this is such a circle here. You simply don't
or won't get it what Bob hyatt is telling you. Reason? Because you have the
prejudice that you want to prove that jaa, the TD, has done a good job.

Nonsense. I suggest you practice your reading skills.

Idon't know why but I have a suspicion. For reasons I will keep secret, because
I can't reveil the technology, I think that you are Jaap. I can't help it.

Could it be that this "technology" involves wrapping a sheet of tin foil
in a conic shape around your hat?

Let me tell you that your position, based on the split between engine and GUI
is completely nonsense. I know that many make the same mistake.

Ok, so now the arguments come, I presume...?

But do also
note what Amir has written. You made a decision and then you heard what the
Jonny author said in Graz. Suddenly you knew that you had made a stupid
decision. But - you had declared that the decion "would be a final one"! So by
definition you saw no way out other than leaving the decision untouched.
You see? Your fault is not one out of smartness, lack of smartness.
It's something else. That is psychologically and interesting problem.
You were unable to simply say this:
"Folks, under these aspects now our former decision _of course_ can't
be held up. We must make a new decision. I admit that my fault was,
not to talk to Johannes Zwanzger. Next year I will engage Rolf as my
personal psychologist and consultant."

Ah no, more "I am Jaap v.d. Herik". Please excuse my lack of response to
this.

You really should get out more. There's more to life than sneeking
behind your Dad's computer and being a twit on Usenet, you know.

Regards,

Sidney

Robert Hyatt wrote:

I would be interested to know what the setup was used during the game,
for the Johnny program. Did it use an integrated engine/GUI, did it use
an xboard compatible interface, UCI...


I can answer those, other than what was discussed at the time of
the problem.. Johnny apparently used the chessbase (fritz) GUI as
the front end...

Ok, that would imply UCI I think, and the GUI signalling the threefold
repitition. A bit of a mess, I think.

That's different from displaying random junk in an analysis window.

For me, it depends on what process initiated the popup. If it's the
engine, ok. If it's a separate GUI, maintaining game state and
concluding on its own that a threefold repetition has taken place, I
don't think that should constitute a claim.

What is the basis for separating the GUI from the engine?

To be a bit blunt: sound software engineering practice. The engine and
the GUI perform different functions; functional decomposition mandates
that you separate them with a clearly defined interface, in order to
reduce the total complexity of the system.

IE crafty has two distinct parts, the input/output, and the
computation part.

Fair enough. Of course, the engine must be able to get input and output.
It's only natural to separate this in two parts. I'd say this supports
my view more than that it contradicts it.

If I were doing a software engineering project, putting the draw
claim stuff in the front-end makes perfect sense.

I disagree. The possibility of a draw claim is something that the
engine's evaluator should be aware of. If the current player can claim:
fine: the evaluation for the current player is at least a draw. If
nothing better comes along, take it. If the opponent can claim: fine:
the evaluation for the current player in that branch of the search tree
is at most a draw. The opponent could refuse to claim if he has a better
option. It's all basic minimax. A possibility to claim a draw is very
similar to a legal move; it's not obligatory, it has a certain
evaluation. I'd say all this is best considered and handled by the
search algorithm, the heart of the engine. If it finds that claiming the
draw is the best "move", it will do so.

All this leaves of course the interesting possibility that two chess
programs will get in an infinite exchange of pointless moves, both
refusing to claim the draw, if they can still force the draw later on,
but there's also still a deadly mistake that could be made by the opponent.

It is, after all the part that communicates with the external world.
Making the engine tell the front end, and the front end tell the world
seems a bit complicated, not to mention violating a couple of design
principles for large software projects.

I passionately disagree. The claiming or not claiming a draw is a
tactical decision, that naturally belongs with the engine, in my
opinion. It is good software engineering practice to implement
functionality in the right place, not in a place that is (in most
circumstances) able to evoke similar behavior by accident.

For me, the words "prompted by the engine" have a very specific and
crucial meaning.

Not for me. The computer sits on the table and plays chess. It doesn't
matter what communicates with the operator. It only matters that it
happens... There has _never_ been a "GUI" component discussion in any
ICGA event. There never should be, IMHO. The engine/gui/computer is
one symbiotic chess player. Take any part out and the game can't be
played. Does it matter whether your left brain or right brain originates
a repetition claim? If not, why does it matter whether the GUI or the
engine did?

Because, to me, the GUI is the computer equivalent of the wooden board:
it's a dumb device on which pieces are moved. Like a regular chessboard,
it couldn't (and shouldn't) care less if a queen was moved from A1 to
B8, or if there were 7 kings on the board.

I'd be pretty darn annoyed if my regular local chessclub would buy
electronical boards that kept track of moves, and announced in the
middle of time trouble, in a monotonous voice: "draw by repetition of
position. Game over". A board shouldn't do that, and neither should a
GUI, IMHO.

- Notwithstanding our almost total disagreement on this (perhaps rather
philosophical) issue, I am grateful that you take the time to explain
your view; at the very least, this forces me to state my thoughts as
clearly as I can.

Best regards,

Sidney

Sidney Cadot wrote:
Robert Hyatt wrote:

I would be interested to know what the setup was used during the game,
for the Johnny program. Did it use an integrated engine/GUI, did it use
an xboard compatible interface, UCI...


I can answer those, other than what was discussed at the time of
the problem.. Johnny apparently used the chessbase (fritz) GUI as
the front end...

Ok, that would imply UCI I think, and the GUI signalling the threefold
repitition. A bit of a mess, I think.

That's different from displaying random junk in an analysis window.

For me, it depends on what process initiated the popup. If it's the
engine, ok. If it's a separate GUI, maintaining game state and
concluding on its own that a threefold repetition has taken place, I
don't think that should constitute a claim.

What is the basis for separating the GUI from the engine?

To be a bit blunt: sound software engineering practice. The engine and
the GUI perform different functions; functional decomposition mandates
that you separate them with a clearly defined interface, in order to
reduce the total complexity of the system.

That's my point. In a _good_ design, you separate, not replicate,
functionality. If the GUI is going to communicate with the outside
world, it should be the software component that does that, from claiming
draws to input and output (display) of moves. Claiming a draw makes
no sense for the engine, since it is not "talking" to the end-user.

I _still_ don't see why it then matters in this event whether the GUI or
the engine initiated the draw claim. The point is that there is a single
player on the white or black side of the board. That _player_ has to
make the decision, it doesn't matter whether it comes from the GUI, the
engine, or in some cases _directly_ from the hardware (ie a special-purpose
device like Belle.)


IE crafty has two distinct parts, the input/output, and the
computation part.

Fair enough. Of course, the engine must be able to get input and output.
It's only natural to separate this in two parts. I'd say this supports
my view more than that it contradicts it.

Yes, but my "engine" doesn't do draw offers either. The front-end
notices that after playing the move supplied by the engine, that the
position repeats a position for the third time. It then says:

"I claim a draw by 3-fold repetition after playing the following move:"

"white(46): Nf3+"

So it would seem that you would want to reject _my_ draw offer as well,
since the GUI does it without being prompted to do so by the engine at
all.


If I were doing a software engineering project, putting the draw
claim stuff in the front-end makes perfect sense.

I disagree. The possibility of a draw claim is something that the
engine's evaluator should be aware of.

You are mixing apples and oranges. The engine has to find the best
move. And yes, it is aware that the move produces a draw score. No
it does not know whether the move repeats the position for the third
time or what. It just knows "If I play this move, it leads to a
position that the search claimed was a draw for some reason."

The GUI has to recognize _why_ because the search engine doesn't return
that information. It just returns a best move and score for that move.
See why I think the GUI is the _right_ place to actually _make_ the
draw claim? The GUI sees the _real_ representation of the chess board,
with all the history, and can tell exactly why this is a draw.




If the current player can claim:
fine: the evaluation for the current player is at least a draw. If
nothing better comes along, take it. If the opponent can claim: fine:
the evaluation for the current player in that branch of the search tree
is at most a draw. The opponent could refuse to claim if he has a better
option. It's all basic minimax. A possibility to claim a draw is very
similar to a legal move; it's not obligatory, it has a certain
evaluation. I'd say all this is best considered and handled by the
search algorithm, the heart of the engine. If it finds that claiming the
draw is the best "move", it will do so.

Correct. But it only says "play this move for a draw score". The draw
may be _right_ now after this move, or it might be a repetition or endgame
table draw that is 40 moves away. The engine doesn't distinguish between
the two, because it doesn't matter to the alpha/beta search...




All this leaves of course the interesting possibility that two chess
programs will get in an infinite exchange of pointless moves, both
refusing to claim the draw, if they can still force the draw later on,
but there's also still a deadly mistake that could be made by the opponent.

You should always make the move that leads to the draw farthest away, to
give your opponent a chance to make a mistake.



It is, after all the part that communicates with the external world.
Making the engine tell the front end, and the front end tell the world
seems a bit complicated, not to mention violating a couple of design
principles for large software projects.

I passionately disagree. The claiming or not claiming a draw is a
tactical decision, that naturally belongs with the engine, in my
opinion. It is good software engineering practice to implement
functionality in the right place, not in a place that is (in most
circumstances) able to evoke similar behavior by accident.


See above. This is simply wrong. Until you actually write an alpha/beta
tree search, it might not be obvious why, but if you read my comments above,
you will see why it is wrong.




For me, the words "prompted by the engine" have a very specific and
crucial meaning.

Not for me. The computer sits on the table and plays chess. It doesn't
matter what communicates with the operator. It only matters that it
happens... There has _never_ been a "GUI" component discussion in any
ICGA event. There never should be, IMHO. The engine/gui/computer is
one symbiotic chess player. Take any part out and the game can't be
played. Does it matter whether your left brain or right brain originates
a repetition claim? If not, why does it matter whether the GUI or the
engine did?

Because, to me, the GUI is the computer equivalent of the wooden board:
it's a dumb device on which pieces are moved. Like a regular chessboard,
it couldn't (and shouldn't) care less if a queen was moved from A1 to
B8, or if there were 7 kings on the board.

I'd be pretty darn annoyed if my regular local chessclub would buy
electronical boards that kept track of moves, and announced in the
middle of time trouble, in a monotonous voice: "draw by repetition of
position. Game over". A board shouldn't do that, and neither should a
GUI, IMHO.

- Notwithstanding our almost total disagreement on this (perhaps rather
philosophical) issue, I am grateful that you take the time to explain
your view; at the very least, this forces me to state my thoughts as
clearly as I can.

Me too.



Best regards,

Sidney


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170

henri Arsenault wrote:

In article ,
(Rolf Tueschen) wrote:


good to know that your name is Sidney and not Jaap, otherwise people would
attend a good demonstrations of the lack of flexibility of Jaap vd Herik.
Smartness often makes circles and this is such a circle here. You simply
don't
or won't get it what Bob hyatt is telling you. Reason? Because you have the
prejudice that you want to prove that jaa, the TD, has done a good job.

Look, Rolf, this is getting boring. Everytime someone says something
that you disagree with, you attack his motives. yet the whole argument
that you are trying to present is an attack on the motives of Jaap.

For sure you must have misunderstood me. I said what he _did_ wrong. Not what
motives stood behind his wrongdoings.



At
least try to be consistent.

Thanks, I try my best.



If you have arguments, present them.


They are already all there. But Sidney and probably you also you both don't
understand these arguments. I am saying in principle what R. Hyatt is saying.
He has the most experinece of all here and in other newsgroups. Speaking of
computerchess.

But what we have is not a climate of decent debating. We have a usenet game
between certain people who say what are the rules and how they should have been
applied at the Graz incidents. That is the rational party. I follow this group.

Then we have people, here in rgcc, who have different opinions about these
rules and their application. They try to twist the situation in Graz so that
they can conclude that the TD was right in his decisions.

But fortunately I see clearly what is going on. What was the situation? We had
a 3-fold-repetition. Right or wrong?? Yes it was on the board. Now the
situation is absolutely clear. The Jonny program (GUI & engine together) saw
it. More, it expressed it. I leave out what SHREDDER did because that is
uninteresting. Now the only thing the Jonny operator should have done -
following the rules /tradition in computerchess, where the operator should
always do what the program expressed, -- he should have claimed a draw. He has
no other choice.

But this young unexperienced man, however strong chessplayer himself, began to
reflect the SHREDDER situation. What had caused the situation where SHREDDER
had such a huge advantage etc. Also that SHREDDER would be third in case of a
draw etc. That is all very normal for a human being, but as the operator he
can't do but one thing: he must claim a draw.

He didn't do that but he continued to make the TD a bit nervous. Formerly he
also wanted to give up but TD refused. Now, when the game was an objective
draw, he wanted to play on so that SHREDDER could still win the game.
That is all very indecent.

Johannes Zwanzger quickly made a move. Because, that was his idea from human
chess, if he had made that move then the draw would no longer exist. In the
meantime a very slow Jaap came to the board. And now Jaap made a gross mistake.
Normally he should have ordered the take-back of the played move and
continuation of the game in the former position which was a repetition 3 times.
So then the game would have been a draw. But Jaap vd Herik ordered that the
game should go on. So - SHREDDER won in the end.

But the biggest scandal happened later. A decision had justified the
continuation of the game when Zwanzger described in detail his thoughts during
that situation. He confessed that he didn't want that SHREDDER played a draw,
so therefore he had NOT claimed the repetition. - He couldn't have made clearer
that he had cheated. But what did the TD do then? Because the former decision
allegedly was final, the decision was left untouched.

Now, we are talking about such a cheat. A complete violation of the rules of
computerchess. And we have people, many people, who congratulate this young
programmer for his human touch.

Bull****! He spoiled the whole event with his cheat. Now SHREDDER got his tie
instead of place three and he won the tie. And all that was made possible by
the cheat of this young ignorant.

These are the facts. These are not opinions. Or prejudices. No, that is all
rational analysis of the event.

Plus some jokes of course. Because you can't expect that I discuss such a cheat
without explaining the incredible stupidity of the TD decisions. Bob Hyatt
exactly said the same about the stupidity.

But that is against the interests of certain parties. They prefer having such a
lame TD who makes the decisions. After all these mistakes he's now like wax in
the hands of the interested parties. I think that next time the players and
operators can order appropriate decisions at will! Because we have a TD who has
no talents to make the right decisions. So that is the best man for players who
want possible extra rights. Or for a company which has to out-balance the
interests of four or five home parties. You know the question who plays
Kasparov in NY, who is Wch, whose merchandising has highest priority. Certainly
Johannes Zwanzger has good chances to be a new member in the ChessBase
family...

We are all manipulated. Look, Henri, since LIST was banned I have it in my
engines folder. Formerly I was content with FRITZ and CRAFTY. But now my
emotions are boiling. I must show my solidarity with that misused programmer.
On the other side I will boycott any Jonny engine. No chance!

Rolf

P.S. I am not forced to tell you what I have written out of what motivaton. Try
to create the enigma to read my lips.



Ad hominem arguments prove nothing.
Personally I don't know any of the people involved, but I know Bob Hyatt
from reading this newsgroup, and I respect him, but like some others, I
happen to disagree with him in this case. In your mind, everyone who
happens to disagree with you is either dishonest or stupid.

Please change the tune.

Henri

my thoughts are that crafty is a licensed product under a GNU public
license. respect that license or you are a theif.
"darrz" wrote in message
news
On Tue, 02 Dec 2003 00:27:35 GMT, "Znarf" wrote:
The ICGA could only access and review the source code upon an accusation
of
"cheating." The Accuser must provide a factual basis for the accusation
(e.g., it must be more than "The accused program performed the same two
moves as program x."). This would protect entrants from unfounded
accusations.

Not really. Read your statement again. Where are the facts in the
accusation? What facts can you have as a cc tournament entrant, about
another program?

You have no source code, no performance of the suspect program on any
critical positions or test suites. Nothing!

All you have is a suspicion, based on the play you see the suspect
program make at the tournament WHICH IS ALREADY IN PROGRESS.

Are you going to stop the whole tournament and examine the suspect
program for a few hours? Based on someone's _suspicions_ ??

I don't think there is a good answer anywhere in this rat hole!

You either run the risk of someone cheating and winning a tournament
with a program like Crafty, or you disrupt the tournament and make
unfounded accusations.

I have another idea, which may not be popular, but here goes:

In an open tournament, any program competes. Bring your open source
program, modified or not. You're in like a porch climber!

Open source authors, like Dr. Hyatt, would just need to keep their
strongest version under wraps until after that year's championship.

It seem's odd that someone would make bikes, give them away freely,
and then say "but you can't race with this bike, against me".

Phooey! Every "bike" can "race" in an open tournament. Every program
can compete with different settings or "personalities" that Joe or
Jill Consumer have discovered, and care to enter into the open
tournament.

If you (as a chess programmer) make your program open source, you need
to make one version stronger than the source you released, and keep it
confidential, to compete with an edge in the next open cc tournament.

Result?

Lots of people make lots of little modifications to Crafty and other
open source chess programs. Most will be bad, but some will be good.
More competitors, more interest in cc, and any good modifications that
prove valuable may expand our knowledge of what makes a stronger chess
program.

Note that I'm not saying anyone has the right to take open source code
and sell it commercially. I'm only saying for an open tournament,
every program, of every type, should be allowed to compete.

That clears the air of any claims of cheating, and is in the true
spirit of an open tournament. IMO

It also makes computer chess more interesting, to more people.

If current open source chess program authors are offended by that, I
believe they should not make their program open source, anymore, and
really ask themselves "why did I make this program open source?".


Your thoughts?


Darrz