Author: Dann Corbit
Date: 12:33:15 05/29/01
Go up one level in this thread
On May 29, 2001 at 12:33:47, Bruce Moreland wrote:
[snip]
>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.
How about the sharing of the Alpha-Beta algorithm. If only they had kept that
secret. Or hiding of how to do a NULL-Move operation? Why not keep everything
secret?
I think your argument is very, very strange. There are no original chess
programs. Almost every aspect of a good chess engine comes from shared
knowledge. I am at the opposite end of the spectrum. I would like to see every
good idea published. And I think incorporation of those ideas is a very good
thing. Now, I don't think that we should just cut and paste someone else's code
into our program and call it ours. But a thing like endgame tablebase probes --
to insist that others reinvent that is nothing less than absurd to me.
>>>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?
Exactly. It is a foolish idea to reinvent the wheel. That's why the publish
the wheel specs, and manufacture and sell wheels. That does not mean that a
better wheel will never be reinvented.
After the Thompson/Edwards sort of tablebase files were invented, who would
imagine that Eugene Nalimov would come along with something much better? Not
me, and yet he did. Which is just another way of saying it might happen again.
But if it doesn't, it won't matter much because we have something really, really
good already.
>>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".
Lots of innovation is going on in sorting right now. Stefan Edelkamp's work on
the weak-heapsort, Stefan Nilsson's work on O(n*log(log(n))) sorting, Cantone's
quick-heapsort, etc. Now, the innovation in sorting has everything to do with
the algorithms being published. For instance, Edelkamp has combined the ideas
of weak-heapsort and quick-heapsort to produce something even superior to either
alone. I am of the radical opinion that algorithms (like math) belong to
everyone and patenting of algorithms is evil. Be that as it may, sharing of
information is noble, and hiding of information is evil.
IMO-YMMV {obviously}
>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.
>
>>>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.
>
>>>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.
Plagiarism involves pretending that you did something but someone else did it.
There is no connection whatsoever to using something with permission.
>>>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.
>
>>>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?
>
>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.
The "mate in 32" argument makes the addition of tablebase files sound
devastating. Actually, there is very, very little ELO gained by addition of
tablebase files.
Consider this experiment:
ftp://cap.connx.com/pub/crafty-tablebase-experiment.doc
ftp://cap.connx.com/pub/crafty-tablebase-experiment.pgn
Here is the issue as I see it:
1. It is wrong to use someone else's work and claim it as your own.
2. It is right to use someone else's work with permission and describe exactly
what you did.
Here is what some header files for programs I wrote look like:
/********************************************************************/
/* Schroder's methods for root calculation, implemented in C. */
/* This is the 'generic' version for any function with derivatives */
/* ----------------------------------------------------------------*/
/* Reference: "On Infinitely Many Algorithms For Solving Equations"*/
/* by Ernst Schroder, Translated by G. W. Stewart. */
/* ----------------------------------------------------------------*/
/* Copyright (C) 1996 by Dann Corbit */
/* =================================================================*/
/* Inspired by the following reference: */
/* Local convergence rates can be made arbitrarily large. */
/* Ernst Schroder showed, over 100 years ago, how a family */
/* of explicit single-point formulas could be designed to */
/* have arbitrarily high orders of (local) convergence. */
/* You can obtain a translation of Schroder's paper at: */
/* */
/* ftp://ftp.cs.umd.edu/pub/papers/papers/2990/2990.ps.Z */
/* */
/* =================================================================*/
/* A posthumous thanks to Mr. Schroder, & thanks to Pete Stewart. */
/********************************************************************/
And:
/*
** Algorithm M, from:
** "The Art of Computer Programming, Volume 3: Sorting and Searching",
** Donald Ervin Knuth, Addison-Wesley, Hardcover, 2nd edition,
** Published May 1998, ISBN 0201896850
** Page 111.
**
** This is a straightforward implementation directly from his description.
** While the primary use of Merge Exchange sorting is parallel supercomputer
** sorting of large batches of data, this version is to be tested for use
** on very tiny partitions (specifically 256 items or less)
*/
And:
/*******************************************************/
/* This function uses the Euclidean Algorithm to */
/* calculate the greatest common divisor of two long */
/* double floating point numbers. */
/*******************************************************/
/* Programmer: Danniel R. Corbit */
/* */
/* Copyright (C) 1992 by Danniel R. Corbit */
/* All rights reserved. */
/*******************************************************/
/* Reference: "Factorization and Primality Testing", */
/* by David M. Bressoud, */
/* Springer-Verlag 1989. */
/* pages 7-12. */
/*******************************************************/
And:
/*
This version of heapsort is adapted from:
Data Structures and Algorithm Analysis in C (Second Edition)
by Mark Allen Weiss
Addison-Wesley, 1997
ISBN: 0-201-49840-5
Page 228.
It is simple and interesting, but quick-sort is better than heap-sort.
*/
And:
/*
** The purpose of this routine is to discover partitions in the data.
** This is a two state FSM.
** Ascend = 1, Descend = 0.
**
** This is a vastly improved version of my ugly code.
** The large improvement was from Kang Su Gatlin.
**
*/
And:
/*
Most significant digit radix sort.
The outline of these sorts comes from "Algorithms in C"
by Robert Sedgewick, ISBN:0-201-31452-5.
I have added a generic CHUNK operator. This operator
is analogous to the compare operator for a standard sort.
Besides just peeling out the digit, CHUNK performs whatever
transforation is needed in order to put the bits in the
proper order of significance.
*/
Notice that I have no qualms about using other people's ideas. In fact, I would
have been unable to 'invent' any hose these very good techniques by myself. In
each case, I received explicit, written permission before using the techniques,
except for algorithm M, which I made major changes to.
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.