Author: Robert Hyatt
Date: 21:46:07 05/27/01
Go up one level in this thread
On May 28, 2001 at 00:11:24, Bruce Moreland wrote: >On May 27, 2001 at 22:12:32, Robert Hyatt wrote: > >>It doesn't bother me for lots of reasons: (1) many programs running today >>have bits and pieces of my code in them; (2) most of the algorithsm I use >>today are from ideas produced by others, years ago. >> >>I don't think that just because you have something to "probe" for you, or >>you have a library function that does something _else_ for you, that you >>should be concerned about originality. IE how is it different to use EGTBs >>than to use a compiler somebody else wrote to compile your program? > >It bothers me. And the difference between an EGTB and the CRT is that you can't >input a position into the compiler and get back a move. Neither can you do this with the egtb code. It has to be incorporated into the search in a way that works. It is a small part of the overall code, although the generator is obviously a complex/sophisticated piece of code that is not part of the chess engine itself. > >The problem is not that you didn't write it. I don't have any problem with the >fact that you didn't write the EGTB stuff. What I have a problem with is that >*everyone* uses it. The problem I have is the multiple authorship problem. >It's not supposed to be possible for the same individual or team to enter more >than one program in the same tournament. > What about the problem of everybody using the same body of PGN to build their opening books? None of us created that data. None of us compiled it. And we even use it in different ways... >I've never understood the argument about the compiler. If it's meant to show >that you can use tools that others have used, then why shouldn't you be able to >make your own version of Crafty, call it Drafty, and enter it into the WCCC? >Clearly not. > My point was that I personally use a _lot_ of code that I didn't write. From the library with printf(), thru the library with select(), etc. To me, the EGTB stuff is just another thing I call if I want that kind of information. I don't see how it is different, in the context of chess, where we _all_ use a common set of lib routines. This is just a chess-specific bit of code that software engineering demands be reused rather than designed from scratch many times. >The difference is chess move selection. The EGTB stuff chooses a move for you, >or at least in many cases causes the move selection process to be extremely >simple. > >The fact that everyone uses it causes some stupid problems: > >1) There could be bugs in it which nobody will find, because everyone operates >according to the same reality. > >2) FIDE chess rules are going to be changed because everyone has this EGTB >crutch. It's come up in player's meetings: What happens if someone enters an >ending that's a mate in 75, with move than 50 moves without capturing, >promoting, or moving a pawn? Some people want to allow the EGTB stuff to take >them conveniently to a win in these cases, at the expense of others who play >according to the FIDE rules. The day it's decided that we have to change the >rules of chess because someone is too lazy to fix this problem is the day we've >lost something significant. That is a different issue. It would be there whether everybody uses a common EGTB library routine or writes their own from scratch. IE what about the GUI issue? I don't want to write one. Xboard works just fine. Someone else has chosen to maintain it and add features as engine authors suggest. In fact, there are more engines using xboard/winboard than there are using the EGTB stuff, although these two numbers will probably get pretty close together as engines are refined. > >>That point is totally lost on me. IE I use xboard for my GUI. I didn't >>write that. I use a mega-million game PGN collection. I didn't develop >>those. I use the same Zobrist hashing everybody else does. I didn't develop >>that. The list goes on and on and on... > >Maybe I'm wrong about some of the EGTB issue. The actual data is just DTM for >various positions, and the selection system isn't that big a deal. The amount >of creativity that can go into selecting moves from the EGTB isn't high, and >creativity can be added outside the Nalimov code. > >For example, if you are in a drawn KRN vs KR, what do you do? The Nalimov stuff >will return you a lot of nice zeros, but it won't help you press for a win. So >there is room to add *something*. > >But maybe I'm not wrong. In any case it's something of a tempest in a teapot >sort of thing, as long as people don't start changing the FIDE rules to hide the >bugs in the EGTB stuff. You bring up a much more important issue with this PGN >thing. > >The PGN games are just game data. For the most part it's just raw information >and no clever process was required to create it. If you're going to say that >you can't use this, then nobody can use any information gained in cooperation >with anyone else. You can't program in the Ruy Lopez, because knowledge of that >opening traces from one person, so we have multiple program authorship through a >long-dead Spanish priest, blah blah. I think this is an obviously absurd >argument. > >But there is room for concern here, too. You don't have to surrender to this >and allow Chessbase to enter Fritz, Dritz, and Gritz, which are 100% Frans >Morsch in one case, and 99.8% Frans Morsch in the others. > >Clearly there is a difference between incorporating a search routine that >someone else wrote, and reading the same Evans Gambit book that they read. First, I don't think the EGTBs influence _every_ game. Yet the engine and evaluation have to play every one. So before the EGTBs influence the result, the engine has to have done something right. At least I don't enter endgame competitions where we start off with 5 pieces on the board. I would not be interested there at all if EGTBs are allowed, for the reason you gave. I didn't develop the 'thing' that is solving the problems. But in real games, EGTBs are apparently here to stay, and it really doesn't seem reasonable to demand that everyone "roll their own". That just turns into a waste of time since it has already been done. Particularly factoring in the CPU time required to build the new databases (6 man)... Second, in this case, the code is such a small part of a complete engine, it doesn't cause me concern. IE I didn't have any problem with Fritz having my book learning code stuck in it. That is just a part of the complete engine, and once I published how I did it in JICCA, someone could have either re-written it from that description or used what I wrote. The latter is again the way software engineering prefers. > >If we're talking about automatically generated opening books, creating one is a >difficult process. Forget about the games that go in -- assume that people use >a public domain pile, or their own games, or whatever. Breaking out useful >information about what move to play, based upon the results of a bunch of games, >is extremely difficult to do. You know this, because you have done it. Should >this code be shared amongst multiple programs? Just remember that a huge amount of time and effort went into the original PGN collections. Someone typed a _huge_ amount of data at some point in time. We are all using the results. Even if we extract the information differently, or if we extract different information, we are using something we could not have created ourselves, without dropping engine development for a long while. I personally typed every line in MCO10 into a book for Cray Blitz. Every column, every footnote, every typo. And then I proofed it. Others did this for real games. There is probably as much effort involved there as in the EGTB development project from Eugene... > >And if we're talking about manually generated books, the same thing is true. A >guy designs a book for programs A, B, and C, so if you play against these in a >tournament, for a very critical and occasionally very long part of the game you >are playing against the same guy several times. This is just part of the "war". IE you play rebel or tiger, you play J.N.'s book. Fritz, Nimzo, etc? Alex. It makes it hard for a single person (like me) to compete since one person hits the book, another works on the engine. For me there is just one person to choose between the tasks. I just take that as part of the team vs me problems that have always been there dating back to HiTech and others that had a big group. > >I'd argue that both of these are examples of single-author multiple-entry. I >don't really want to play against ChessBase's best book, fine-tuned for >individual programs by ChessBase's best opening book tuner, five or six times at >the next WMCCC. Do you? This is already happening, at least to an extent. If you play against a human in a match, you have the same problem. That human will get a bunch of humans to help him. If you pick another in the group to challenge, he will get the same group to help him prepare too. Fair or not? This is one of the reasons Fischer refused to defend his title. It is something just like income tax. I hate it, but I put up with it. > >It shouldn't be the case that someone signs a contract with ChessBase and then >sighs with relief because they know they're going to gain an extra couple of >points at the next tournament, because they can use opening book technology >shared by all of the Chessbase products. > >bruce I won't disagree. But it is already happening. If I ever play in what I consider an important event, it will be one of my goals to take some sort of evasive action, book-wise. Or take my main goal: to make hand-tuned books obsolete. I believe that is possible over time. I'm going to try to do it.
This page took 0.01 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.