Author: Robert Hyatt
Date: 14:55:11 05/29/01
Go up one level in this thread
On May 29, 2001 at 12:33:47, Bruce Moreland wrote: >On May 29, 2001 at 00:15:01, Robert Hyatt wrote: > >>On May 28, 2001 at 12:45:26, Bruce Moreland wrote: > >>>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.. > >For the Nth time, functions like scanf do not return "mate in 32", or "play >Qd8", or "this pawn structure is worth 33 centipawns". I don't care about >software reuse for peripheral things. I care about it in the guts of the >program. Please stop and think a minute. 30 years ago chess wasn't the name of the game, it was just writing a program to do something useful. And some functions were considered interesting for sharing (I/O, etc.). Step forward to today. Tablebases are a binary operation. you either get a hit or you don't. There is no innovation, no room for making different decisions, etc. You probe and get a hit or not. My tablebase probe into the Nalimov tables will produce _exactly_ the same result as your probe into your tables. No creativity. No selectivity. Identical results. The same as reading files, handling signals, talking over a socket, etc. The engine and evaluation are different. There are a near-infinite number of programs possible to play chess. And there are a near-infinite number of results you can get back from searching the same position. But not with tablebases. you get it or you don't. Which takes this beyond being a significant part of the engine, into being something akin to another I/O method everyone uses to search a database. IE if I write a business program, I certainly won't write my own DB2 equivalent. I will use their library, but still call the code that calls it "mine"... > >>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. > >If I wanted to use Edwards PGN stuff I would have no problem with doing it, >since (see above), this is not returning "mate in 32", etc. I fail to see the difference. One returns an exact game played by someone, the other returns an exact result for a given position, with no creativity or anything at all involved. > >>>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? > >For the something more than Nth time, I don't care about this, since these >functions are not returning "mate in 32", etc. What makes "mate in 32" any more special than sqrt(4)? Both have absolute answers, require no thought on our part to code them, etc. > >There has to be a line somewhere, to keep me from pulling your whole eval >function out and using it directly. That might be good software reuse, but it >screws up a competitive event, where the point is to have original code >competing. I don't disagree there at all. I just don't consider a EGTB probe to be anything like an evaluation at all. In my eval, I consider what patterns I want to recognize and how they interact, and the weights they get. For an EGTB probe, I get the same value whether I write my own or use the code written by someone else... > >It seems obvious that the line is drawn somewhere between "printf" and code that >does search, evaluation, and move selection. > >>>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. > >If I fix it in mine, and yours says mate in 78, and mine says draw, and 50 moves >later the came is a draw by FIDE rules, I should get a half point. What could >your argument be that I shouldn't get a half point. That "everyone" is using >the Nalimov tables? This is my point exactly. No. I agree with you 100% there. The "I don't buy that argument" was directed at the statement you made about "the argument that everyone has." I don't believe the rules should be bent to validate a database that has an obvious problem with the 50-move rule. > >Someone who enters the mate in 78 ending without any tables at all should also >get the draw 50 moves later. What's the alternative? To force this guy to >reset the 50-move counter so it will continue to play, so you don't have to fix >your bug? Nope. I try to play within the rules... and my program will do everything it can to not draw by 50 move rule, without turning a win into a loss. But it can fail if there is no way to push a pawn at the right instant. The search takes care of this in many cases. I don't want special treatment for any program, with or without tables... > >>>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. > >As I have also stated several times, I think the EGTB argument is a minor issue >compared to the book reuse issue. > >Most people think that EGTB is drudge work. It's hard to get it right, it takes >a lot of disk space and time, and Eugene has already done it correctly. > >Essentially he's solved the problem, and nobody coming along later is going to >make a better one, with the exception of the 50-move bug. > >It does bother me though, because it sets a bad precedent. I think that over time, chess engines will continue to get better, and grow in size, to the point where this bit of code shrinks to almost nothing, relatively. Just like the other simple (and shared) functions in my engine (FirstOne() and so forth are so necessary for bitmap programs, and so unnecessary for someone to search for the fastest way to do them)... > >>>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... > >And who is working on this? Why should they work on this if they can just use >Eugene's thing? See my comment about the bubble sort. Which was then modified to the improved bubble sort, and eventually into the varions NlogN sorts like quick/heap sort. Alpha/Beta has evolved tremendously, yet the raw code for it has been published and used by many for years... Urban has already developed a more space-efficient generation algorithm, which shows that development won't stop... > >>The bubble sort didn't end innovation in sorting... > >The bubble sort didn't solve the problem effectively enough. But this does >provide an argument about why the EGTB issue doesn't matter *that* much. If >there had been sorting competitions, and someone created a sort that was >demonstrably optimal, there would be no more interest in the competition. > >If the sort was a part of another competition, it might be agreed that it's >possible to reuse the sort and work on the other parts, since part of the >problem has been "solved". > >This is the de facto situation with the Nalimov tables now. If the 50-move bug >ever comes up in practice though, and I'm there to see it, the guy whose program >follows FIDE rules is going to get the half-point though. I'm not aware of any way around this already. IE in every event I have played in, the 50 move rule was in full force, with no exceptions since FIDE undid the exceptions cases it had specified in the past. > >>>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. :) > >PGN and SAN don't return "mate in 32", etc. > >>>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. > >I agree that the opening book is the biggest problem here. I would obviously >give up the whole EGTB argument in exchange for the opening book argument. Back to my point: how to develop a policy that can be enforced? That is the problem I see. It is already hard enough to ensure that a program isn't a clone of another program. What about the books? How could I prove my book is from a collection of random PGN games rather than pirated from (say) ChessBase and Fritz??? Suppose I use the latter to play, but the former for your examination? This seems impossible to me... and if it is impossible to enforce, it is probably not worth the effort to worry about 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.. > >It is hard to police but it's still wrong. Taking all of Crafty is not that >much different than taking a sigifnicant portion. If someone can read it and >understand it, and implement their own that does the same thing, and maybe add a >new idea or two, no problem. > >The issues here are similar to the issues involved when we're talking about >plagiarism of academic works. I agree. But with academic works, we can compare word for word. Since most don't publish their source, we will never know how rampant (or not) this is. We have certainly seen at _least_ two copies of Crafty, (voyager and Le Petite were certainly exact copies) not to mention others like Gunda and Bionic. I wonder if that is "all" or "just barely the surface"?? Hard to say... Harder to prove unless someone gets a copy... > >>>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... > >Of course, but we "all" don't use "mate in 32", etc. source code written by >others. I see no more creativity in probing an egtb than I do in computing the sqrt() of a number... Perhaps creating the database was interesting. Or developing the complex indexing scheme to minimize the size was interesting. But once it is done, I don't see how making everyone do it again changes anything. They get the _exact_ same value whether they use Eugene's tables or "roll their own" which is an important point. The results _must_ match or there is a bug to fix... In a search or evaluation, this isn't the same at all... > >>>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... > >Yes, but the rule isn't even discussed now. How many programs are going to show >up at the next WMCCC running the ChessBase interface and using some ChessBase >book created using the same process and/or by the same person? This already happens. IE in the SSDF testing, Crafty generally uses a normal (not special) Fritz book via the ChessBase GUI. Good or bad? Hard to say. > >Here I am having to consider doing an incredible pile of work in order to avoid >losing on move 13 to someone who never had to dick with any of this. > >bruce Welcome to computer chess. :) That is why I am so interested in eliminating the human side of this. I've been doing tournament preparation for so long... and it is utterly boring and wasted time, except that it avoids embarassing losses when you forget to do it.
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.