Pawn Pattern Matching

[bob]

It was an asymmetric evaluation term and all of that was eliminated within the last 2 years.

Also it did not do what Gerd is looking for. It was an almost exact match, where at least 3 of the 4 pawns had to match. He is looking more general than that I believe, with some measure between 0 and 100 of how well the match fits...

Dann posted an example of how your old code could be effective at certain positions. Maybe it is worth bringing it back?

One day, if I can figure out how to do that without any sort of asymmetrical behavior, I will do that. But we removed _all_ asymmetry in the eval when we started the rewrite last year or the year before, and we don't want to regress to that solution for certain types of problems...

Why would this be asymmetrical ? Shouldn't you just pull the score closer to zero if the "loosing" side has the choice to wall ?

Tony

The way all of these were done was to make such positions worse for Crafty. Just pulling the scores closer to zero is the wrong thing to do in many cases. Because many near-zero scores are just numbers representing approximate equality, even though there are imbalances that might create a struggle later. These kinds of positions are more absolute in their evaluation, which means it would be nice to have a "absolute draw" vs "probably a draw" type scoring. I would much prefer "probably a draw but with some winning chances for my side (and not the opponent's)" over "absolutely drawn because it is locked up."

The other part was the Stonewall detection and that was completely asymmetric, being always a big penalty for Crafty so that it would just avoid that type of position completely if possible.

[Dann Corbit]

I have seen parts of the Wiki.

I think my contributions would be minor compared to true experts on the subject.

I do have a suggestion:
Create the site like a reference work (IOW, if discussion is about alpha-beta, try to discover the inventor of the algorithm, include Knuth's analysis, etc.)

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I also think that the history trail on top of main.c in Crafty is a wonderful idea. We should all do something like that with our programs.

[Zach Wegner]

I have seen parts of the Wiki.

I think my contributions would be minor compared to true experts on the subject.

I do have a suggestion:
Create the site like a reference work (IOW, if discussion is about alpha-beta, try to discover the inventor of the algorithm, include Knuth's analysis, etc.)

Not a bad idea, and it is done in some places. Many times the pages are just "stubs" giving the basic idea of algorithms. There is room for expansion in all areas of the wiki, except perhaps some of the technical bitboard articles (Gerd is very thorough). You are encouraged to update it! I will approve you if you register...

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I also think that the history trail on top of main.c in Crafty is a wonderful idea. We should all do something like that with our programs.

I like the history idea, but I have mine in a separate file. It bugs me to see all of that at the beginning of Crafty's main.c. The other thing I do is write a comment at the top of every function that specifies what it does, when it was created, and when it was last modified. The modify dates are off in some places, but for the most part they are accurate. It gives a good idea where I've been working recently.

[Gerd Isenberg]

I have seen parts of the Wiki.

I think my contributions would be minor compared to true experts on the subject.

I do have a suggestion:
Create the site like a reference work (IOW, if discussion is about alpha-beta, try to discover the inventor of the algorithm, include Knuth's analysis, etc.)

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I also think that the history trail on top of main.c in Crafty is a wonderful idea. We should all do something like that with our programs.

Dann, your suggestions are very much appreciated.
Of course contributing to the wiki should be fun and no obligation.

The strange thing is, that I sometimes feel my vanity hurt, if somebody explains stuff which is mentioned in the wiki as well - and act like a thin-skinned wisenheimer. Sorry for that. I will try to do better.

Gerd

[Tord Romstad]

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I like the idea, especially for a program like mine, which is not designed with the purpose of being a competitive program, but rather to serve as an instructional example and a vehicle for research and experimentation.

The main problems are that it would take a lot of time (especially because it would often be quite difficult to find the origin of the algorithms), that I find it difficult to program when my code is too cluttered with comments (there are already far too many comments for my taste in Glaurung 2), and that I am not familiar with any of the literate programming tools for C/C++.

Does anyone have any experience with CWEB? Is it easy to install on Unix systems, and is there a comfortable Emacs mode for it?

I like the history idea, but I have mine in a separate file. It bugs me to see all of that at the beginning of Crafty's main.c.

I also prefer a separate file.

The other thing I do is write a comment at the top of every function that specifies what it does, when it was created, and when it was last modified. The modify dates are off in some places, but for the most part they are accurate. It gives a good idea where I've been working recently.

For me, the Darcs change log satisfies all such needs. I keep my commits as atomic as possible, and always include the name of the modified function(s) and a brief description of the changes in my comment. When I want to know when I last changed my quiescence search, I just search for "qsearch" in the Darcs change log. This avoids the need to clutter my code with comments explaining the last time something was made, and also makes it easy to get a quick summary of the entire history of every function, not just about the most recent change.

Tord

[Uri Blass]

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I like the idea, especially for a program like mine, which is not designed with the purpose of being a competitive program, but rather to serve as an instructional example and a vehicle for research and experimentation.

The main problems are that it would take a lot of time (especially because it would often be quite difficult to find the origin of the algorithms), that I find it difficult to program when my code is too cluttered with comments (there are already far too many comments for my taste in Glaurung 2), and that I am not familiar with any of the literate programming tools for C/C++.

Does anyone have any experience with CWEB? Is it easy to install on Unix systems, and is there a comfortable Emacs mode for it?

I like the history idea, but I have mine in a separate file. It bugs me to see all of that at the beginning of Crafty's main.c.

I also prefer a separate file.

The other thing I do is write a comment at the top of every function that specifies what it does, when it was created, and when it was last modified. The modify dates are off in some places, but for the most part they are accurate. It gives a good idea where I've been working recently.

For me, the Darcs change log satisfies all such needs. I keep my commits as atomic as possible, and always include the name of the modified function(s) and a brief description of the changes in my comment. When I want to know when I last changed my quiescence search, I just search for "qsearch" in the Darcs change log. This avoids the need to clutter my code with comments explaining the last time something was made, and also makes it easy to get a quick summary of the entire history of every function, not just about the most recent change.

Tord

Your program is clearly designed to be competitive based on rating lists

http://www.husvankempen.de/nunn/40_120_ ... glist.html

Glaurung2.01 has a bigger rating than Junior10.1 and even if you compare with some newer program like hiarcs the gap is not big and glaurung scores more than 40% against hiarcs.

Uri

[Tord Romstad]

Your program is clearly designed to be competitive based on rating lists

http://www.husvankempen.de/nunn/40_120_ ... glist.html

Glaurung2.01 has a bigger rating than Junior10.1 and even if you compare with some newer program like hiarcs the gap is not big and glaurung scores more than 40% against hiarcs.

That a program isn't designed to be competitive does not imply that it cannot be competitive. It's possible to be stronger than Junior without ever having beating Junior as a specific goal.

Tord

[Tony]

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I like the idea, especially for a program like mine, which is not designed with the purpose of being a competitive program, but rather to serve as an instructional example and a vehicle for research and experimentation.

The main problems are that it would take a lot of time (especially because it would often be quite difficult to find the origin of the algorithms), that I find it difficult to program when my code is too cluttered with comments (there are already far too many comments for my taste in Glaurung 2), and that I am not familiar with any of the literate programming tools for C/C++.

Does anyone have any experience with CWEB? Is it easy to install on Unix systems, and is there a comfortable Emacs mode for it?

I like the history idea, but I have mine in a separate file. It bugs me to see all of that at the beginning of Crafty's main.c.

I also prefer a separate file.

The other thing I do is write a comment at the top of every function that specifies what it does, when it was created, and when it was last modified. The modify dates are off in some places, but for the most part they are accurate. It gives a good idea where I've been working recently.

For me, the Darcs change log satisfies all such needs. I keep my commits as atomic as possible, and always include the name of the modified function(s) and a brief description of the changes in my comment. When I want to know when I last changed my quiescence search, I just search for "qsearch" in the Darcs change log. This avoids the need to clutter my code with comments explaining the last time something was made, and also makes it easy to get a quick summary of the entire history of every function, not just about the most recent change.

Tord

Your program is clearly designed to be competitive based on rating lists

http://www.husvankempen.de/nunn/40_120_ ... glist.html

Glaurung2.01 has a bigger rating than Junior10.1 and even if you compare with some newer program like hiarcs the gap is not big and glaurung scores more than 40% against hiarcs.

Uri

Yeah, Tord must be lying.

He is always doing that.

Tony

[Dann Corbit]

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I like the idea, especially for a program like mine, which is not designed with the purpose of being a competitive program, but rather to serve as an instructional example and a vehicle for research and experimentation.

The main problems are that it would take a lot of time (especially because it would often be quite difficult to find the origin of the algorithms), that I find it difficult to program when my code is too cluttered with comments (there are already far too many comments for my taste in Glaurung 2), and that I am not familiar with any of the literate programming tools for C/C++.

Does anyone have any experience with CWEB? Is it easy to install on Unix systems, and is there a comfortable Emacs mode for it?

I suggest that you might contact Ben Pfaff, author of Libavl, who used it to create his program in book form:
http://www.stanford.edu/~blp/avl/

I like the history idea, but I have mine in a separate file. It bugs me to see all of that at the beginning of Crafty's main.c.

I also prefer a separate file.

The other thing I do is write a comment at the top of every function that specifies what it does, when it was created, and when it was last modified. The modify dates are off in some places, but for the most part they are accurate. It gives a good idea where I've been working recently.

For me, the Darcs change log satisfies all such needs. I keep my commits as atomic as possible, and always include the name of the modified function(s) and a brief description of the changes in my comment. When I want to know when I last changed my quiescence search, I just search for "qsearch" in the Darcs change log. This avoids the need to clutter my code with comments explaining the last time something was made, and also makes it easy to get a quick summary of the entire history of every function, not just about the most recent change.

Tord

[Dann Corbit]

I even think that chess programs should be written in this manner (for each algorithm, cite the origin and briefly describe the intention).
That is my notion of literate programming. Literate programming should literally be like writing a reference book.

I like the idea, especially for a program like mine, which is not designed with the purpose of being a competitive program, but rather to serve as an instructional example and a vehicle for research and experimentation.

The main problems are that it would take a lot of time (especially because it would often be quite difficult to find the origin of the algorithms), that I find it difficult to program when my code is too cluttered with comments (there are already far too many comments for my taste in Glaurung 2), and that I am not familiar with any of the literate programming tools for C/C++.

Does anyone have any experience with CWEB? Is it easy to install on Unix systems, and is there a comfortable Emacs mode for it?

I like the history idea, but I have mine in a separate file. It bugs me to see all of that at the beginning of Crafty's main.c.

I also prefer a separate file.

The other thing I do is write a comment at the top of every function that specifies what it does, when it was created, and when it was last modified. The modify dates are off in some places, but for the most part they are accurate. It gives a good idea where I've been working recently.

For me, the Darcs change log satisfies all such needs. I keep my commits as atomic as possible, and always include the name of the modified function(s) and a brief description of the changes in my comment. When I want to know when I last changed my quiescence search, I just search for "qsearch" in the Darcs change log. This avoids the need to clutter my code with comments explaining the last time something was made, and also makes it easy to get a quick summary of the entire history of every function, not just about the most recent change.

Tord

Your program is clearly designed to be competitive based on rating lists

http://www.husvankempen.de/nunn/40_120_ ... glist.html

Glaurung2.01 has a bigger rating than Junior10.1 and even if you compare with some newer program like hiarcs the gap is not big and glaurung scores more than 40% against hiarcs.

Uri

If, for instance, his intention were to write the strongest program in the world and be world champion at WMCCC, it would clearly be in his best interest to hide his own code. Hence the goal is not purely strength, but the strength is a byproduct of other goals.

Let's call the amazing ability of his program an "accident of excellence." It comes from writing solid, bug free code in a modular and extensible fashion according to an excellent design vision.

Fruit's excellence had much the same origins.