Well first of all I have no clue which level is last, if there is a last level. And Segfault's algorithm can't be up to much taking forever between 100 and 108... I mean I haven't even written a program yet, and I'm on Level 35, and the difficulty isn't exactly shooting up, at least in my eyes. Anyway, I've got my own idea for an algorithm. Complicated maybe, but if I can implement it, I should be in first place quite soon...
Can anyone come up with a fiendishly difficult puzzle for this game? I'm not even sure what a really hard one is meant to look like so far.
How hard is this puzzle?
-
- Posts: 67
- Joined: Sat May 05, 2007 6:11 pm
- Location: San Carlos, CA
- Contact:
Re: How hard is this puzzle?
Much of that is that I haven't been running it all the time.ShardFire wrote:And Segfault's algorithm can't be up to much taking forever between 100 and 108...
I have a few ideas that might improve it somewhat, though I've been primarily concentrating on Modulo recently...
Re: How hard is this puzzle?
yes, whatever you sayCaptain Segfault wrote:Much of that is that I haven't been running it all the time.
Re: How hard is this puzzle?
ShardFire, Ha-ha... You have written so beautifully and dared, but still on level 36 is.
let's go
let's go
Compared to modulo, where I cannot find a trick to improve the solver (except constant speedup by multithreading ... everything else was natural) ... brickolade seems to be reach of possible improvement paths compared to simple bruteforce. ... Move (in) dependency is what makes this puzzle really interesting.
Early cuts could improve bruteforce to some level, but I suppose dependency analysis and some kind of dynamic programming would be required to pass higher levels.
Hmmm, I did 76 manually faster than the simple code ...
... And the same with 103 and 108, 109 ...
I have recoded whole the solver to make it persistent as much as possible ... and seems I gained almost no speedup ... let me hope the added statistics would sppedup the "early cuts", whose were slowing down the original version.
Early cuts could improve bruteforce to some level, but I suppose dependency analysis and some kind of dynamic programming would be required to pass higher levels.
Hmmm, I did 76 manually faster than the simple code ...
... And the same with 103 and 108, 109 ...
I have recoded whole the solver to make it persistent as much as possible ... and seems I gained almost no speedup ... let me hope the added statistics would sppedup the "early cuts", whose were slowing down the original version.