2

I am trying to calculate with higher precision numbers in JavaScript to be able to zoom in more on the Mandlebrot set. (after a certain amount of zooming the results get "pixelated", because of the low precision)

I have looked at this question, so I tried using a library such as BigNumber but it was unusably slow. I have been trying to figure this out for a while and I think the only way is to use a slow library.

Is there a faster library?

Is there any other way to calculate with higher precision numbers?

Is there any other way to be able to zoom in more on the Mandlebrot set?

Probably unneceseary to add this code, but this is the function I use to check if a point is in the Mandlebrot set.

function mandelbrot(x, y, it) {
    var z = [0, 0]
    var c1 = [x, y]
    
    for (var i = 0; i < it; i++) {
        z = [z[0]*z[0] - z[1]*z[1] + c1[0], 2*z[0]*z[1] + c1[1]]
        if (Math.abs(z[0]) > 2, Math.abs(z[1]) > 2) {
            break
        }
    }
    return i
}
  • You can try other libraries, but in the browser you're limited to browser implementations, e.g., no FFI to something *actually* fast. – Dave Newton Aug 04 '20 at 17:03
  • You have to increase the iteration limit as you "zoom in" on smaller and smaller regions of the complex plane. http://gutfullofbeer.net/mandelbrot/ click and drag to zoom – Pointy Aug 04 '20 at 17:04
  • @Pointy I know that I have to increase the itterations, but what I am having problems with is the fact that it gets pixelated after a bit of zooming, exactly the same as it does here: http://gutfullofbeer.net/mandelbrot/ – Simon Lovec Aug 04 '20 at 17:08
  • @DaveNewton Do you have any recomendations? – Simon Lovec Aug 04 '20 at 17:10
  • @SimonLovec well on my implementation you can zoom in pretty far before you run out of precision with native 64-bit floating point. Increasing iteration count by a lot gives you more accurate set details in tiny rectangles of the plane. There's nothing you can do to get more floating-point precision at anything close to native number performance. – Pointy Aug 04 '20 at 17:10
  • 1
    At the full size of the set, around 2 units around the origin, 500 iterations is plenty. At smaller and smaller areas, you need to be up in the thousands for the max iterations. – Pointy Aug 04 '20 at 17:12
  • @SimonLovec Nope; I'd just explore the options and maybe do some benchmarking. Ultimately, though, giant, precise numbers will be slow in the browser. – Dave Newton Aug 04 '20 at 17:15
  • My code's formula (not based on any sort of science) is `400 * Math.log(1/dz0)`, where `dz0` is the real-axis width of the section of the plane. Thus if the width is 0.001, the max iterations is over 2700. – Pointy Aug 04 '20 at 17:17
  • @Pointy Oh, is that your impl? I blame you for the last 10 minutes of my life. Anecdote: I once wrote Mandelbrot visualizers on three different highly-parallel computers at Argonne Nat'l Labs at a workshop. This was a long time ago but brings back fond memories. – Dave Newton Aug 04 '20 at 17:19
  • @Pointy You are right that it is pretty far, but it kinda cancels the idea of "infinite" zooming. But that's what I basically wanted to hear, the fact there is nothing I can do about that. – Simon Lovec Aug 04 '20 at 17:19
  • @DaveNewton yea me too! I worked at DEC in the early 90s and I wrote one that used a bunch of MIPS-based workstations. Now I just need my laptop :) – Pointy Aug 04 '20 at 17:19
  • @Pointy DECstation/systems? I remember those; MIPS was my favorite CPU for a long time. Because having favorite CPUs IS OKAY AND I'M FINE WITH IT – Dave Newton Aug 04 '20 at 17:20
  • btw my favorite part of the set is down towards the bottom of the top and bottom "notches" just a little ways to the left of the origin. – Pointy Aug 04 '20 at 17:21
  • @Pointy Because having favorite Mandelbrot coordinates is also ok ;) – Dave Newton Aug 04 '20 at 17:21
  • 1
    @DaveNewton we're totally abusing the comment section but if the DEC Alpha had not been the property of a messed-up company like DEC it could have been really successful. – Pointy Aug 04 '20 at 17:21
  • @Pointy Thanks for the formula! I had manual control of the itterations with the + and - keys but doing it automaticly will be much better. – Simon Lovec Aug 04 '20 at 17:22
  • @Pointy Yes; DEC screwed the pooch. It was painful to watch. – Dave Newton Aug 04 '20 at 17:24
  • @SimonLovec I'm going to provide an answer just for fun, it's not every day I get a question about something I've been doing for fun since about 1982 – Pointy Aug 04 '20 at 17:38

1 Answers1

2

The key is not so much the raw numeric precision of JavaScript numbers (though that of course has its effects), but the way the basic Mandelbrot "escape" test works, specifically the threshold iteration counts. To compute whether a point in the complex plane is in or out of the set, you iterate on the formula (which I don't exactly remember and don't feel like looking up) for the point over and over again until the point obviously diverges (the formula "escapes" from the origin of the complex plane by a lot) or doesn't before the iteration threshold is reached.

The iteration threshold when rendering a view of the set that covers most of it around the origin of the complex plane (about 2 units in all directions from the origin) can be as low as 500 to get a pretty good rendering of the whole set at a reasonable magnification on a modern computer. As you zoom in, however, the iteration threshold needs to increase in inverse proportion to the size of the "window" onto the complex plane. If it doesn't, then the "escape" test doesn't work with sufficient accuracy to delineate fine details at higher magnifications.

The formula I used in my JavaScript implementation is

maxIterations = 400 * Math.log(1/dz0)

where dz0 is (arbitrarily) the width of the window onto the plane. As one zooms into a view of the set (well, the "edge" of the set, where things are interesting), dz0 gets pretty small so the iteration threshold gets up into the thousands.

The iteration count, of course, for points that do "escape" (that is, points that are not part of the Mandelbrot set) can be used as a sort of "distance" measurement. A point that escapes within a few iterations is clearly not "close to" the set, while a point that escapes only after 2000 iterations is much closer. That distance quality can be used in various ways in visualizations, either to provide a color value (common) or possibly a z-axis value if the set is being rendered as a 3D view (with the set as a sort of "mesa" in three dimensions and the borders being a vertical "cliff" off the sides).

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • Sorry, but I don't think this actually adresses the asked question at all - OP specifically asked about his image getting pixelated, not about a lack of detail that could be caused by a low iteration limit. Besides that, the formula you mentioned is at best a rough approximation; the required iteration count varies a lot depending on where you zoom in, so this heavily underestimes it in some places and overestimates it in others. – peabrainiac Sep 06 '20 at 18:06
  • @PeaBrain yes that's true; clearly any formula for picking an iteration count could be substituted. In practical terms (I mean, the whole thing is about making pretty images) I've found that works well enough. And yes, when you run out of "room" in the floating point range things look bad, but there's nothing to be done about that. – Pointy Sep 07 '20 at 12:56