The researchers started by sketching out the problem they wanted to solve in Python, a popular programming language. But they left out the lines in the program that would specify how to solve it. That is where FunSearch comes in. It gets Codey to fill in the blanks—in effect, to suggest code that will solve the problem.
A second algorithm then checks and scores what Codey comes up with. The best suggestions—even if not yet correct—are saved and given back to Codey, which tries to complete the program again. “Many will be nonsensical, some will be sensible, and a few will be truly inspired,” says Kohli. “You take those truly inspired ones and you say, ‘Okay, take these ones and repeat.’”
After a couple of million suggestions and a few dozen repetitions of the overall process—which took a few days—FunSearch was able to come up with code that produced a correct and previously unknown solution to the cap set problem, which involves finding the largest size of a certain type of set. Imagine plotting dots on graph paper. The cap set problem is like trying to figure out how many dots you can put down without three of them ever forming a straight line.
I mean, I would also call genetic algorithms a form of brute forcing. And just like with genetic algorithms, this approach is going to be severely limited by the range of values that can be updated and the ability to test the outcome.
Why would you not be able to test the outcome fully? And what do you mean by “limited by the range of values that can be updated”?
So they configured the experiment so that only certain lines of code were able to be iterared/updated. Maybe you could ask it to start from scratch, but I imagine that would increase the time for it to converge (if it ever does).
Regarding testing, not all mathematical proofs can be verified by example. Here they were trying to prove that there was an even lower bound for the problem, but not all proofs will work with that structure.