Author: Robert Hyatt
Date: 21:15:01 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. But think back about 30 years and visualize this conversation: "You can't use that scanf() function because someone else wrote it, and even though it is pretty straightforward to write a function to read in data based on simple format options, you have to do that yourself or else the program you write really isn't "yours" to use.. That isn't too far off. Yes, EGTB is chess specific. But we are all doing chess programming. And it just happens to be a useful library routine. I wouldn't mind (and there is such an animal by the way) for everyone to use a good PGN parser rather than writing their own, as it would eliminate a lot of crap PGN that certain programs seem obsessed with producing. > >>>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. Then by this argument aren't the various authors of the normal C library also "team members" as their code is essential (reading files, etc.). What happens if someone build a special-purpose board that anyone can grab, which will probe the EGTBs very efficiently? What if this ends up in the micro- processor of 2010? > >>>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 buy that argument either. We have talked about solutions to the problem, although the idea of fixing such a thing, only to have FIDE next year change the 50-move rule again is a bit much when you think of the wasted compute cycles if this happens. > >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. I think we mainly differ on our opinion of "substantial" in your statement. I think the EGTB stuff is a tiny part of the overall engine. > >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. There's plenty of room for innovation left. Better (still) indexing schemes. Better compression. 50-move rule fixes. Better (less resource intensive) construction algorithms... etc... The bubble sort didn't end innovation in sorting... > >>>>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? Remember that we already live with PGN and SAN. A probe routine is not that far away. Even a standard opening book access method would not be to far beyond reality, and it would eliminate a lot of book preparation. :) > >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. I agree, although the book issue is _already_ a problem. > >>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. This seems hard to handle. They might take all my ideas, but from discussion with me rather than from the code. That would be hard to "police"... IMHO.. > >>>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. > I hope not. I am just pointing out that we _all_ use things developed by others... >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 don't disagree. However, I think that enforcing a rule restricting this would be hard... > >>>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
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.