Complex Plotting App

[Han]

(02-12-2015 06:29 AM)dwgg Wrote:  

(02-07-2015 06:02 AM)Han Wrote:  Usage: Plot(r) where the initial resolution is a grid of squares of size \( 2^r \times 2^r \). On the emulator, this modified version takes half the time vs. the original. On the calculator, the modified version takes 75% of the time of the original.

Thank you Han for the improvement. I tried the modification and it does get rid of redundancy and improve the performance of the program. Moreover, since we are only drawing uncalculated pixels there is almost no time penalty in doing progressive resolution compared to doing pixel level single sweep.

Also adding one comment regarding conformality (I am learning more about complex analysis as I am further working on this program), it looks like you can indeed check conformality by checking contour grids: Conformality breaks where the contour is breaking up. You can read further in below link:

http://www.mai.liu.se/~hanlu09/complex/d...icode.html

Comparing with complex graphs I see from above link, I think now that in terms of graph features this program is meeting many of what one would look for in complex graph.. I think what we could improve further on is as below:

1. Any further speed improvement (if possible)
2. Capability for saving previous calculated plots and using it to redraw if function is not modifed (like Graph3D... so we don't have to keep redrawing when we come back)
3. Tracing feature (based on re and im coordinate print out z value)
4. implement option for edge detection filter for the contour lines so the contour lines are of uniform width (see further info in above link).

Up late grading; thought I'd respond before bed…

1. I wonder if PIXON_P (as opposed to RECT_P) would be any faster for r=1 since we're only drawing a single pixel (fewer flops for sure since some arithmetic is done for computing the dimensions of the colored squares.

2. This can be done; not sure about data set sizes (in terms of storage) but you could perhaps just store the evaluation of the function at x+yi. The color can be calculated (slower but less storage needed -- up to you). You can even predefine an array of size 320x240 and simply save the output values in entry (a,b) -- see the variables in the loop -- as those are also the top left corners of each colored square.

3. Shouldn't be hard once #2 is added on.

4. This can be done using a dynamic list of lists. Each list within the list would correspond to a single contour level. You can expand each contour level list with concat; same goes for the container list. (Graph3D uses some similar for its cross-sections shown during trace mode). The idea I have in mind may be way to slow, though. That is, each new contour point is compared with existing points within its contour-level list. You would need to design an algorithm to decide whether or not a new contour point gets added based on the currently existing list of contour points (perhaps a simple distance calculation to see if the new point would create a new "vertex" for the contour line as opposed to simply making the contour line thicker). (I have not read the link so this may be a very poor idea to actually implement.)

Edit for #4: Or perhaps just compute the image of the lines x+0i and 0+yi under the function f and use LINE_P.

#5. Add a feature for different "color" schemes (I actually find the yellow -> red -> black to be quite pleasing to my eyes) and even allow users to use a 320x240 image for the mapping (as opposed to colors).