Talk:Expansions/@comment-49697-20120821020450/@comment-5116140-20120821033101

Well There's Only One thing to do with a Tough Nut,

Get a bigger nut Cracker!!

Well, these is no doubt all these expansion anomalies are due to side-effects in new code. Without seeing the code, it would be hard to say more. I might be able to advance similar hypotheses as in my last post, that would generate more of the anomalies.

Seems some of the margin widths might involve integer division or modular effects.

Example 5/2 in integer division is 2 and not 3. (Java code)

And in the case of 4 on one side and 1 on the other, that 1 looks like it would normally be zero, but there is an of-by-one error, one of the most common logical errors in code.

The best I can say is that all of these quantities, left margins, right margins and even expansion costs are probably not set as constants but instead are calculated using formulas.

In these formulas appear an assortment of constants such as the width W, total number of expansions N and maximum expansion cost Cmax.

I suspect the formulas work just fine for a 70*70 grid, but some are misbehaving now because constants for the postulated larger grid are leaking in by mistake.

This hypothesis is broad enough to include all the expansion anomalies reported so far.

But not too useful I am afraid. I still suspect a bigger grid is behind it all.

It is very hard to imagine another generic and common software bug that could generate such a wide array of expansion anomalies. It has to be something like the theory advanced above, bad values leaking into formulas that used to work just fine. Some about-to-be-released upgrade is messing up their formulas. And lots of their formulas.