I have indeed tried profiling it, which did further frustrate me :P
I have kept spoilers to an absolute minimum in these images:
The original version performs worst on input 13 with a max of 301 cycles, where, the A=D:y branch is hit 5 times. The improved version, which simply moves the A=B test up one space to exclude B join A when A=B:y, performs worst on input 26 with a max of 308 cycles, where the A=D:y branch is hit 8 times. This even makes it score 2 points less (357 vs 359..).
As you can probably understand, this makes it very frustrating to hunt for the 'best' 360 solution as it just feels like moving stuff around at random and preying to RNGesus. I'm not sure if this is fixable but I was hoping some of the "highly-regular" RNG's that I did notice in earlier levels could provide a consistent worst case for this level.
You're right about that - the previous RNGs are back, and I believe that this issue is fixed now. Thanks for reporting it!
I've checked the option of a global RSS feed. Specifically, detecting changes in scoring thresholds and filtering the inconsequential ones is tricky to do automatically. There are other changes that are easier to notify of (e.g. to the leaderboards), but I don't think many players will be interested in such a mechanism (it will also be spammy).
I can give a heads up about my intention to reject the brute-force threshold for D8, one way or another. Other than that, it all depends on the people playing the game. Just make sure to save your savefile to a file so as not to rely on the browser's local storage policy for keeping it intact.
Thanks for fixing G3.
I like out of the box solutions and that includes my D8 solution :P The exponential nature of the level makes it very attractive for unrolling, nothing wrong with that :P Especially because its just one level where it even is viable in the first place, and considering the cost tradeoff it will never affect the normal solutions.
If larger test cases are added, it will first of all start lagging the game quite hard and secondly, it will still always be more optimal to hardcode the bottom layers and add a proper iterative algorithm ontop of this. You could restrict the number of workers but this will invalidate a large potion of current solutions aswell as add significant difficulty for future players, and it will just bloat the root score instead if that option will be available.
Another alternative would be to just hard limit the cost but that would be quite lame. Overall I think you should just come to terms with the solution considering that it only really affects this level.
If the cost graph is the problem, why not make it logarithmic (for this level only maybe considering the exponential nature) and/or implementing a graph break?
This is less about technicalities (the threshold is already excluded, so it doesn't affect other players' scores or graphs), and more about the concept that solutions work in the general case. If you need to change your algorithm whenever new test cases are added, then I don't consider it a valid solution, and I'll work to improve the test cases until it is invalidated.
Brute-forcing is actually the easiest one for me - it's evident from the graphs and doesn't require a "prove or disprove" process (recall that I handle players' solutions as black boxes). And D8 is not special in this respect, previous cases that I've invalidated included a solution that assumed out-degree <= 5 or so (I'm sure that it was out of the box...)
Note that this approach doesn't preclude loop unrolling as an optimization strategy. The game does favor minimal and elegant solutions (that's why cost is calculated as it is, and why certain achievements exist), but score is determined equally as a function of cost and cycles (i.e. commutatively).