Author: Bob Durrett
Date: 17:21:34 10/27/02
Go up one level in this thread
On October 27, 2002 at 17:01:08, Ingo Lindam wrote: >On October 26, 2002 at 15:55:30, Bob Durrett wrote: > >>These are my "post-breakfast" thoughts. Again, I am still trying to see >>whether or not I understand what you are proposing. > >Well, I really believe in post-breakfast thoughts must be the best. >Unfortunately my breakfast is long time ago but I had a very good lunch and >cheesecake later. > >>Since the chess engine must find a move, we need to think about how that would >>be done using your "patterns." Please ignore the trivial case of getting the >>move from an opening book or an endgame tablebase. Let's limit ourselves to >the middlegame. > >This is a very clever simplification I appreciate. > >>Associated with each of the patterns you store in your computer [regardless of >>storage medium], there typically will be moves associated with that pattern. >>For example, if the pattern is the one associated with the thematic sac of a >>bishop on h7, then the bishop move Bxh7 could be the one associated with that >>pattern. Some patterns may have more than one move associated with it. One >>could generalize to include "combinations" assiciated with certain positions. >>For example, recall the familiar smothered mate involving the moves Nf7+, >>Kh8-g8, Nh6 dis. ch. [with the queen on the diagonal], Kh8, Qh8+ RxQ Nf7 >>smothered mate. This is a case of a combination being associated with the >>position fragment [which you call a "pattern."] > >My main idea of using patterns was to give the computer more positional >knowledge to judge about positions. It would be most interesting to read an elaboration on this idea/concept. For example: If the position [which occurred immediately after the Engine's opponent made his/her/it's move] being evaluated, perhaps you could associate it with a list of patterns which are "in" that position. If you have a high-quality set of reference patterns, and have enough of them, then you could "somehow" combine the evaluations of each relevant reference pattern and obtain a composite evaluation for the position. This is given without proof since I don't feel up to the task of producing a proof right now. Hence, I could be wrong. In other words, it may NOT be possible to represent a position under evaluation with a set of patterns [with their data]. But my gut feel is that "covering" the position with a well-selected set of patterns would be possible. Similarly, in the middle of [in the gory guts of] a search algorithm, maybe some of the positions occuring during the search could be evaluated the same way. In a purely serial machine [no parallel processing] I fear that the time required for this computation might not leave enough time for the rest of the search. In other words, "not competitive." If you are going serial, you have a big challenge to make your engine competitive with current engines which do not [?] use your idea. Parallel processing is another matter, given the requisite technology. Am I still at least "out in left field" on this one? [Still in the ballpark?] >Nevertheless I am aware that a statistical >choice of pattern will also lead to tactical motives and it might be hard to >distinguish. I as well thought at once of the motive of the smothered mate >probably will be found in a lot of games. When you find a pattern [no comment yet] >while running a training (or generation of pattern) on a huge data base you >may distinguish several classes of patterns also by the following moves after >the occurence of this pattern. I see a great doctoral dissertation, or maybe even a bunch of dissertations here. Alternatively, a well-funded research project. You envision producing a "black box" with inputs and outputs. The inputs would consist of one or two million master level chess games. The outputs would be a large set of patterns with associated properties &/or other useful data. Right? [If yes, then how?] Without spilling all my beans at once, let me just say that I see partitioning the complete set of possible patterns into classes but maybe not quite the way you suggested above. Each class would have defining properties and might or might not be represented by a single pattern. If a representative pattern is to be used, then somebody has to identify the characteristics of all similar patterns which would fall into the same class. When you look at a complete chess position to be evaluated, you must determine whether or not a pattern exists in that position which would fall into one of the classes. Then you must identify that class. Similarly for all other patterns in the position to be evaluated. Only then could you apply the information associated with that class with the position being evaluated. [Disclaimer: These are "half-baked ideas."] [Parallel processing!!!!] >This may lead to typical moves, plans or just to a method to >distinguish different pattern classes. This idea of using the moves following >the appearance of a pattern might make the whole thing more complex. The >response on my ideas here at CCC were more like telling me the problems or the >ambition of the ideas are two big (or just nonsense) so I don't really dare to >dream of generating plans (at first step). The main idea is just to use the >pattern to evaluate the position. Don't let anybody squelch your dreams! You eventually may laugh at all of them on your way to the bank! : ) [Like Bill Gates] Besides, those who do not dream are not alive at all. :( > >>Typically, a position occuring in a game [being played with the chess engine] >>may include dozens or even hundreds of position fragments for which you have >>patterns in your database [or table]. > >Well, I expect to find a number of pattern in a position to evaluate or a few >less but more complex pattern. Its hard to say what is a reasonable number of >pattern I should find and with how many pattern I could deal at which stage of >the evaluation process now. This is starting to look like more Doctoral Dissertations. They would answer the question: "How many is a reasonable number?" > >>In a parallel processing [or hybrid] implementation of your concept, there >>would >>be some process required to go from the information you have for the relevant >>patterns to the choice of move. > >Yes, if I want to use the pattern in a chess playing engine my engine has to >make moves and has to decide which to play (when possible a little bit quicker >than I do). > >>The various relevant patterns may each have one or more moves associated with >>it. Each such move could be considered to be a probability function of the >>pattern. P[move1] = etc. > >Well, this is ofcourse possible to associate moves with the pattern, but to make >the idea not failing by being to complex at first stage I would rather kepp this >in mind as an option and look how far it goes without linking moves or plans to >the pattern. But ofcourse you never should forget about this option. The pattern >come from games... and I search for pattern that name my position a winning >position. If I bring myself to a position that contains these winning patterns I >have automatically a lot of examples in my game data base how to win such a >position. > >>How do you decide which pattern should be taken more seriously? > >Well, I should take those pattern more seriously that apear more often... and >that lead to significant probabilities for P+, P= or P-. And here is the most >important reason to use three (or two) instead of a single score. When I find >nothing in a position I can value for white or for black I probably can just >score the position 0 (?). Don't might this lead to an optimization of the moves >into noland (knowing nothing about the position) as more as I evaluate the >opponents moves/positions the same way? My approach should (!) lead to >distingish seriously between draw and knowing nothing. I admit being confused by all this, but it sounds reasonable and I'm willing to give you the benefit of the doubt. > >>If there are hundreds of patterns in the position, there could easily be >>hundreds of moves, each associated with one or more of the patterns. Somehow, >>you must decide how to arrive at the one and only one move to play. I must >>admit that this is unclear to me at this time. > >A very natural possibility should be to use the pattern just to evaluate >positions. When I evaluate positions in a search tree that should lead me >automatically to make moves leading into positions I find more good pattern for >me than for my opponent. > >>Am I still on track? > >Ofcourse Bob... I don't expect you to leave the track. > >Ingo Generally, It seems to me that you would do yourself a disservice if you went to all the trouble of producing and then using the patterns just to obtain a position value. This seems like a lot of work to generate a lot of great information only to ignore 99% of your findings and then just use the remaining 1%. Specifically, it would be a pity if all the computations in current engines would still have to be done in your program. What would you save? [I would like to see ALL searching become ancient history; i.e. something on display at the Smithsonian Museum in Washington, DC, USA] Bob D.
This page took 0.02 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.