Welcome to Fractal Forums

A slightly early Christmas present to y'all: a (slightly) deep M-set zoom I ran into on the way to deeper things. Because it only barely requires bignum arithmetic and the iterations are so low, the image could be rendered in only half an hour or so on my equipment. Consider it a bonus of sorts. :)

Without further ado...

(http://u5789.direct.atpic.com/24796/0/1666469/1024.jpg) (http://pic.atpic.com/1666469/1024)

A straightforward one-layer image colored by smoothed iterations, of a microbrot on the spike in the big minibrot's Elephant Valley. Zoom into a "cumulus" mini-julia on the spike, then at the spike between the left pair of big spirals, then into another mini-julia to find a microbrot similar to this one.

This one was right on the border between long double and bignum arithmetic, to the point that the 640x480 preview didn't use bignums but the final 2048x1536 render did.

Freely redistributable and usable subject to the Creative Commons Attribution license, version 3.0.

Detailed statistics:

Name: All Roads Lead To Rome
Date: December 23, 2009
Fractal: Mandelbrot
Location: Elephant Valley of big spike minibrot
Depth: Moderately Deep (21 decimals)
Min Iterations: 269
Max Iterations: 17,257
Layers: 1
Anti-aliasing: 3x3, threshold 0.10, depth 1
Preparation time: 10 minutes
Calculation time: 35 minutes (2.5GHz dual-core E5200)

Fitting name :)
Using the Rome analogy it looks a lot like centers of different size around rome. Each center (City) leads to smaller villages and they're all directly connected to the capital, Rome. Though, the direct way between two cities don't exist and one has to travel through rome to get from one City to the other.

To get from one Village to an other, one has to at least travel through the city in which they both lie - if they lie in different cities, one again has to walk through rome...

I wonder how effective or ineffective such a street sytem would be today... :)

So it takes 1/2 hour to render this as a 3x super-sampled 2048x1536 image? (6144  4608 samples) That is using "bignum" arithmetic? How many bits of precision are in "bignum"? Is it arbitrary?

Where did you get the math library to do your bignum calculations? My app uses long doubles to calculate pixel coordinates, and doubles for iterating. I haven't resorted to long doubles, even, because I want it to be fast. I've debated recompiling with long doubles, or even finding a higher precision than that. I think I would add a preference to switch between types so I could still offer fast calculations.

For comparison, I rendered a plot that looks a whole lot like yours, at lower zoom. I don't support super-sampling, so I rendered it at 6144x4608 pixels, and it took about 4 minutes. That's on a 2.4 ghz Core 2 Duo (2 core) Mac. It's definitely worth only using higher precision when you have to, since the native double precision on current hardware is VERY fast.

I used fractional iteration counts to get smooth coloring. If I had turned that off it would have been a lot faster because I would have been able to use boundary following That would enable me to not even calculate quite a few of the pixels.



Duncan C

Since the tendrils have infinite detail, they would be infinitely long. That might make travel a little slow...  :-\

Yeah, sure, though in a real life scenario you don't have an infinite iteration count, lowering the lenght....

In this case, 65 bits, just too many for the 64 bits of the x86 family FPU (C's "long double"'s precision on this hardware).


Probably not quite the same; perhaps the center of one of the "cumuli" instead of first finding a smaller one between two of the spirals of the bigger one?

 That's on a 2.4 ghz Core 2 Duo (2 core) Mac. It's definitely worth only using higher precision when you have to, since the native double precision on current hardware is VERY fast.


Actually, where that really comes into its own is with distance estimator images. Nearly the entire image can be skipped in some cases. The fastest algorithm for producing a DEM plot (or any plot) of the M-set uses boundary following, calculates interior distance estimates as well as exterior, at the screen edges jumps by the distance estimate of the previous pixel instead of one pixel at a time, and in the case of super-sampling, boundary traces at the scale of the smallest sub-pixels.

Actually, in this case many of the tendrils are basically just straight lines. (Some curve slightly, and some a lot more.) Most other areas of the M-set though and they would indeed wind and wiggle at every scale.

WOW!

This is my favorite of your recent stuff.  Stunning!

I think that what does it for me is the color scheme.  Brown/beige has always been my favorite.  It seems natural for some reason.

I think they call that "sepia".     :D
 

Thank you.

Ha!  You're right!  I guess it turns out that I'm just a fan of old photographs.  :)