Buddha's Jewel: a special subset of the Buddhabrot, symmetrical about both axis!

[Chris Thomasson]

As I understand it, the classic Buddhabrot plots iterates only of points that escape - points that don't escape are not plotted.  The anti-Buddhabrot plots iterates only of points that don't escape - points that escape aren't plotted.  Looks like you plotted both with different weights, giving some kind of hybrid "dark matter" Buddhbrot?

I wrote a post about the Ultimate anti-Buddhabrot, which plots only the limit-attractors of points that don't escape:  http://mathr.co.uk/blog/2013-12-30_ultimate_anti-buddhabrot.html  I did some other experiments around that time (late 2013) using something very similar to billtavis' technique, no pics online at the moment though (and will take me some time to trawl my hard drive to find them to upload, might instead take a photo on Sunday of the print hanging on my parents' wall...).

My technique was to trace (using Newton's method) external rays at pre-periodic external angles inwards towards the Mandelbrot set, stopping when the iteration count reaches a certain limit - then plotting all the iterates.  Pre-periodic angles land at Misiurewicz points, and for some reason still unknown to me they are much quicker to trace than periodic angles which land at cusps and bond points.  The other difference from billtavis' method was the colouring - I plotted iterates in colours corresponding to the external angle (in HSV colour space, the angle would be the hue).

If you don't split the rays into periodic and pre-periodic subsets, the pre-periodic part totally dominates - "most" angles are pre-periodic, and in fact any binary floating point representation will be pre-periodic (apart from the period 1 ray at angle 0).

Yikes! For some reason I missed the point where a classic Buddhabrot only takes note of iterations that escape!

:^o

Anyway, your "anti-Buddhabrot" looks very similar to the one I did.

Thank you so much for the information Claude!

:^)

[cKleinhuis]

@people developing a buddhabrot renderer, is there one to make a buddhabox ? (lol i know i am getting on your nerves .. )

[ker2x]

Buddhabrot are very everything-intensive.
In most "classic rendering" (non-buddha) fractal you can have 1 thread per pixel, which is very GPU-friendly and also memory friendly (and that's why it's gpu friendly, the memory is a massive bottleneck on gpu).

In a buddhabrot you have to do the usual stuff, to test if a point escape or not (feel free to chose to plot a buddha or an anti-buddha after that), which is the easy part.
Now you have to eventually plot millions of point on the whole memory space in a pure chaotic order.
It's a 100% guaranteed cpu cache miss : ssssssssssloooooooooow.
And in theory you have to use an annoyingly global lock that kill the multi-thread performance.
In buddha++ we choosed to removed this mutex because it made no visible difference.

We used the intel profiler (free for opensource project on linux (not for windows).

Then you have to do the rendering, which require to know the max value of a pixel, and reprocess every pixel for a nice rendering.
(And there is no way to do that without a global lock this time)

And we use the metropolis-hasting algorithms to make everything so much faster when you start to zoom.

That's another problem when you're zooming on a buddhabrot compared to a mandelbrot :
- On a mandelbrot, if you zoomed on [0,0.1] and your resolution is 1000x1000 you're going to compute 1 million time in the [0,0.1] space and your job is done.
- In a buddhabrot you have no way to predict where your orbit will go. So even if you zoomed on [0,0.1] you still have to do the computation in the [-2,0.5 ; -1.3,1.3] space billions and billions and billions of time, twice. The more you zoom the less chance you have for an orbit to be visible in your screen. And you can't know it until you did the whole cpu intensive computation. The metropolis-hastings algorithm is helping and get good result even if it's less than perfect (there is a statistical chance that the neighbor of a point visible on your screen will be visible too).

And contrary to the classic mandelbrot, it can use an insane amount of ram.
A classic mandelbrot don't need much ram and adding more ram isn't going to help you in any way, using more cpu is easy and 100% efficient (you can use 1 thread per pixel and each pixel doesn't interact with other pixels).
In buddhabrot, the more ram the better and multithreading is much more difficult because it require some global lock here and there.

That's why we're focusing on z^2+c, it's fast, efficient, well known, and give good result. And there is still discovery to be done on this one before switching to something much more complex and even more everything-intensive. 

[kram1032]

In my experiments trying higher order polynomials, a couple of things stood out. Instead of spirals and closing patterns, if you go off-center (i.e. if your polynomial has a root not on (0,0), you'd get patterns that look like multiple sheets ending in straight lines. A lot of the patterns do seem like actual sheets being slightly twisted in various ways. I'm sure you can find that if you look at various of my pictures.

I did never attempt to study this in detail though. The above is just roughly my intuition. It basically looks like you are folding the 2D plane onto itself and you get things like mild to strong wrinkles and slightly shifted layering and such.

[claude]

I did some other experiments around that time (late 2013) using something very similar to billtavis' technique, no pics online at the moment though (and will take me some time to trawl my hard drive to find them to upload, might instead take a photo on Sunday of the print hanging on my parents' wall...).

attached, note that I didn't give it a nice name like "Buddha's Jewel" at the time, I used something like "pre-periodic buddhabrot variation"

[Chris Thomasson]

Buddhabrot are very everything-intensive.
In most "classic rendering" (non-buddha) fractal you can have 1 thread per pixel, which is very GPU-friendly and also memory friendly (and that's why it's gpu friendly, the memory is a massive bottleneck on gpu).

In a buddhabrot you have to do the usual stuff, to test if a point escape or not (feel free to chose to plot a buddha or an anti-buddha after that), which is the easy part.
Now you have to eventually plot millions of point on the whole memory space in a pure chaotic order.
It's a 100% guaranteed cpu cache miss : ssssssssssloooooooooow.
And in theory you have to use an annoyingly global lock that kill the multi-thread performance.
In buddha++ we choosed to removed this mutex because it made no visible difference.

We used the intel profiler (free for opensource project on linux (not for windows).

Then you have to do the rendering, which require to know the max value of a pixel, and reprocess every pixel for a nice rendering.
(And there is no way to do that without a global lock this time)

And we use the metropolis-hasting algorithms to make everything so much faster when you start to zoom.

That's another problem when you're zooming on a buddhabrot compared to a mandelbrot :
- On a mandelbrot, if you zoomed on [0,0.1] and your resolution is 1000x1000 you're going to compute 1 million time in the [0,0.1] space and your job is done.
- In a buddhabrot you have no way to predict where your orbit will go. So even if you zoomed on [0,0.1] you still have to do the computation in the [-2,0.5 ; -1.3,1.3] space billions and billions and billions of time, twice. The more you zoom the less chance you have for an orbit to be visible in your screen. And you can't know it until you did the whole cpu intensive computation. The metropolis-hastings algorithm is helping and get good result even if it's less than perfect (there is a statistical chance that the neighbor of a point visible on your screen will be visible too).

And contrary to the classic mandelbrot, it can use an insane amount of ram.
A classic mandelbrot don't need much ram and adding more ram isn't going to help you in any way, using more cpu is easy and 100% efficient (you can use 1 thread per pixel and each pixel doesn't interact with other pixels).
In buddhabrot, the more ram the better and multithreading is much more difficult because it require some global lock here and there.

That's why we're focusing on z^2+c, it's fast, efficient, well known, and give good result. And there is still discovery to be done on this one before switching to something much more complex and even more everything-intensive.  

IMVHO, a Buddhabrot wrt multi-threading, can benefit from fine-grain locking techniques. Also, if a pixel is a word, why not use atomic fetch-and-add on the pixel value and add some cache padding in the pixel layout to prevent false-sharing?

I just happen to know a thing or two about designing multi-threading synchronization.

State-of-The art:

http://www.1024cores.net/

Link is here:

http://www.1024cores.net/home/lock-free-algorithms/links

(he has a link to one of my older sites near the bottom of the page "AppCore")


A nice multi-producer/consumer queue I helped develop:

https://groups.google.com/d/topic/lock-free/acjQ3-89abE/discussion


And a proxy garbage collector:

https://groups.google.com/d/topic/lock-free/X3fuuXknQF0/discussion

http://pastebin.com/f71480694


Not sure if this is relevant at all, but I felt a reason why this just might be of interest to you.

;^)

[billtavis]

Thanks everyone!

attached, note that I didn't give it a nice name like "Buddha's Jewel" at the time, I used something like "pre-periodic buddhabrot variation"

There it is again! Awesome coloring too! It sounds like you were also plotting the orbits of points just outside the "tips", although you had a more orderly manner of choosing them... and maybe you plotted other points too, like near the centers of spirals and nets?

[ker2x]

Not sure if this is relevant at all, but I felt a reason why this just might be of interest to you.

Yes, it is

I hadn't time/energy to code since a long time but i'm switching job from sysadmin/dba/architect/bigdata/coder to just dba, i'll have some time to do weird stuff again 

[Chris Thomasson]

IMVHO, a Buddhabrot wrt multi-threading, can benefit from fine-grain locking techniques. Also, if a pixel is a word, why not use atomic fetch-and-add on the pixel value and add some cache padding in the pixel layout to prevent false-sharing?
...
(he has a link to one of my older sites near the bottom of the page "AppCore")

The link to my old crappy site, can be found here:

http://www.1024cores.net/home/lock-free-algorithms/links

(near the bottom of the page "AppCore", under the "source code to study" section)

[ker2x]

I subscribed to the lockfree list a few years ago but i'm not reading it
But it's all archived so i will, someday

[Chris Thomasson]

dude, the last pic is marvellous!

this looks so 3d ish

FWIW, I whipped up a multi-Julia iterated function system and got a rendering that, IMVHO, has a 3d feel about it.

BTW, when I say multi-Julia, I mean using multiple Julia seed points and dynamically switching between during iteration. The switching is based on a probability factor...

[Chris Thomasson]

I subscribed to the lockfree list a few years ago but i'm not reading it
But it's all archived so i will, someday

Great!  BTW, thank you for taking an interest in to more "exotic" synchronization algorithms out there...

;^D

[kram1032]

Fractal-splosion O:

[Chris Thomasson]

FWIW, here is a result I got from feeding my Buddhabrot implementation with points generated by my hybrid multi-Julia iterated function system. It seems to have a Mandelbrot'ish outline in white, bright pinks and some purples. Humm...

[Chris Thomasson]

FWIW, here is another Buddhabrot fed with points generated by my multi-Julia iterated function system:



I have to admit that I am proud of this one!

:^D