The population minus the winner.michiguel wrote: Who's everybody else in that case if he ends up with one player? That is why I asked.
As for why ending up with one: I don't do threesomes.
Moderators: hgm, Rebel, chrisw
The population minus the winner.michiguel wrote: Who's everybody else in that case if he ends up with one player? That is why I asked.
That is evolution like Genghis Khan = become a King and impregnate everybodyGian-Carlo Pascutto wrote:The population minus the winner.michiguel wrote: Who's everybody else in that case if he ends up with one player? That is why I asked.
As for why ending up with one: I don't do threesomes.
It's a matter of which learning algorithm you use. I prefer PBIL which is population based incremental learning as it's more modern that the old fashioned and less efficient genetic algorithm. The compact genetic algorithm is a modern improvement it you like GA which works on the same principles. The principle I'm talking about is that you simulate an infinite population (that is what the "compact" is all about) and thus get much more diversity without having to actually store an infinite population. You get the best of both worlds.michiguel wrote:I am asking a question that you are not answering. I understand what you are saying. I am just trying to know what is your rationale for your decision of ending up with few players rather than more.Don wrote:Why is this so difficult to understand?michiguel wrote:
I agree with what you say, except that I do not understand why you want to end up with "one" best player. I should be better to end up with a set of good players, not one. Otherwise, all the evolutionary mechanisms are not working. It would be more like a breeding process. What do you do after you end up with the best? I may not be understanding your set up.
Let's assume we have a 2 bit gene or chromosome or whatever you call it for simplicity. An infinite population is represented by 2 floating point values which correspond to each bit in the gene. If the floating point value is 0 it means the entire population is compose of a zero bit in that place. If the bit is 1 it means the entire population has bit set to 1. And anything in between corresponds to the ratio of ones to zeros in the infinite population. So there are two floating points numbers, one for each of the 2 bits in the chromosome. Of course for a practical application it will have many bits.Of course, I know that you can end up with n players.
It's pretty obvious that you can end up with as many players as you want. If you want 2 player, don't play the final round match. If you want 4, don't play the last 2 rounds.
Again, I am curious to know why you decided to end up with few players, and I would like to know what is the next step you do. Do you mate them? with whom? do you mutate them and start again and you do not mate them?
And you do not have to fear that this is "too precise" because all you are doing is plucking N players from a population (from an infinite population if you use the more modern and efficient CGA or PBIL.) These players will on average be very good players (which is what you want) but there is always a chance that some weak player will get "lucky" and win the tournament. You have perfect control over this by deciding how many rounds and how many games per match to play.
Miguel
Keep trying i'd say.ilari wrote:For a couple of years now I've been interested in tuning evaluation weights of a chess engine with a genetic algorithm. What has discouraged me are the disappointing results that others have gotten, and the huge amount of time it would take. But even though people smarter than me have tried it before and failed, there are a few reasons why I'm keen on discarding their results and doing it again:
Getting system time is difficult, even today.- The number of games that it takes to determine superiority between two engines of similar strength was horribly underestimated in the past experiments. Usually the whole learning process consisted of only a few thousand games, and in some cases just a few hundred.
I feel 1997-1999 world champs is an important milestone in computerchess.- The hardware they used wasn't very impressive by today's standards. Nowadays we have the tools to run a ton of games quickly, easily and concurrently.
Well there is some truths in this. In some total beginners engine if you randomly change something and implement some random 'enhancement' somewhere, based some texts you wrote down when listening for 2 minutes to HGM, then odds are big already it improves such engine. Additionally to that those written down thoughts make more sense when the engine is weaker.- In some experiments they wrote their own simple and very slow chess engine to tune. In this Master's thesis the author had an engine that could search only 3 plies deep under his test conditions. The population size, the number of games and the number of generations were also ridiculously small.
so true.- The number of evaluation parameters (weights) was usually small. Today's top programs have a large number of parameters, and because they depend on each other, it's tedious and difficult to hand-tune them. GA's on the other hand thrive when the number of parameters (genes) is large.
Well basically all this is a very bad idea because it has a few assumption mistakes. Mistake 1 is to assume we just want to tune the material values. Mistake 2 is to assume the material values are just 6 values.I've already written a GA library in C++, and I planned on plugging that to a somewhat modified version of cutechess-cli. I'd use the UCI protocol for the learning process, because UCI "spin" options could be easily used as learning parameters (genes) with a minimum and maximum value. The idea is that it would be possible to tune any UCI engine without modifying its source code, apart from converting eval weights to UCI options. So if the engine has options "PawnValue" and "KnightValue" the user could just tell cutechess-cli to use them as learning parameters.
Make something generic that benefits us all and which we can use as push button technology to test GA's.I was thinking of the following initial test conditions:
- Population size of about 100 individuals
- For each generation, every individual plays one game against everyone else. So 4950 games per generation. With 99 games per individual the fitness function will of course be far from perfect, but then again, there's already some randomness in Selection.
- Time control of a few seconds per game. For example, a tc of 4 seconds would mean 5.5 hours per generation, or 1.4 hours on a quad-core.
- As many generations as it takes to reach a global maximum
If the initial test shows any promise, I would consider increasing the population count and number of games per generation.
So what do you people think? Would this be a colossal waste of time? Any advice, corrections, encouraging/discouraging anecdotes?
It leads to faster convergence at the cost of some diversity.michiguel wrote: That is evolution like Genghis Khan = become a King and impregnate everybody
No worries, I was just using the two material weights as examples of how the tuning software would work. The goal is to tune all available evaluation weights of a top engine.Well basically all this is a very bad idea because it has a few assumption mistakes. Mistake 1 is to assume we just want to tune the material values. Mistake 2 is to assume the material values are just 6 values.
In case of diep already since summer 2000 or so the material is quite some parameter values. Like a 200+ or so, depending upon how you count.
That's my ultimate goal. Any code that I write will be available at a Git repository near you.Make something generic that benefits us all and which we can use as push button technology to test GA's.
Coding a GA optimization program is completely trivial. (Which is why there's so much academic material about it ) There will probably be much more work involved in making it generic or adapting any program to it than to the actual algorithm in the first place.diep wrote: Make something generic that benefits us all and which we can use as push button technology to test GA's.
All interesting stuff. You may also look at "Swam Learning". I'm not sure how applicable it is to chess parameter learning but I'll throw it into the mix in case someone hasn't heard about it. It's a nice cross between probabilistic and hill climb optimization. It's based on the natural model of a swarm of birds / ants / buffalo. Each member of the swarm has a set of genes representing the elements to be optimized. The genes are adjusted based on the host's fitness and the fitness of its healthiest neighbor. There are variations that also look at the single fitest citizen.Don wrote:Have you looked at PBIL, population based incremental learning?...
I'm mostly familiar with SA but it's a very similar idea of random mutation.ilari wrote:For a couple of years now I've been interested in tuning evaluation weights of a chess engine with a genetic algorithm. What has discouraged me are the disappointing results that others have gotten, and the huge amount of time it would take. But even though people smarter than me have tried it before and failed, there are a few reasons why I'm keen on discarding their results and doing it again:
Any advice, corrections, encouraging/discouraging anecdotes?