First up this week, I think I figured out what was causing the incompatibilty problem where seed shape files saved by one version were unloadable by the other. It's an issue with serialization - some changes must have been made to the SeedShape and Segment classes between the two versions, so the saved (serialized) instances are not recognized as the same class. Since I'll be introducing a version 3, I might make a translating program to read all the old saved shapes, create instances of the newest version, and re-serialize them.
___
The next thing I did was notice and fix a problem with two of the types of replacement lines. Both yellow and blue lines replicate the shape reflected across an axis perpendicular to the baseline. In order to do that, the code reversed the order of the points in the shape from left to right; however, the segments were still iterated through in the old order, so the segment information was not lining up with the correct endpoint information.
___
The most interesting task this week was to recreate the fractal dimension calculating part of the program (since we didn't have the source code for that part). Dr. Krishnamoorthy gave me the C code originally used by my predecessor as a basis - it approximates solutions to polynomial equations, such as Moran equations (equations relating the dimension of a self-similar fractal with the various ratios of scaling used in replication). So all I had to do was translate this to java and add a bit to construct the Moran equation of a given fractal, and voila, I can compute the dimension of Sierpinski's triangle to be 1.58496 +- .00001. That's even better than wikipedia. I still need to do some work making it display prettily and figuring out when to calculate it for maximum efficiency.
Also, there are some problems with this approach (though I think it's good enough for its purpose).
First, the algorithm doesn't take into account how much the lines of the shape overlap each other. For instance, if the shape is made up of several replicating lines positioned so that it looks like one straight line (and continues to look so in all iterations), one would think the dimension should be 1. But the algorithm treats it the same as if all the lines were skew and non-intersecting, in which case the dimension is usually > 1. The algorithm gives this dimension to both cases. However, since nobody's really interested in making replicating shapes that look like line segments for eternity, I don't think this is a real problem. (If even part of a seed shape overlaps itself, or if subsequent iterations layer lines over each other exactly, the same problem occurs to a less noticable extent, but again, I don't think it happens often enough to be a problem and it is nearly always avoidable.)
More worrisome is what happens when there is only one replicating segment: if there is no other information in the shape and the segment's scaling ratio is <1, the algorithm gives a dimension of 0 which as far as I've been able to read seems to be ok; however, if there is other information (inactive, non-replicating segments that will get replicated by the one active segment), the dimension certainly shouldn't drop to 0, but since the algorithm ignores inactive information it still does. An example of this is a logarithmic spiral:
The applet version currently on the site gives it a dimension of 2, my code gives it a dimension of 0, and I've read it should really have a dimension of 1, though I don't know the reasoning behind that. A more intuitive example is this one:
It's pretty obvious this should be 1-dimensional, but again the old version gives 2 and my version gives 0.
Also, the Moran equation is only valid when all of the scaling ratios are < 1; if a fractal spreads without limit this method is not applicable.
___
Another priority for this week was to fix an inconvenience with entering a value for line thickness: one used to hit "enter" after typing in the value to make it update, which was mightily convenient but entirely unintuitive. We settled on making it auto-update with every keystroke in the textfield as the best solution, and I think it works beautifully.
___
One more thing I did was fix an annoyance where the edit-panel would lose the keyboard focus after certain buttons (like "Clear") were clicked and therefore wouldn't be able to receive keyboard input again till a double-click point-creating action was made; this made deleting points at certain times impossible. Now the panel requests the focus again every time the mouse moves over it.
___
No comments:
Post a Comment