Author: Ed Schröder
Date: 14:51:47 05/28/01
Go up one level in this thread
On May 28, 2001 at 12:45:26, Bruce Moreland wrote: >On May 28, 2001 at 00:46:07, Robert Hyatt wrote: > >>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. > >You can call into someone's code and get an accurate score for a position. In >some cases, the score allows you to immediately enter a won ending or avoid a >lost one. This is chess-specific knowledge, and that you have to correctly >generate the successors to the node, and check them against the EGTB stuff >doesn't diminish this. "strcmp" doesn't let you do this. > >>>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 addressed this later in the post. > >>>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. > >I don't care if you didn't write printf. What I care is that some of the code >being reused has chess knowledge in it. It is not okay to enter two programs >into the WCCC, but in a minor sense, Eugene has many. > >>>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. > >The mate in 75 problem can be fixed and improved upon. As of now, everyone has >to wait for Eugene to do it for them. I don't. If I want to fix this in my >stuff, or if I want to not use EGTB because I can't tolerate this bug, I should >have an advantage when it's time to play. The argument that "everyone" has this >bug, and therefore it should be codified into the rules, is poor. > >I don't care about the GUI stuff. Winboard doesn't pick a move for you. For >the Nth time, I am not at all concerned about code sharing in the general case. >What I'm concerned about is sharing of code that selects moves, or provides >substantial assistance to a program when it's time to select a move. > >If someone wants to make set of chess piece bitmaps and give them to everyone, I >don't care. If someone writes a king safety routine and gives that to everyone, >I do care. > >That kind of thing is unfair and destroys innovation. > >>>>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)... > >It is probably unreasonable to demand that everyone write their own EGTB. The >cat is too far out of the bag. > >I think it sucks though. I made my own. But now I'm faced with a series of bad >choices. 1) I can spend a lot of time and money making my own stuff, in order >to come up to parity with people who have done essentially nothing. 2) I can >take Eugene's tables and convert them to my own format. 3) I can discard my own >original code and ask to use Eugene's stuff. > >Conversion of formats may be a viable choice, and may rescue this, but don't you >have a problem with the idea that I'm faced with the problem of standardizing on >a means of selecting chess moves? > >Like I said though, this is a tempest in a teapot. Most people don't care. The >issue is not that big a deal until it starts to encroach upon the middlegame, >until Eugene's stuff provides a means of selecting between drawn moves in order >to pick the one with the most winning chances, or unless this sets a precedent >for sharing opening books and opening book generators. > >It is absolutely reasonable to demand that people don't share opening books, >opening book generators, and obviously core search and eval code. > >>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. > >The book learning code thing is a little troubling, but you could have just >given him the algorithm and he could have done it himself, so I'll pretend you >did that. > >Software engineering may prefer it, but software engineering would also prefer >one chess program that incorporates the best parts of other programs. > >If we were all trying to create the best possible chess program (one of them), >this might be the way to do it. > >But there is a certain amount of competition built into this, and if this is to >remain, there needs to be a limit to the amount of cooperation that can occur. > >I argue that, for instance, letting someone incorporate your pawn structure code >verbatim, is too much cooperation. > >>>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... > >That's all mindless data-entry, Bob, and if you're going to claim that this >provides an open season on all forms of "code sharing", we are dicked. You've >just opened the way for anyone to make a slight mod to Crafty and enter it into >the WCCC. > >The book sharing thing is a little touchy. If you give me your MCO, and I use >it in my book generation process, are you a co-author? I don't think so in this >case, because you didn't editorialize it, and it's okay to generate an opening >book from a reference source such as a chess book. It would be stupid to claim >that everyone should *have* to type that crap in by hand. > >That you typed all that crap in shouldn't be an argument that someone who >specifically designed a computer chess book should be able to distribute the >book and its move selection system to programmers of their choice. > >>>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. > >The opening book author is an author of the program. I don't have a problem >with a guy doing the book for any other program, but I don't want to have to >play against it several times in the same tournament. These days, with everyone >and their dog becoming a ChessBase engine, you could end up getting outbooked by >a relatively new program, the programmer of which has done essentially no >opening book work. > >That's not fair, and it stifles development in this field. > >>>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. > >The humans that help him don't help him while the clock is running. That's an >important distinction. And even if you make this point, where does it lead? >Once again, it seems obvious that at some level, move selection knowledge should >not be shared. I think that it is very clear that at least the opening book >should be one of these places. But it seems that your arguments would lead to >sharing of middlegame code. That's terrible. > >>>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. > >But will you then give this code to ChessBase? At that point a newcomer is >faced with getting book-bombed by *everyone*, putting in a huge amount of effort >that nobody else has to expend, or going along with the crowd in order to get >parity. A terrible choice. > >bruce Pointless discussion. You use alpha-beta in your program, you did not invent it, still you use it. Take it out and your program will drop with 700 elo points doing only 4-5 ply searches instead of 11-13 ply searches. Will you remove alpha-beta? I guess not. Just take everything what is offered for free that makes your program stronger. That is your job :) Ed
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.