@articuno12 Is our implementation of genetic algorithms complete? I am not sure if the test is guaranteed to pass - is there a (rare and unfortunate) case where the code terminates without generating a perfect solution? If there isn't, then this is perfect, but otherwise it may make sense to have a different test case than the current one.

@kaivalyar As stated in the pseudo code in fig 4.8 : "Run until some individual is fit enough, or enough time has elapsed return the best individual in population , according to FITNESS -FN" , so genetic algorithm will terminate if the solution is found , otherwise it has to be stopped after some time.In second case , it will obviously not return a perfect solution.And some time bound has to be given otherwise the algorithm can keep on running infinitely. @norvig Am I right?
For the test case I have added , it will give perfect solution because of the time I am running it for.As it is random based algorithm so I tried that testcase for several times and it was giving perfect solution everytime (10000/10000). It is also giving perfect solution for 4 queens problem . But when N is made greater than or equal to 6 , it may or may not give perfect solution . This is because of the size of population . Increase the size or increase the time , chances of perfect solution will increase.

Hi @articuno12, there are now some conflicts with your PR. May you resolve them?

#501 implements GA. This PR can be closed.

@Chipe1 I guess this PR was made way before so there shouldn't be more PRs afterwards doing the same thing. @norvig I cant understand what open source rules this organisation follows !

Mr. Norvig took a break for a while, and this PR must have slipped through the cracks. It's unfortunate, but stuff like this happens.

@articuno12 I'm sorry it was a misunderstanding on my part. I thought this PR was made to work with GAState in #480. But when GAState got removed in #501 I assumed this PR would no longer work. According to the discussion in #511 that seems to not be the case.
There were a few old PRs which were unmerged and now don't work due to merge conflicts or design changes. I thought I'd just comment on those PRs to help clear up the repository.

Personally I feel GAState is not needed. We can seemingly do everything in the class while also adhering more to pseudocode.

It would be interesting though to have the algorithm solve problems given by the problem classes in the module, even though that's not exactly needed due to the nature of the algorithm. Your genetic_search accomplishes that. I would like to see you modify the function to fit in with the current implementation.

Perhaps we could open an issue on GitHub to discuss whether or not to use GAState. Just to separate that discussion from this one, I guess.

@kaivalyar: Since this PR deals with the topic, I think it would be best if we discussed it here to keep things as much in order as possible.

Personally I feel we don't need GAState. All that the class does is store the genes of an individual state and implements the functions of mutation and reproduction.

Since the genes are in string form though (thus are simple), it would be best to simply store them as strings and then have the functions of mutation and reproduction as stand-alone functions. This will not only keep things simpler, but will also keep the code closer to the book. In the book, the aforementioned functions are not properties of the individual states, so they shouldn't be in the code either.

My feeling is that we don't need GAState -- when in doubt, keep it simple. I think that individuals should be sequences (not necessarily strings). I apologize for being away from this project while I attended to other duties, and not resolving this issue earlier.

I think there is some merit to keeping GAState - it allows the code to be extendable. If, for a slightly different problem, somebody wishes to define the state differently than a string, then inheriting from GAState is a good option that would be lost if we use strings. In fact, I was thinking of adding a small example that does this to the Jupyter notebook too.

Of course, as @norvig mentioned, this does have the flipside of slightly more complicated code - but I think this can be overcome by documenting GAState correctly and extensively.

I agree with @kaivalyar that a str is too restrictive a type. But I think that it is ok to assume that each individual is a mutable sequence. Then there would be two operations on these sequences: mate(a, b) returns a[i:] + b[i:]; and mutate(a, values) does a[i] = random.choice(values). So for most problems, individuals are lists, and everything works fine; the code is simple. But if you want to define a custom class, you just need to define getitem and add methods, and you can do whatever you want. Do you think that works?

Yes, this seems like a simple and extendable solution - better than using strings or GAState, in my opinion.

Perhaps an example demonstrating how to define a custom class would be helpful in the Jupyter notebook, and the simplified genetic_algorithm can be kept in the .py file.

I agree with individuals as lists. When writing the code, this is where I wanted it to go, but didn't get a chance to make it happen at the time. I think the code needs very few modifications to go from strings to lists.

I'm not entirely convinced though that we need a class for it. Is it possible to give us an example of when a class would be better than a list?

I don't think we need to have a custom class defined beforehand - it's just that using lists keeps that option potentially open. There may be cases where this helps, I am unsure of exactly where, but it is hard to think that lists would cover all use cases students would ever want to explore Genetic Algorithms with.

As for the GA implementation within the code for this project, using the built-in Python lists seems to be the simplest and best solution. Its just that others studying aima-code may choose to extend our code, and will have the option to do so.

I made the to-list changes on #523.