# Fractal rendering fun

This topic is 4421 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I discovered an interesting fractal pattern. This simple piece of code outputs it as an SVG. Please excuse the horrible hand-printing of XML. You need to give it one parameter, which is the number of points to plot. 10000 is reasonable, 50000 gives you a very nice image. I'd offer the SVG itself, but it's too big to put in a post and I have nowhere to host it.
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>

int main(int argc, char** argv)
{
double x = 2.7;
double y = 0.7;
int count = 0;
long iterations = 0;
FILE *outfile;

if (argc <= 1)
{
printf("Usage: %s iterations\n", argv[0]);
return 1;
}

outfile = fopen("argyle.svg", "w");
if (outfile == NULL) {
perror("Could not open output file");
return 1;
}

iterations = atol(argv[1]);

fprintf(outfile, "<?xml version=\"1.0\" standalone=\"no\"?>\n");
fprintf(outfile, "<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 1.1//EN\"\n");
fprintf(outfile, "\"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\">\n\n");
fprintf(outfile, "<svg width=\"8cm\" height=\"8cm\" viewBox=\"0 0 1000 1000\" \n");
fprintf(outfile, "version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\">\n\n");
fprintf(outfile, "<path d=\"");

srandom(time(NULL));

for (count=0;count<iterations;count++)
{
if(random()&01)
{
x = sin(x);
y = cos(y);
}
else
{
x = cos(x);
y = sin(y);
}

fprintf(outfile, "M %d %d l 1 1 ", (int)(x*1000), (int)(y*1000));
}

fprintf(outfile, "z\" fill=\"none\" stroke=\"black\" stroke-width=\"1\" />\n\n");
fprintf(outfile, "</svg>\n");

fclose(outfile);
return 0;
}


##### Share on other sites
Looks like this to me:

Appears to be some kind of IFS fractal.

Mark

##### Share on other sites
That's the expected result. What's interesting is that if you run it with a large argument, it becomes obvious that the "tails" of the diamonds overlap, and that the gaps remain distinct.

The really odd thing is that the random() calls seem to be necessary - using any more deterministic algorithm to "fairly" represent the two branches will not produce such a nice pattern. It's independent of the implementation of the random device as well.