It’s in Java 1.5, multi-threaded. Could be potentially re-coded in Luma… or obj-c. But then it would lose its portability.
Sharing the sources (for free) doesn’t sound apealing to me. But, if you send me a level, I could feed it to solver and provide you the results of the analysis.
I’m also planning to deploy the Solver to Google App Engine to use their computing power and to let others try the solver.
@blaker, no problem, your work, you decide how to share! I think it’s super cool.
Do you prune the search tree at all? eliminate a conditional instruction if that color doesn’t appear in the puzzle for example? Or avoid going left first if the crane starts on the left? etc,etc
Ofcourse, I eliminate most of the combinations, which won’t work before trying them. I take into account: the colors, the calls (if prog is defined, it should be called), the presence of all types of commands (should be at least one left, right and down), the prog length (at least 2 instructions) and many other things. I don’t check for going left if crane starts at 1st postion, because it will just immidiately fail on the trial run.
I also eliminate most of the equivalent solutions. Suppose you have a 3 prog solution, so if you exchange progs 2 and 3 (and the calls) it will be equivalent and doesn’t require checking.
Only thing I have dificulty with is detecting the infinite loops. So I just currently try each program for at least 1000 iterations, and if it doesn’t lead to solution, I consider it infinite loop. Any ideas on faster detection of the infinite loops are welcome!
@blaker, will have a think. One simple consideration is whether the state repeats. If the cranes + crate + program pointer combination ever repeats, then you know it’s looping. That would quickly catch programs like L, R, F1
@blaker, you need to compare the stack contents as well. But, on the other hand, the contents of the stack may change due to recursion even if the overall state does not.
Explanation of Come Together.
I have seen the solution for Come Together, but I don’t understand why it works.
The solution is Prog 1. = Prog2, down, prog 1
Prog 2. = If none go right, down, if none Prog 2, left.
What I don’t get is why the final left arrow keeps sending the boxes left more than once, as opposed to left a single time. Can anyone explain this simply to a crumbly over 50?
I’ve been playing with a solver lately as well, if I can get the code cleaned up I’d be happy to share it here. To help solve the infinite loop problem I actually run 2 simulations at once, with one advancing a single step per iteration and the other advancing two. If the two states are ever the same then it means we’re in a loop (this is a commonly used algorithm to detect loops in linked lists, which is effectively what the state diagram for this game is for any given simulation). Of course, it doesn’t detect loops that affect the stack, but it trims a massive portion of the search tree none-the-less.
What we really need is a GPU solver. By way of example Bitcoin mining is over 500 times faster on a modern graphics card than a modern CPU. The biggest problem would be figuring out how to implement the stack efficiently, it might actually require a hybrid solution where the GPU is doing the bulk of the work and identifying candidates for closer inspection by the CPU.