Author: Robert Hyatt
Date: 05:32:30 03/16/98
Go up one level in this thread
On March 16, 1998 at 02:22:01, Keith Ian Price wrote: >On March 15, 1998 at 06:37:35, Dirk Frickenschmidt wrote: > >>On March 15, 1998 at 02:53:17, Keith Ian Price wrote: >> >>Hi Keith, >> >>as a user I understand and completely share your view about autoplaying! >> >>And just like you I find it a real improvement if an autoplayer changes >>colours after each game, like the Fritz5 autoplayer, which should be a >>standard feature for all of them. >> >>But I also understand the problems for the programmers in the age of >>outbooking by a combination of heavy book learning features combined >>with auto-testing. >> >>This combination allows you to play a long series of games against an >>opponent already rated in the SSDF *before* you release the program. >>Then you take out all losing (and perhaps drawing) games and melt the >>winning games into the book up to move x. Now the effect will be that if >>the two programs play against each other the book learning will lead the >>new program very fast to exactly those pre-played winning lines. The new >>program will simply repeat its long before generated auto-played wins >>(or draws). >> >>In effect the percentage of wins (and draws) will become much higher >>than the program's real playing strength ever could be. >>It's no cheat insofar as it repeats real wins gained by autoplaying >>before, but it's a *heavy* cheat considering the fact that it omits most >>or many of the real losses that would have happened without this kind of >>tuning. > >Of course it is cheating. But this could be eliminated with a universal >autoplayer standard. If it were agreed upon by all subscribing to the >autoplayer standard that that is not allowed, then code could be written >in to allow a program to challenge a second defeat with the exact same >score as a previously stored defeat if autoplayer was true for both, and >the autoplayer code would score a forfeit for the offending program. For >the less obvious cases, where a program comes out of book in a bad >position, and there are repeated autoplay games using that same opening >but with random moves thrown in which don't affect the score, but >prevent duplicates, then the program notifies the autoplayer with all >scores and pvs and once again all games are forfeited by the offending >program. If this couldn't be done completely automatically, it should >still be feasible with the co-operation of the SSDF, as adjudicators, if >the program lodged a protest on screen. It would quickly point out the >hanky-panky, and the testers would probably not want to test the >offending program anymore. With the incentive gone, the practice would >stop. > This seems silly. Why not simply "let learning take its course?" IE if a program doesn't learn it gets killed repeatedly. That encourages the programmer to add learning. And if it isn't done right and repeats losing games anyway, it still gets killed, and the programmer either settles for a lower rank on the SSDF or he fixes it correctly so it won't play a losing line twice. It is *not* hard to do this... >>Under these circumstances it is hard for a programmer not to see his >>program being outboked by later programs, *if* he allows autoplaying by >>providing an autoplayer or allowing one to be used with his Dos-program. >> >>I am convinced that this problem has to be solved before the autoplayers >>can get their normal function back: to provide real results for users, >>testers and programmers without any twisting around with them in this - >>from my view - completely unacceptable way. > >It can only be solved with an open autoplayer standard, as proprietary >code leaves room for accusations whether founded in truth or not. > I personally think that this is backwards. IE I would *like* for my program to know whom it is playing. If it is a computer, I adjust things differently (I use a really dynamic draw score for humans, but I want to user a draw score that is proportional to my opponent's (and my) rating when playing a computer. I see nothing wrong with a program playing differently against a human and a computer. If you play Scrappy or Crafty on ICC you are going to get this, because there I know *exactly* who I am playing. And I adjust the resign threshold, draw logic and other things based on the opponent I am playing. Just like I do as a human when I play games there... >>Until now I see no way how this misuse could be prevented. But I hope >>either a a programmer agreement (unlikely) or some new technical ideas >>by someone like Bob Hyatt or other programmers could show us a solution. > >I would think Bob could come up with a really cool autoplayer >specification, with this kind of anti-booking security, and perhaps >supply the basic code in C or C++ for inclusion in programs. This way he >could also slip in automatic chess server access, which I know that he >would like, and perhaps TCP/IP for network use. What do you think, Bob? >Any time in your 38-hour days for this? At least it would eliminate your >hassles with autoplayer and Crafty... > It's far harder than you think. If everyone ran Linux/unix, I'd do it in one day. It's already done, in fact, and it is called "xboard". And the non-x version called "ROBOfics". Both work well. But when you try to support win95, and winNT, and DOS and all the different hardware variations as well, it turns into a headache... > >>Missing autoplay features really mean a mess and something like having >>to stay in the computer chess stoneage for users. >> >>Not acceptable for long. >> >>So please programmers gather and find a solution! > >One hundred percent agreement from me on this! > > >>Kind regards from Dirk > > >and back to you, > >kp
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.