if i do the same for a filled unit circle (disk) and decrease the size of my boxes (lets say take the right most picture with a box size of 1/8), x (or in the picture e) will be 1/8, just as for the square. But obviously it will not contain all 64 boxes, thus have a smaller dimension then 2.
The box counting algorithm only cares for the limit after infinitely many iterations. The problem you describe is a boundary error; i.e. something that happens at the rim of the circle, not deeper inside the disk. But as you keep halving box size, the number of boxes overlapping the circle rim is dwarfed by the number of boxes inside the disk. Eventually, what is happening inside the disk will dominate the ultimate outcome, and boundary effects become irrelevant.
Another way to see that circle and box really behave the same way is this: imagine the unit square is first rotated by some oblique angle, say, 31 degrees; but keep the grid for box counting upright. Then the square case will suffer from boundary errors, too. But obviously the nature of the square has not changed, so you still expect the same result.
(In fact, practical implementations of the box counting algorithm must apply a little extra effort to negate boundary artifacts. One way to do that is to randomly move the boxes' coordinate origin in every iteration, and even to rotate the box grid randomly in every iteration.)
October 25, 2012, 06:12:45 PM
Dilber MC Theme by HarzeM