Difference between revisions of "Talk:Lake"

From LifeWiki
Jump to navigation Jump to search
(SAWs!)
Line 6: Line 6:


:: Oh, hmm... yeah, I see what you mean. At least about "loopy" - not seeing the problems with corners as easily. Well, I'm sure I'll semi-consciously puzzle over the matter for a while longer (a new plan that centres around just possible configurations of pieces is already beginning to emerge and will probably soon be beginning to be shot down), and see how that goes. [[User:Elithrion|Elithrion]] 04:05, 5 February 2009 (UTC)
:: Oh, hmm... yeah, I see what you mean. At least about "loopy" - not seeing the problems with corners as easily. Well, I'm sure I'll semi-consciously puzzle over the matter for a while longer (a new plan that centres around just possible configurations of pieces is already beginning to emerge and will probably soon be beginning to be shot down), and see how that goes. [[User:Elithrion|Elithrion]] 04:05, 5 February 2009 (UTC)
:: Okay, I have succeeded... in rephrasing the problem in a way that makes its nature clearer and my confidence in ever seeing a solution much much lower. What we're trying to '''count''' is '''the number of SAWs with three rules: they reach the origin at the last step, each step must be orthogonal to the one before, there is a total of [cells]/2 steps'''. I'm not even sure if this is easier than the boxed SAWs problem we have... on hold. On the bright side, some easy upper bounds are available! The most basic one is obviously just 2^k (k = [number of steps of the walk] = 4*n = [number of cells]/2)... and I'm a little alarmed by the amount of difficulty I'm having improving on that. Well, it can't be more than (3/4)*(2^k), since if you walk at random, 1/4 of the time you'll end up immediately making a loop (e.g. walking down and then right after by chance walking up and then left). This doesn't hold for k=4, of course. Similar reductions could be made for larger loops, but this would still leave us orders of magnitude off. So, I've got no other good ideas for now. [[User:Elithrion|Elithrion]] 05:54, 5 February 2009 (UTC)

Revision as of 05:54, 5 February 2009

Counting lakes

Re: lake-counting. An explicit formula seems reasonably doable, doesn't it? Adding 8 cells to a lake allows you to lengthen a pair of sides. Let's call the shape with one pair of sides having minimal length (and the other thus maximal) the basic shape. Then, you get a slightly longer basic shape, and from that you can modify the figure by shortening the long side/lengthening the short one to get all the other "straight-side" shapes. That's pretty trivial, and then, it's a matter of figuring out what you can do with the corners given those shapes. I'd guess that the number of corner-changing actions you can do is a function of the length of the shorter side and probably independent of the length of the longer one, which makes it easier. Of course, you might think that with my confident conjecturing and a decent amount of data to check theory against, I'd just go ahead and try to do this myself, but maybe later... Elithrion 03:04, 5 February 2009 (UTC)

I tried basically exactly what you said, but it became insane very quickly. The number of interactions between which corners you can and can't "bend in" seems to be much too complicated to get a hold on. Also, one problem with just considering the "convex" lakes and distorting them is that you can never get "loopy" lakes (which can only exist for large n). By "loopy" I mean like if you were to put a 2D sausage around a spiral and use its border as a lake. Feel free to try though, you've got some data to compare your results with now at least. Nathaniel 03:24, 5 February 2009 (UTC)
Oh, hmm... yeah, I see what you mean. At least about "loopy" - not seeing the problems with corners as easily. Well, I'm sure I'll semi-consciously puzzle over the matter for a while longer (a new plan that centres around just possible configurations of pieces is already beginning to emerge and will probably soon be beginning to be shot down), and see how that goes. Elithrion 04:05, 5 February 2009 (UTC)
Okay, I have succeeded... in rephrasing the problem in a way that makes its nature clearer and my confidence in ever seeing a solution much much lower. What we're trying to count is the number of SAWs with three rules: they reach the origin at the last step, each step must be orthogonal to the one before, there is a total of [cells]/2 steps. I'm not even sure if this is easier than the boxed SAWs problem we have... on hold. On the bright side, some easy upper bounds are available! The most basic one is obviously just 2^k (k = [number of steps of the walk] = 4*n = [number of cells]/2)... and I'm a little alarmed by the amount of difficulty I'm having improving on that. Well, it can't be more than (3/4)*(2^k), since if you walk at random, 1/4 of the time you'll end up immediately making a loop (e.g. walking down and then right after by chance walking up and then left). This doesn't hold for k=4, of course. Similar reductions could be made for larger loops, but this would still leave us orders of magnitude off. So, I've got no other good ideas for now. Elithrion 05:54, 5 February 2009 (UTC)