Title: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on April 07, 2013, 05:02:21 PM I've converted my arbitrary precision Mandelbrot set hobby project to Java:
http://www.superfractalthing.co.nf/ (http://www.superfractalthing.co.nf/) It uses perturbation theory to dramatically reduce the calculation times. Here is a mathematical description of how it works: http://www.superfractalthing.co.nf/sft_maths.pdf (http://www.superfractalthing.co.nf/sft_maths.pdf) I recommend the 9x super sampling. It takes a bit longer, but it makes complicated images look a lot better. Unfortunately the Java JNLP UI seems a bit buggy on Apple OS X, as you can't edit text in dialog boxes, or enter a save file name. Hopefully Oracle will fix this sometime. It should work fine on PC though. Edit: Latest version of Java seems to have fixed the Apple OS X problems :) Edit2: SuperFractalThing is now open source. The source, and a runnable jar, can be obtained from here: http://sourceforge.net/projects/suprfractalthng/ Edit3: For an explanation of why this thread is so long, try reading reply 12. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Tabasco Raremaster on April 13, 2013, 06:19:03 AM only gives an error using a 32-bit windows 7 laptop.
Java Plug-in 10.17.2.02 Using JRE version 1.7.0_17-b02 Java HotSpot(TM) Client VM User home directory = C:\Users\Basje ---------------------------------------------------- c: clear console window f: finalize objects on finalization queue g: garbage collect h: display this help message l: dump classloader list m: print memory usage o: trigger logging q: hide console r: reload policy configuration s: dump system and deployment properties t: dump thread list v: dump thread stack x: clear classloader cache 0-5: set trace level to <n> ---------------------------------------------------- Match: beginTraversal Match: digest selected JREDesc: JREDesc[version 1.6+, heap=268435456-4294967296, args=null, href=http://java.sun.com/products/autodl/j2se, sel=false, null, null], JREInfo: JREInfo for index 0: platform is: 1.7 product is: 1.7.0_17 location is: http://java.sun.com/products/autodl/j2se path is: C:\Program Files\Java\jre7\bin\javaw.exe args is: native platform is: Windows, x86 [ x86, 32bit ] JavaFX runtime is: JavaFX 2.2.7 found at C:\Program Files\Java\jre7\ enabled is: true registered is: false system is: true Match: selecting maxHeap: 4294967296 Match: selecting InitHeap: 268435456 Match: digesting vmargs: null Match: digested vmargs: [JVMParameters: isSecure: true, args: ] Match: JVM args after accumulation: [JVMParameters: isSecure: true, args: ] Match: digest LaunchDesc: null Match: digest properties: [] Match: JVM args: [JVMParameters: isSecure: true, args: ] Match: endTraversal .. Match: JVM args final: -Xmx4g Match: Running JREInfo Version match: 1.7.0.17 == 1.7.0.17 Match: Running JVM args mismatch: have:<> !satisfy want:<-Xmx4g> Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on April 15, 2013, 11:35:16 PM Sorry about that, I haven't got a 32bit OS to test it on. I've added a link to a low memory version on the launch page, which I think should help. The low memory version is the same except it can't export poster size images.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Tabasco Raremaster on April 20, 2013, 01:32:05 AM Sorry about that, I haven't got a 32bit OS to test it on. I've added a link to a low memory version on the launch page, which I think should help. The low memory version is the same except it can't export poster size images. The system has 3 gig but I guess it's the on-board graph card that ruins the party. Just pasted the info to inform you. Checking on 64bit machine in a few. :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 06, 2013, 11:27:12 PM I don't think I fully understand what you're doing but if this "means that the time taken rendering Mandelbrot images is largely independent of depth and iteration count, and mainly depends on the complexity of the image being created", this could be something big.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Syntopia on May 08, 2013, 09:47:30 PM I'm not sure I get this? As I understand it, you calculate a series, Xn, using the standard approach with arbitrary precision floating points. Then you use an approximation with lower precision floats in a neighborhood around Xn.
First, you say that "Equation (1) is important, as all the numbers are 'small', allowing it to be calculated with hardware floating point numbers.". Why does the magnitude of the numbers matter - the series will always stay below 4.0 anyways? I cannot see why the smaller numbers should need less precision. Secondly, you say "Using equations (1) and (2) means that the time taken rendering Mandelbrot images is largely independent of depth and iteration count". But you still need to calculate a number of series Xn using arbitrary resolution to base your interpolations on, right? Doesn't that mean you get exactly the same dependence on depth and iteration count, and only a linear speedup, because you can estimate the neighborhood faster? Btw, I tried running your app, but Firefox crashed, and in Chrome I got an NumberFormatExpection for the number "1.024" (probably a localization issue - dot versus comma). Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: simon.snake on May 08, 2013, 11:17:49 PM I'm on Windows 7 x64 version running Chrome but all I got was a blank page, then after (quite) a while Chrome crashed all my windows and I had to restart it.
Don't think I'll try again as the same thing happened to me last night when I clicked the link. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: elphinstone on May 08, 2013, 11:59:49 PM I cannot see why the smaller numbers should need less precision. I didn't read the whole theory, maybe I'm completely wrong, but in fact floats are really "more precise" near 0. Because of their structure floating points are not distributed uniformly, they are more dense near zero. (32 bit) floats are structured this way:
The fixed size of the mantissa only allows a limited range of digits, but using the exponent we can "move" these digits at a different decimal place (not so easy as moving the point in decimal digits, the point is moved between base-2 digits, but the idea is the same). So with floats we can not represent numbers like Here you can find a good introduction to float representation: http://www.systems.ethz.ch/sites/default/files/file/CASP_Fall2012/chapter3-floatingpoint-1up.pdf (http://www.systems.ethz.ch/sites/default/files/file/CASP_Fall2012/chapter3-floatingpoint-1up.pdf). Have a look expecially to slide 20. (Note: not sure if the numbers can be really represented in base 2... Again I used base 10 because it's easier to understand. It's just an example ;) ) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Syntopia on May 09, 2013, 09:05:18 AM Well, I get that if you have two high precision numbers, close to each other, e.g:
X_n = 0.1230980948029380492 Y_n = 0.1230980948029380493 their difference could be expressed with a lower precision number, such as D_n = Y_n-X_n = 1E-19. Quote Equation (1) is important, as all the numbers are 'small' But in (1)-(5), the X_n that enters the equations are not small (we know they are points on the orbit - their components will be 0<|X_n|<2). Only the delta's are. I would like to see a comparison between a deep zoom image with another fractal program, comparing rendering speed and image quality (and just to check the correct image is produced!), before I'm convinced. Sorry about being sceptical, it just sounds rather wild to me :-) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: elphinstone on May 09, 2013, 09:36:33 AM Finally read the document, sound like an interesting trick, but now I'm confused too.
The multiplication of Are these multiplications performed with arbitrary precision? They could be faster than a full Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 09, 2013, 05:32:40 PM I would like to see a comparison between a deep zoom image with another fractal program, comparing rendering speed and image quality (and just to check the correct image is produced!), before I'm convinced. Sorry about being sceptical, it just sounds rather wild to me :-) I did something like that. Fractal extreme is supposed to be the fastest windows software to render fractals, so I use that as a reference, and then I used SuperFractalThing. Both programs using 32 threads, SuperFractalThing is faster. I can't get SFT to work at the moment so I can't provide any numbers.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 09, 2013, 05:49:55 PM Okay, I got something out of it now. I used the location "deep" in the library in SFT.
Benchmark parameters: Code: Re = -0.8635169079336723787909852673550036317112290092662339023565685902909598581747910666789341701733177524889420466740410475917304931409405515021801432520061688309437600296551693365761424365795272805469550118785509705439232403959541588349498522971590667888487052154368155355344563441 The results:
That is a really significant decrease in render time! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 09, 2013, 06:22:11 PM The program magically works again, so I inserted some parameters of my own.
Coordinates: Code: Re = -1.479,946,223,325,078,880,202,580,653,442,563,833,590,828,874,828,533,272,328,919,467,504,501,428,041,551,458,102,123,157,715,213,651,035,545,943,542,078,167,348,953,885,787,341,902,612,509,986,72 Magnification: 2^471 6.0971651373359223269171820894398 E141 4000×3000 render in SFT took 105 seconds 24000×12000 render in Fractal extreme took 1 day, 6 hours, 0 minutes, 15 seconds Even though my render in Fractal extreme was 24 times larger, SFT rendered 1029 times faster, which is equivalent to 42.86 times faster if the resolutions were the same. The reason I rendered at 4000×3000 in SFT is because it gave me an error that it was out of memory and that I had to use a 64-bit browser. Downsampled images: Fractal extreme: (http://th01.deviantart.net/fs70/PRE/f/2013/129/1/e/tick_tock_by_dinkydauset-d64nkak.png) (http://dinkydauset.deviantart.com/art/Tick-Tock-370614908) SFT with the default gradient: (http://th01.deviantart.net/fs71/PRE/f/2013/129/3/d/test_render_superfractalthing_by_dinkydauset-d64nkfd.png) (http://dinkydauset.deviantart.com/art/Test-render-SuperFractalThing-370615081) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 09, 2013, 06:29:32 PM incredible results, to make the differences more clear, can you exactly render same resolutions, and then using the same colormap, e.g. 256 grayscales that repeat, and then subtract the images from eachother to show the errors ?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 09, 2013, 06:31:14 PM hehe, with this incredible new zoom depths will be possible ;) :D muahahar, expecting new deep zoom records soon!
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 09, 2013, 06:38:00 PM incredible results, to make the differences more clear, can you exactly render same resolutions, and then using the same colormap, e.g. 256 grayscales that repeat, and then subtract the images from eachother to show the errors ? That would be a good idea, but I don't understand the way the gradient works in SFT. Maybe someone else can do this. As far as I can see the results are accurate.hehe, with this incredible new zoom depths will be possible ;) :D muahahar, expecting new deep zoom records soon! Looks like I wasted months of render time on that deep zoom to over 2^3000 which isn't even finished yet. Still it's a positive thing.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 09, 2013, 08:30:05 PM I'm on Windows 7 x64 version running Chrome but all I got was a blank page, then after (quite) a while Chrome crashed all my windows and I had to restart it. Don't think I'll try again as the same thing happened to me last night when I clicked the link. I think the high memory version seems to be causing some stability problems. I tried Chrome, and it crashed like it did for you. However the low memory version seemed to work fine on chrome in my brief test. I might change my web page to make the low memory version the default one. The extra memory is only needed for exporting very large images. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 09, 2013, 08:43:48 PM The multiplication of <Quoted Image Removed> and <Quoted Image Removed> (or in general of a small number with a number of order 1) still gives a result with the same precision of <Quoted Image Removed> (mantissas are multiplicated first with full precision, then it's rounded to float precision and the exponents are added). But even if we can say that we have a high precision on the result we still cut away details from <Quoted Image Removed>, so we can only work on points that can be represented with floats. In equation (1) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 09, 2013, 10:13:35 PM i am going to mention this method in the upcoming news issue, it would be great if you could provide the essential algorithm, as far as i understand this can even lead to deeper zooms on a gpu with just floating points ? if for an image just one exact location would be needed this could be done on the cpu, and the rest on the gpu ?!
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 09, 2013, 11:49:05 PM i am going to mention this method in the upcoming news issue, it would be great if you could provide the essential algorithm, as far as i understand this can even lead to deeper zooms on a gpu with just floating points ? if for an image just one exact location would be needed this could be done on the cpu, and the rest on the gpu ?! That should work. The gpu code would need to access the values of Xn, so they would have to be stored in a texture or something similar. Also it should be possible to get past the 1e-38 limit by scaling the A, B and C coefficients. SuperFractalThing does this to enable it to render images that have a size too small to store in a double precision number.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: brucedawson on May 10, 2013, 03:04:29 AM Code: [quote author=Dinkydau link=topic=15559.msg61119#msg61119 date=1368114595] The results:
That is a really significant decrease in render time! [/quote] That's fascinating. I don't understand why chaos theory doesn't make this fail, but I guess I'll have to give it a try. One thing to watch out for. If Java is using double precision floating point numbers then I suspect this will fail at around a magnification of 10^308 (about a thousand zooms). At around that point a double does not have the range to represent the difference between the left and right edge of the image, and some time before that a double does not have the range to represent the difference between two pixels. I hit variations on this problem a few times while working on Fractal eXtreme. This isn't an insurmountable problem -- it just means that something more complex than double will be needed. That also means that getting it working on GPUs will be trickier beyond that level. Good algorithms beat optimized code. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 10, 2013, 03:55:58 AM wow, surely worth a mention ;)
regarding chaos theory ... its "just" deterministic chaos, and it still is hard to predict, but this awesome encounter just moves the border a few hundred defimals farther ;) awesome, fantastic work Mr.Flay ! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 12, 2013, 07:15:10 PM That should work. The gpu code would need to access the values of Xn, so they would have to be stored in a texture or something similar. Also it should be possible to get past the 1e-38 limit by scaling the A, B and C coefficients. SuperFractalThing does this to enable it to render images that have a size too small to store in a double precision number. Also SuperFractalThing stores the numbers 2-Xn to help it accurately calculate the first iteration where |Yn|>2. However I think this is only really needed for points near -2. A dynamic gpu zoomer would be able to use the same reference point data for several frames, so the speed of calculating the Xn values shouldn't be a problem. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 12, 2013, 07:25:23 PM One thing to watch out for. If Java is using double precision floating point numbers then I suspect this will fail at around a magnification of 10^308 (about a thousand zooms). At around that point a double does not have the range to represent the difference between the left and right edge of the image, and some time before that a double does not have the range to represent the difference between two pixels. I hit variations on this problem a few times while working on Fractal eXtreme. SuperFractalThing can go beyond 10^308. It does this by scaling the A, B and C coefficients. I haven't really tested this very much, I have just zoomed in on one point to 10^400. If the result from equation (2) is to small to be stored in double precision floating point then SuperFractalThing will fail, but I think it would need an extremely chaotic image for that to happen.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cbuchner1 on May 13, 2013, 05:17:59 PM Does the perturbation theory maths also apply to 3D rendering of Mandelbulb, Mandelbox and other hybrids? If so, it could greatly speed up the non-DE based raytracing methods. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 13, 2013, 05:29:05 PM i think it would work ... but it has to be carefully developped, mrflay has done the work for the mandelbrot equation, other formulas need careful development of such ... but in general what the paper states is that pertubation theory can provide faster solutions for harder problems ... but this would not be easy to achieve ....
you can *try* to rego the steps with the 3d version and triplex mathes, but as long as i do not have implemented the method by myself, and fully understand how he developed the formulas i wont touch any higher dimension or other formulas with such :( @mrflay is the sourcecode available for this program? i am really interested in a very deep zoom mandelbrot explorer using the gpu, this would be reeeeeeeeeeeeeeaally awesome for now ;) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 14, 2013, 08:29:27 AM This sound really amazing, as soon as I get a little time I can't wait to lay my hands on this.
I searched a little on google for "pertubation superfractalthing" and found that there is what it seems a desktop application however only available on Mac. Have any mac users tested it? If it is possible to render Mandelbrot fractals in Java so many times faster than Fractal extreme, one can only guess the possibilities with a program written in optimized C++ and assembler... :o This MAC application seems to be a couple of years old, so this does not seem to be any news at all. How did we enthusiasts missed it for so long...? :o Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 14, 2013, 01:18:38 PM Yes, I have been thinking of installing mac OS on my computer just for this application. I don't think it would change my everday life actually; photoshop and after effects are available for mac, browsers are available for mac, and I assume there must be some MSN application for mac as well.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 15, 2013, 12:09:19 AM @mrflay is the sourcecode available for this program? i am really interested in a very deep zoom mandelbrot explorer using the gpu, this would be reeeeeeeeeeeeeeaally awesome for now ;) I'm planning on having a look at releasing the java app source as open source at the weekend. However I might get distracted by making a single precision version of SFT to test the feasibility of the gpu idea.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cbuchner1 on May 15, 2013, 01:50:30 AM I'm planning on having a look at releasing the java app source as open source at the weekend. However I might get distracted by making a single precision version of SFT to test the feasibility of the gpu idea. even with single precision not fully working, there is the option to use the DSMATH library to combine two single precision floats into something that is more precise than a float, but somewhat less precise than a double. for a CUDA implementation https://devtalk.nvidia.com/default/topic/394729/emulated-double-precision-double-single-routine-header/ I am certain an OpenGL (GLSL) and OpenCL variant will be possible as well. The speed would be about 4 times slower than using float (yet still much faster than one's CPU could do double precision maths using SSE2 or AVX), and will run on older GPU hardware that doesn't have native double precision support. Christian Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 19, 2013, 05:13:08 PM mrflay, even if you did not have the time to make your code open-source, can you give us any pseudo-code or something please?
I am trying to investigate this, however it seems that I didn't get it quite right. I am still only using the arbitrary precision library. The function is Dn= 2*X*D + D*D + CD, where CD is the offset from the pixel I am calculating using the ordinary Mandelbrot calculation (D0), X is the Mandelbrot variable, D is the delta and Dn is the next delta. The ordinary Mandelbrot calculation, where C is the location: xin = 2*(xr*xi) + ci; xrn = xr*xr - xi*xi + cr; Before this, the new Delta-values are calculated, and cd is the difference between the X and the Y values: dnr+dni = 2*(xr+xi)*(dr+di) + (dr+Di)*(dr+di) + cdr + cdi => dnr+dni = 2*xr*dr + 2*xr*di + 2*xi*dr + 2*xi*di + dr*dr + 2*dr*di + di*di + cdr + cdi => This is the resulting code: dnr = 2*xr*dr + 2*xi*di + dr*dr + di*di + cdr; dni = 2*xr*di + 2*xi*dr + 2*dr*di + cdi; So in each iteration, the above is calculated and added to the Y value, and then checked for the absolute value not exceeding 2: yr=xr+dnr; yi=xi+dni; if(yr*yr+yi*yi > 4) break; However I only get the same value on Y as on X. The terms dr*dr and di*di get very small compared to 2*xr*dr and 2*xi*di Can you or anybody please help? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 19, 2013, 06:14:15 PM This is the resulting code: dnr = 2*xr*dr + 2*xi*di + dr*dr + di*di + cdr; dni = 2*xr*di + 2*xi*dr + 2*dr*di + cdi; Here's my code: Code: // update dx Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 19, 2013, 06:32:52 PM Thanks a lot!!! :),
yes I forgot the minus sign :snore: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 19, 2013, 07:01:49 PM My first open source project:
http://sourceforge.net/projects/suprfractalthng/ Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: blob on May 19, 2013, 08:11:01 PM Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application.
Thanks. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 21, 2013, 12:06:35 AM Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application. I might make that a project for this weekend - I think it needs some GPL information put in the about box. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 23, 2013, 10:45:20 PM I have now had some time to investigated this a little.
The following two fractals are zoomed to just a little more than e100. Only the top left pixel is calculated with the standard Mandelbrot function with a arbitrary precision library. The rest of the pixels (of the 100x100 images, which are here magnified 4 times) are calculated with the SFT method with the standard double variables (the result is almost identical if I use the arbitrary precision library with the SFT method). The first fractal (random colors different for each iteration) is near the edge rel:-1 img:0 and give a really promising result, there is only a little glitch in the middle of the spines, where the iterations are vary the most: (http://biphome.spray.se/karl.runmo/sft_s.jpg) The second fractal (gradient colors) is in the "sea horse valley" (or actually on the opposite side, which I don't know the name for) and don't give any good result at all. (http://biphome.spray.se/karl.runmo/sft_c.jpg) Is SFT accurate only near rel:-1 img:0 or does your program give better results? The glitches are clearly visible even if I calculate every 3rd pixel with the Mandelbrot function. If you are able to zoom into more complex regions, what ratio of Mandelbrot and SFT pixels do you use in your program? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 24, 2013, 12:55:39 AM regarding that your name sound like hitting head on the keyboard, thank you for those tryouts, why not choose a pixel in the middle ?
and to be true, this method can not guess points deeper iterated than the original point i guess ;) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on May 24, 2013, 01:01:27 AM Wow, nice technique! I reimplemented the maths in OpenCL to run it on GPU (or CPU if you have no GPU that supports double precision):
http://code.mathr.co.uk/fractal-bits/tree/HEAD:/mandelbrot-delta-cl Example output (25mins render time at 8192x8192 then downscaled): http://mathr.co.uk/misc/2013-05-23_opencl_mandelbrot_perturbation_de.png Coordinates -1.744462934349396211092633065532440162654657162058301205300011967233679112768696718643911450570050500237635116030934362e+00 + -2.204215166614661298784067716126285236126642700430015281578297171107705673910697920586811821018057499939594440402773182e-02 i @ 4e-99 period 5308 There are some white blobs that shouldn't be there - it's not maximum iteration count being reached, but something else (inappropriate reference point for those pixels? over/underflow somewhere? mystery...) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 24, 2013, 09:19:05 AM regarding that your name sound like hitting head on the keyboard, All the names I wanted on youtube was already used so eventually I just hitted the keyboard, I am using the same name here since most of my youtube movies are fractal zooms :) thank you for those tryouts, why not choose a pixel in the middle ? You may regard the images as 200x200 pixels with the Mandelbrot pixel in the middle ;)and to be true, this method can not guess points deeped iterated than the original point i guess ;) And yes, the reference Mandelbrot pixel continues to be calculated in my test until all the SFT pixels are set, so in my opinion it should not matter if the SFT pixels are much deeper. However, you have a good point here and my opinion is wrong - if I use the deepest pixel as reference the fractal gets really good even in complex regions: (http://biphome.spray.se/karl.runmo/sft_c2.jpg) So, in order to make a general Mandelbrot explorer - how can the deepest pixel in an image be chosen prior calculation? Or maybe we can just live with the errors it gets when just choose the pixel in the middle? Edit: The fractal above is zoomed to e103. Time to render the left image with the Mandelbrot function (in one thread) is 9.6s. Time to render the right image is amazingly 0.072 seconds!!! There is an improvement of 133 times!!! A e103 image rendered almost instantly!!! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 24, 2013, 10:09:17 AM awesome results!!! mr flay has earned our non existant fractal nobel prize i believe!
to the choosen point, i think you are going to render animations, one thing is that the actual reference point does not need to be recalculated for every frame, it just needs to be recalculated when quality gets too low ... so, this is one, second is that the reference point should be user adjustable, especially for rendering animations from time to time the reference points should require a re adjustment woot woot, e100000000000 animations are visible soon :D :D :D :D :D :D :D :D :D :D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 24, 2013, 10:12:23 AM Wow, nice technique! I reimplemented the maths in OpenCL to run it on GPU (or CPU if you have no GPU that supports double precision): https://gitorious.org/maximus/fractal-bits/trees/master/mandelbrot-delta-cl Example output (25mins render time at 8192x8192 then downscaled): http://mathr.co.uk/misc/2013-05-23_opencl_mandelbrot_perturbation_de.png Coordinates -1.744462934349396211092633065532440162654657162058301205300011967233679112768696718643911450570050500237635116030934362e+00 + -2.204215166614661298784067716126285236126642700430015281578297171107705673910697920586811821018057499939594440402773182e-02 i @ 4e-99 period 5308 There are some white blobs that shouldn't be there - it's not maximum iteration count being reached, but something else (inappropriate reference point for those pixels? over/underflow somewhere? mystery...) statistics about calculation time ? so, this method works well with gpu ? :D who is in for implementing a ultra deep mandelbrot realtime zoomer on gpu, this would be just awesome, this task is open for anyone right now and it would have massively deep and huge impact, it might become a reference example for nowadays graphics cards :D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 24, 2013, 12:05:00 PM the actual reference point does not need to be recalculated for every frame Yes, I agree, an animation should only needed the center point to be calculated once! Amazing possibilities opens, not only very deep zooms but also very zooms with very high iterations will be possible! woot woot, e100000000000 animations are visible soon :D :D :D :D :D :D :D :D :D :D However, in order to exceed e308, which is the limit of a double, it is necessary to scale the values from the arbitrary library to double and then back again... Any suggestions anyone? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cbuchner1 on May 24, 2013, 01:09:55 PM So screensavers performing a GPU based HD realtime deep zoom into a set of previously chosen deep locations should be easy to implement. ;)
Has anyone checked yet if float vs double precision makes a difference? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 24, 2013, 03:15:37 PM Has anyone checked yet if float vs double precision makes a difference? I did not work for me with float, seems the precision is too low.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 24, 2013, 03:42:46 PM the irony is that floating points can be used when the absolute zoom level is very deep, resulting in a very small surround area,
as far as i understand it, the floats can be enough when the distance to the known point is small enough ;) but it is just a guess!!! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 25, 2013, 06:30:55 PM I've uploaded a new version to my website (version 0.3).
Changes: Fix hang when trying to recreate claude's image in reply 38 Fix mandelbrot set going white when super sampling is turned off. Out of memory exception checking when creating the png, when exporting an image Show system memory in the export dialog. Update about box Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 25, 2013, 07:02:32 PM Wow, nice technique! I reimplemented the maths in OpenCL to run it on GPU (or CPU if you have no GPU that supports double precision): https://gitorious.org/maximus/fractal-bits/trees/master/mandelbrot-delta-cl Example output (25mins render time at 8192x8192 then downscaled): http://mathr.co.uk/misc/2013-05-23_opencl_mandelbrot_perturbation_de.png Coordinates -1.744462934349396211092633065532440162654657162058301205300011967233679112768696718643911450570050500237635116030934362e+00 + -2.204215166614661298784067716126285236126642700430015281578297171107705673910697920586811821018057499939594440402773182e-02 i @ 4e-99 period 5308 There are some white blobs that shouldn't be there - it's not maximum iteration count being reached, but something else (inappropriate reference point for those pixels? over/underflow somewhere? mystery...) 25 minutes seems a bit slow. My i7 running SFT java can do that in about 7 minutes. Are you using the series approximation technique? Here's a link to the sft image https://www.box.com/s/bbgj5nrey0veauf98vzc Your white blobs occur because the blobby points move too far away from the reference point, causing the calculation to lose precision. The points can't be distinguished from each other, so they come out the same colour. SFT mainly uses one reference point per image. However with this image SFT automatically uses two, which fixes the blobs. I've attached a txt file that can be loaded into SFT. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 26, 2013, 10:42:53 AM Mrflay, thank you for your excellent maths!
Next step, for me atleast, is to use scaling to be able to zoom beyond e308. I am able to multiply the variables with a constant that I later divide away. However that constant is also a double datatype, limited to e308, so I am only pushing the limit to e616 or something (atleast in theory). But I want it to be unlimited! Maybe I have to create a datatype with the same precision as double but with unlimited exponent. However a custom datatype will always get slower. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 26, 2013, 02:12:26 PM All the names I wanted on youtube was already used so eventually I just hitted the keyboard, I am using the same name here since most of my youtube movies are fractal zooms :) From what I understood, it doesn't matter where the reference point is that you're using, It doesn't actually have to be inside the region of the image, right? So could it be possible to make something like a max iterations slider, a slider to determine how many iterations the reference point should have? It may be very difficult to find which pixel in a grid needs the most iterations prior to rendering, but it may be easier to use reference points such as those between the circle and the cardoid of the main mandelbrot set. By approaching the real axis from above there, you could find points with as many iterations as you want.You may regard the images as 200x200 pixels with the Mandelbrot pixel in the middle ;) And yes, the reference Mandelbrot pixel continues to be calculated in my test until all the SFT pixels are set, so in my opinion it should not matter if the SFT pixels are much deeper. However, you have a good point here and my opinion is wrong - if I use the deepest pixel as reference the fractal gets really good even in complex regions: (http://biphome.spray.se/karl.runmo/sft_c2.jpg) So, in order to make a general Mandelbrot explorer - how can the deepest pixel in an image be chosen prior calculation? Or maybe we can just live with the errors it gets when just choose the pixel in the middle? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on May 26, 2013, 03:06:22 PM 25 minutes seems a bit slow. My i7 running SFT java can do that in about 7 minutes. Are you using the series approximation technique? <Quoted Image Removed> No - I was using iteration because I also wanted to compute the derivative for distance estimator colouring (I didn't manage yet to solve the maths to get a similar more-direct approximation): I haven't checked the SFT source code yet - maybe you already do this - but with the series approximation it might work to use binary search for the lowest N that escapes, should be O(log(N)) time! Quote Your white blobs occur because the blobby points move too far away from the reference point, causing the calculation to lose precision. The points can't be distinguished from each other, so they come out the same colour. SFT mainly uses one reference point per image. However with this image SFT automatically uses two, which fixes the blobs. I see - so automatically check when points might become indistinguishable, and retry with additional reference points. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on May 26, 2013, 03:22:58 PM From what I understood, it doesn't matter where the reference point is that you're using, It doesn't actually have to be inside the region of the image, right? X_0 should be "close enough" to your region so that each Y_0 - X_0 are representable to sufficient accuracy in the lower precision type. Otherwise you could just pick X_0 = 0+0i as your reference! Quote It may be very difficult to find which pixel in a grid needs the most iterations prior to rendering My idea would be to find the centre of a hyperbolic component (Jordan curve technique to find detect period, Newton's method to find location). These points don't escape at all.. But would the periodicity mess up the series approximation? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 26, 2013, 04:37:23 PM X_0 should be "close enough" to your region so that each Y_0 - X_0 are representable to sufficient accuracy in the lower precision type. Otherwise you could just pick X_0 = 0+0i as your reference! I was thinking of how it would be to make an extremely high resolution render of the whole mandelbrot set. Then you could use such a reference point as between the circle and cardoid; it's accurate and within the region. Rendering a deep zoomed image would then be similar to rendering just a portion of that extremely high resolution image of the whole set. The math in the document from mr. Flay makes it looks easier than it is, I see.My idea would be to find the centre of a hyperbolic component (Jordan curve technique to find detect period, Newton's method to find location). These points don't escape at all.. But would the periodicity mess up the series approximation? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on May 26, 2013, 04:57:14 PM with the series approximation it might work to use binary search for the lowest N that escapes, should be O(log(N)) time! Just tried this, fails miserably because the series approximation is only valid while C d^3 remains small compared to A d and B d^2 (as mentioned in the SFT maths PDF...). Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 27, 2013, 12:11:40 AM Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application. Thanks. There is now a runnable jar here: https://sourceforge.net/projects/suprfractalthng/ I've also separated out the JNLP source code so it should be easier for people to build it (Just ignore the SuperFractalThingJNLP file) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on May 27, 2013, 12:48:26 AM Awesome! The program works so much better for me now.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: blob on May 27, 2013, 02:40:49 AM Thanks! :beer:
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 27, 2013, 12:43:07 PM There is now a runnable jar here: https://sourceforge.net/projects/suprfractalthng/ I've also separated out the JNLP source code so it should be easier for people to build it (Just ignore the SuperFractalThingJNLP file) I am sorry, I am totally ignorant when it comes to Java, and this is probably not the right forum to ask this stupid question. However, if anyone would be kind to help me, I would much appreciate it. From my command prompt: C:\>java C:\Downloads\superfractalthingrunable.jar Error: Could not find or load main class C:\Downloads\superfractalthingrunable.jar C:\>java -version java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: blob on May 27, 2013, 01:41:05 PM I am sorry, I am totally ignorant when it comes to Java, and this is probably not the right forum to ask this stupid question. If Java is properly installed, all you need to do is double click on the jar file in Windows Explorer.However, if anyone would be kind to help me, I would much appreciate it. From my command prompt: C:\>java C:\Downloads\superfractalthingrunable.jar Error: Could not find or load main class C:\Downloads\superfractalthingrunable.jar C:\>java -version java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on May 27, 2013, 02:21:43 PM Hi,
Interesting thread! All this looks extremely cool but I'm having troubles to run the application. Either the jar and the applet. I'm getting this error: Code: Exception in thread "main" java.lang.NumberFormatException: For input string: "1á024" In the applet it says the exeption occures for the string "1 024" (with a space). I tried with firefox and chrome always with the same error. I've also tried to change the number format in the configuration panel but no success. :-/ BTW, your formula (in the document) looks like a Taylor expansion at zn. fn(z+e) = fn(z) + d/dc fn(z) *e + 1/2 d˛/dc˛ fn(z) *e˛ +... = zn + d/dc zn *e + 1/2 d˛/dc˛ zn *e˛ +... Right? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 27, 2013, 11:42:37 PM In the applet it says the exeption occures for the string "1 024" (with a space). I tried with firefox and chrome always with the same error. I've also tried to change the number format in the configuration panel but no success. :-/ It looks like this might be a localisation issue. The number should be 1,024 but the comma has gone wrong. I think someone else had issues with this. I tried switching my computer to use commas and periods round the other way, but it didn't seem to reproduce the problem. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 28, 2013, 12:28:43 AM Mrflay, can you please tell in which code file, or function or variable name, you are scailing in order be able to zoom beyond e308? You wrote previously that you were able to zoom to e400, but I don't yet understand how...
Edit: I think I solved my problem: my arbitrary precision library is optimized for fractal math and has a limit on big values, so instead of multiplying delta with a big value I have to "remove zeroes". However the e616 limit remains... But I will still be very happy to be able to create a 30 min HD movie to e600 on an interesting spot that requires a high number of iterations within days, instead of within years :) :) :) :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 28, 2013, 10:21:34 PM Mrflay, can you please tell in which code file, or function or variable name, you are scailing in order be able to zoom beyond e308? You wrote previously that you were able to zoom to e400, but I don't yet understand how... The scaling is done in the function FillInCubic. The size is specified by aActual_width*10^aSize_extra_exponent. In the test for "Is the ABC approximation accurate enough", it uses the extra exponent to scale the ABC values. Btw I have found a bug in SFT when saving an image beyond 1e308. The size is saved out as zero. However the coordinates are ok, so the save file can be 'fixed' by editing the text file and setting the size to something sensible. I should have a fix fairly soon. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: blob on May 29, 2013, 12:55:01 AM I have just entered an image I made with it in the competion.
http://www.fractalforums.com/index.php?action=gallery;sa=view;id=14225 :beer: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 29, 2013, 01:07:28 PM My first SFT movie, rendered within one day :o
http://www.youtube.com/watch?v=g3yko0bi9lU I guess this movie would have taken at least a month to render in my old program, or in Fractal extreme.Above 1e4 0,0i is used as reference, with all X(n)=0. Below 1e4 only one reference point is used for all the frames in the whole movie, that's in the point in the middle of the last frame, which is somewhere inside the minibrot at the end. There is a little glitch at e105 where the zoom after a long path of centering turns to the side. I guess that in those frames the deepest point, reachable from a double, is not the end minibrot, at e255. This glitch is repeated at e180, e218 and e237. There is also a few strange "stains" in the large "empty" areas outside the spirals. I don't know where they come from, they are really stains in the middle of nothing and not something miscalculated in the edge of the frames. Anyway, if I hadn't tell you you wouldn't have noticed :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cbuchner1 on May 29, 2013, 02:25:35 PM How many individual frames did you render for this animation? Could this be sped up further by rendering less frames at a somewhat higher resolution (or with predistortion optimized for zooming in), and interpolating any zooming or rotation that occurs inbetween? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 29, 2013, 03:18:10 PM awesome zoom, is that 720p the resolution you rendered it ?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Alef on May 29, 2013, 03:59:35 PM My first SFT movie, rendered within one day :o Could you do 5 minits compo style movie? Colours here are nicer than violet contest zoom. http://www.youtube.com/watch?v=g3yko0bi9lU I guess this movie would have taken at least a month to render in my old program, or in Fractal extreme.Above 1e4 0,0i is used as reference, with all X(n)=0. Below 1e4 only one reference point is used for all the frames in the whole movie, that's in the point in the middle of the last frame, which is somewhere inside the minibrot at the end. There is a little glitch at e105 where the zoom after a long path of centering turns to the side. I guess that in those frames the deepest point, reachable from a double, is not the end minibrot, at e255. This glitch is repeated at e180, e218 and e237. There is also a few strange "stains" in the large "empty" areas outside the spirals. I don't know where they come from, they are really stains in the middle of nothing and not something miscalculated in the edge of the frames. Anyway, if I hadn't tell you you wouldn't have noticed :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 29, 2013, 04:38:53 PM How many individual frames did you render for this animation? I create a zoom-out sequence of images, each frame only render the new revealed pixels (like a frame) and squeezes the previous image, 10000 frame images in total. This also make the center of the movie smooth without using anti-aliasing and such. Then I assemble the images backwards to create a zoom-in movie. By doing so my old program rendered movies in about the same time as FX, although FX is faster than my program.Could this be sped up further by rendering less frames at a somewhat higher resolution (or with predistortion optimized for zooming in), and interpolating any zooming or rotation that occurs inbetween? awesome zoom, is that 720p the resolution you rendered it ? The original frame images are 640x360Could you do 5 minits compo style movie? Colours here are nicer than violet contest zoom. My competition movie has my "metal-style" effect, which I hope is unique? :)Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on May 29, 2013, 05:27:04 PM It looks like this might be a localisation issue. The number should be 1,024 but the comma has gone wrong. I think someone else had issues with this. I tried switching my computer to use commas and periods round the other way, but it didn't seem to reproduce the problem. I also tried that. Is it possible to make it filter for spaces as it does with commas?asdklfjdf: Nice video! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on May 30, 2013, 12:08:16 AM statistics about calculation time ? so, this method works well with gpu ? :D Using a CPU-based OpenCL runtime, my current implementation takes 15mins to render the whole SFT Library at 512x512 with only a few failures: http://mathr.co.uk/mandelbrot/2013-05-29_sft_library/ This is using a plain iteration for each pixel using double precision (no cubic approximation, no recursive subdivision) and a similar one for difference in the derivative (for distance estimate colouring). Unfortunately some changes in the code stop it working on my GPU-based OpenCL runtime (too many kernel arguments), and when it did work it tended to peg Xorg and make interactively using the computer impossible until it finished. I looked briefly at the SFT source code (but not been able to compile it due to missing jnlp.jar or similar) and saw some "parent" fields in some objects. Am I correct in thinking it has a tree of points, with each level being created using a cubic approximation from the parent? That kind of algorithm might be harder to implement efficiently for GPU. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on May 30, 2013, 01:15:41 AM dudes, congratulations all, i award this as nobel prize candidate for 2013!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pharmagician on May 30, 2013, 02:00:50 AM Wow!
:cantor_dance: Wonderful! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hgjf2 on May 30, 2013, 09:37:24 AM Also a JAVA applet with explore MANDELBROT set with high precision with deep zooming it can finding at site http://math.hws.edu/xJava/MB/
The JAVA applet can zoom to over 1E+300, same as in your movie posted, but for explorer deeping in zoom need more time because if you zoom deeper than 1E+15, image render slower, but zooming at 1E+300 image render more slow because calculate with other algorithm what generate all digit for the big numbers value. :peacock: :thumbsup1: JAVA - fractal extreme emulator EH! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on May 30, 2013, 12:39:53 PM Also a JAVA applet with explore MANDELBROT set with high precision with deep zooming it can finding at site http://math.hws.edu/xJava/MB/ If you would include the SFT algorithm in your java app, it would be many times faster than all other Fractal programs to at least e400, perhaps e600!The JAVA applet can zoom to over 1E+300, same as in your movie posted, but for explorer deeping in zoom need more time because if you zoom deeper than 1E+15, image render slower, but zooming at 1E+300 image render more slow because calculate with other algorithm what generate all digit for the big numbers value. :peacock: :thumbsup1: JAVA - fractal extreme emulator EH! The really cool thing with SFT is that it is not so dependent of the speed of the arbitrary precision library, since it is only used for the reference point, and since double is probably as fast in Java as in C/C++/Assembler the programming language is not so important either. One could make a really decent Mandelbrot e400 explorer also in 32-bit Windows, or as a mobile-app, or anything! Oh I wish I knew about SFT 20 years ago, I would have been able to do magic in 16-bit Windows 3.11!!! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Alef on May 30, 2013, 05:14:57 PM Quote My competition movie has my "metal-style" effect, which I hope is unique? Well it was pink. I think colours of this one were better. Exponent smoothing with some metal gradients can generate metal efect alone.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on May 30, 2013, 11:51:11 PM I looked briefly at the SFT source code (but not been able to compile it due to missing jnlp.jar or similar) and saw some "parent" fields in some objects. Am I correct in thinking it has a tree of points, with each level being created using a cubic approximation from the parent? That kind of algorithm might be harder to implement efficiently for GPU. SFT does recursively divide up the screen, allowing extra iterations of the ABC coefficients to be calculated for each region. SFT keeps dividing until the regions are 3x3 pixels, however I don't know how close to optimal this is. I would expect an optimised gpu implementation to use the cpu to recursively divide the screen down to about 20x20 to 50x50 pixels, maybe, whilst using the gpu to calculate the leaves. It should be easier to compile the source now. I've separated the jnlp code to a single file that can be ignored if you are not interested in running it in a browser. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on June 01, 2013, 10:03:57 PM I've built a new version of SuperFractalThing It can be accessed via my web page http://www.superfractalthing.co.nf, or downloaded from SourceForge.
Changes for version 0.4: * Size is saved correctly for zooms past 1e308 * If the user changes the iteration limit and then performs a zoom, the users iteration limit is now used * The automatic iteration limit increase now works with box zooms as well as double click zooms * Issues with commas in the iteration limit might be improved. * Now built with Java SE 7 Edit: There was a problem with the web page version, stopping it from saving and loading. It should be fixed now. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 02, 2013, 03:04:57 PM Mrflay, I am using the name SFT on my creations made by my jet unpublished program based on your pertubation theory. However you may consider SFT being the name of your programs and not the general method?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 02, 2013, 03:58:42 PM Yet another movie based on this pertubation method. This time far beyond e308 :)
http://www.youtube.com/watch?v=-zQFN-X0kbA Rendered in 7 hrs on a 32-bit laptop pc Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on June 02, 2013, 05:28:15 PM I've built a new version of SuperFractalThing ... Changes for version 0.4: ... Great work! I've been hacking a bit on the code, I put my fork online here (the "claude" branch): http://code.mathr.co.uk/sft Significant changes against upstream:
Planned changes:
(0) http://en.wikipedia.org/wiki/Mandelbrot_set#Continuous_.28smooth.29_coloring (1) http://en.wikipedia.org/wiki/Mandelbrot_set#Exterior_distance_estimation Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Tabasco Raremaster on June 02, 2013, 06:41:28 PM Sorry about that, I haven't got a 32bit OS to test it on. I've added a link to a low memory version on the launch page, which I think should help. The low memory version is the same except it can't export poster size images. Thanks but I've got my 64bit machine finally running well now so am going to give it another try :) Can you create such an application to make a deeper than deep zoom into flames ? P-p-p-please :D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on June 22, 2013, 12:00:59 AM Btw I had a go at looking at a deep high iteration spot to see if I could break sft, and I succeeded. Attached is a save file of the point just before it goes wrong. I haven't figured out why it goes wrong, it might be a fundamental issue or just a simple bug. What happens is that when you zoom in, you always seem to get the same image, regardless of the depth and position. The saved point is inside the final image of teamfresh's e228 zoom, with a zoom of 1e412, and a minimum of about 500,000 iterations.
Its not very quick to render, so here's an image from a bit earlier in the zoom: https://www.box.com/s/8u8zi19piactx9wx76yc Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 24, 2013, 12:05:42 PM Its not very quick to render, so here's an image from a bit earlier in the zoom: Can you give the location parameters?https://www.box.com/s/8u8zi19piactx9wx76yc I had a similar problem and that was due to the scaling and the limitation of the double datatype, which should not occur until about e600 if you are scaling the variables. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on June 25, 2013, 03:04:45 AM The pdf you posted includes:
An+1 = 2XnAn + 1 Bn+1 = 2XnBn + An2 Cn+1 = 2XnCn + AnBn and that the series approximation becomes poor once C starts to approach B in magnitude. But this will always happen at C2. Note that A0 = 1 and B0 = C0 = 0. Then: A1 = 2X0A0 + 1 = 2X0 + 1 B1 = 2X0B0 + A02 = A02 = 1 C1 = 2X0C0 + 2A0B0 = 0 and finally: B2 = 2X1B1 + A12 = 2X1 + (2X0 + 1)2 C2 = 2X2C1 + A1B1 = A1B1 = A1 = 2X0 + 1. If X is any trapped or high-iteration point, it's dithering around in a Julia set of diameter approximately 2, so |B2| is generally in the range 0-11 and |C2| is in the range 0-3. I tried calculating the first few terms for the center coordinates of Mandelbrot Safari: 0.275337647746737993588667124824627881566714069895426285916274363067437510130230301309671975356653639860582884204637353 84997362663584446169657773339617717365950286959762265485804783047336923365261060963100721927003791989610861331863571141 0655928412269957977397230123742985898239211816931398241903797459102438729408702005271146241616545 + 0.006759649405327850670181700456194929502189750234614304846357269137106731032582471677573582008294494705826194131450773 10704967071714678595763311924422571027117886784050420240236249129631789483532106497151867377563025274513529470021667381 57907333431349841201085240017993510765776422837516274693151248839624530130938534718983117335557824i I got these results: 1.0, 0.0, 0.0 1.550675295493476 + 0.013519298810655701i, 1.0, 0.0 2.0886093800617935 + 0.04200174973566416i, 3.1066166509201705 + 0.06289212803423438i, 3.101350590986952 + 0.027038597621311403i The magnitudes of B2 and C2 are extremely close in this instance. Is there an error in the math in the PDF, an error in the claim "The approximation should be good as long as the δ3 term has a magnitude signicantly smaller then[sic] the δ2 term", an error in my implementation, or an error in my assumption that this series approximation would ever shave off more than just the first handful of iterations? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on June 25, 2013, 03:14:48 AM Actually, I may have answered my own question. It seems it must be the magnitude not of the coefficient but the whole term that matters -- so, in fact, C should be no bigger than Bx10magnification or so, rather than no bigger than B. I got there from thinking "wait, shouldn't the approximation break down sooner for less magnified images, instead of being fixed for any image using a given reference orbit?" Just comparing B and C corresponds to an image magnification showing a quarter of the Set or so, so it makes sense for it to break down after only a couple of iterations in that case.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 25, 2013, 10:26:12 AM I don't understand why the coefficients A, B and C where invented at all. I am only using function (1) from the sft_maths.pdf document, and I think the other functions adds unnecessary overhead and complicates the scaling.
Or am I missing something important? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on June 25, 2013, 12:32:12 PM A substantial further speedup, given that my current data suggests it should be possible to lop about 50,000 iterations off the start of calculation for every pixel of the final Mandelbrot Safari image in one fell swoop.
On the other hand, data for other magnifications centered on the same point indicate that the savings is as much as 1/3 earlier on, but drops to about 1/10 toward the end. Combined with my minibrot-associated speedup, though, it could prove more substantial, saving 1/3 even for deeper images, on top of (multiplied by) that other speedup's savings -- but I'm not, as yet, completely certain of that. First acid test of my implementation of the perturbative approach (sans other speedups) should likely happen later today. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on June 25, 2013, 06:35:35 PM I've got my own implementation partly working now. There's still some kinks to work out but preliminary tests on isolated points are giving sensible results.
Meanwhile, I managed to break Superfractalthing itself. If you accidentally put, say, 1e10 instead of 1e-10 into "Horizontal size" and "refresh", it hangs with 0% CPU use. The usual case that would trigger this is copying a magnification over from Ultrafractal or other software without flipping the sign. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on June 26, 2013, 10:30:26 PM I have my own implementation generating correct-looking images from just past the limits of double precision. The inner loop seems to be about 2.5 times slower than SuperFractalThing's, but that's within spitting distance. It's also running on a JVM (64-bit server VM to be exact), but it's written in Clojure (a dialect of Lisp for the JVM). No user interface as yet.
So there are now three Mandelbrot renderers using the OP's technology:
of which at least one is publicly available and open-sourced. An open-source Nanoscope with a real UI may exist eventually, but my next priority is going to be adding animation capability to it (designed to be combined with VirtualDub or other external images-to-avi converter), now that I've gotten it working, and working at a non-dismal speed. I will also investigate at least one possibility for moderately upping its speed. Oh: Nanoscope should be able to zoom past e300, with a bit of a slowdown at that point, but I haven't tested that yet. When zoomed deeper than that, it uses a different inner loop that is divided into two parts: an innermost part that works with delta-times-10p for some power p > 300, with the delta-squared term ignored (it's 10300 or more smaller than delta, and delta has 16 bits of precision!) and a copy of delta-nought pre-multiplied by 10p. The innermost part runs for 500 iterations at a time. The outer loop moves some of the growing exponent of delta into p, shrinking delta and growing p (and renormalizing delta-zero), between each run of the inner loop, until the true value of delta is larger than 10-300. At that point, it switches to the other version of the loop, with delta squared term included (as it's now not guaranteed to be negligible) for the rest of the iterations. Only the loop with delta squared checks for bailout, as it can't be anywhere near bailing out yet until delta's way larger than 10-300; I just check delta itself against the bailout, as with any bailout suitable for smoothed iterations (107, say) the difference between delta and the actual orbit point (the reference orbit point!) will be small in comparison (a couple parts per million, if the reference orbit is trapped in a disk of radius 2 centered on the origin). The 500 above is because if the rescaled delta starts at O(1), being multiplied by 2*reference-point each iteration and added to a (swiftly negligibly smaller) delta-nought, then given a trapped reference point it will grow at most 4* bigger each iteration, and 4500 ~ 10301 is still a bit short of the point of double exponent overflow. My above E-300 inner loop has 8 adds and 7 multiplies (I *could* make a third, "was smaller than E-300 originally" version with 5 adds by dropping the delta-zero term which will be negligible in these cases; and 2 multiplies and an add are needed to calculate radius for bailout, or I could drop to 5 multiplies and 7 adds) and my below E-300 inner loop has 4 adds and 4 multiplies. If anyone has optimized this loop to remove more multiplies I'd be curious to know how. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: mrflay on June 26, 2013, 11:40:26 PM Can you give the location parameters? The location was in the text file attached. To this post, I've attached the text file with the coordinates for the image I linked to.I had a similar problem and that was due to the scaling and the limitation of the double datatype, which should not occur until about e600 if you are scaling the variables. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cbuchner1 on June 27, 2013, 10:49:30 AM My above E-300 inner loop has 8 adds and 7 multiplies (I *could* make a third, "was smaller than E-300 originally" version with 5 adds by dropping the delta-zero term which will be negligible in these cases; and 2 multiplies and an add are needed to calculate radius for bailout, or I could drop to 5 multiplies and 7 adds) and my below E-300 inner loop has 4 adds and 4 multiplies. If anyone has optimized this loop to remove more multiplies I'd be curious to know how. I am kind of thinking that you could achieve a speed-up of factor 2 by going to SSE2, and a speed-up of factor 4 by going to Intel AVX. But I don't think software built on top of a Java VM has that kind of low level access. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 27, 2013, 12:16:51 PM The location was in the text file attached. To this post, I've attached the text file with the coordinates for the image I linked to. My program is able to zoom beyond this. And yes, it is very time consuming due to the huge number of iterations.I recall now that the problem I had was that the location just did not get updated, so maybe it is not relevant. I would like to ask you again, why the coefficients, why equation (3), (4) and (5)? I am only using equation (1). I create tables with all the delta-values, and when the zoom-level is above e300 the ap-library has a parameter for stripping zeroes when converting to double. The variable m_nScalingOffset is an integer, and m_nScaling is a double. These variables are actually applied for all zoom levels, however I have not noticed any performance difference. Code: m_nScalingOffset=0; Code: m_db_cdr[x][y]=(cr-rref).ToDouble(m_nScalingOffset); Code: for(i=0;i<nMaxIter;i++){Code: Dnr = (m_db_dxr[antal]*m_dbDr[x][y] - m_db_dxi[antal]*m_dbDi[x][y])*2 + m_dbDr[x][y]*m_dbDr[x][y]/m_nScaling - m_dbDi[x][y]*m_dbDi[x][y]/m_nScaling + m_db_cdr[x][y]; I hope this can also help Pauldelbrot. What is "Series approximation" that my app is lacking? Unfortunately I still haven't got the SFT java app working on my machine, so I have never tested it. It would be nice if someone could do a comparison on the performance. I suspect that there isn't any big difference, since Java, or any language, would not add any overhead on simple arithmetic with hardware datatypes? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on June 28, 2013, 02:48:36 PM I would like to ask you again, why the coefficients, why equation (3), (4) and (5)? I am only using equation (1). I think the formula for delta2 in http://www.superfractalthing.co.nf/sft_maths.pdf (http://www.superfractalthing.co.nf/sft_maths.pdf) is incorrect. With the correctWhat is "Series approximation" that my app is lacking? version you get the formulas 3) TO 5). :surprised: This approach is very interesting indeed. I can't say I understand it well yet but in theory it promises huge speed ups compared to the traditional approach. Coming back to your question. The "series approximation" is (2). Formula (1) for delta(n+1) is exact, but uses delta(n) which makes it recursive and expenisve to compute. Formula (2) for delta(n) is an approximation since it ignores all terms with delta(0)^m, 4 <= m <= 2^n. But it is NOT recursive which makes it far more efficient to compute once all the An, Bn and Cn have been computed and stored. With formula (2) you can do a binary search for the n where delta(n) gets > 2 and regular iterations would be stopped, PROVIDED the approximation is good enough (e.g. the missing terms don't distort delta (n) too much). When it works a pixel is computed not in O(n) time but O(log n) time. A huge speed up for large n. I have some questions as well. - The reference point should be in the Mandelbrot set or at least not go to infinity till the maximal iteration allowed for the image is reached, right? At least for all points using it as reference. How is this point found best so that the distances for all the points/pixels in the image remain small enough? Should it best be in the image itself? If not, how far can it be away till we get precision issues when using doubles only? - What to do when (2) does not converge fast enough with A, B and C alone? Fallback on (1)? Search a new and better reference point? - Does a Cn term << the Bn term guarantee that all the other terms are "irrelevant"? What should the minimal size difference be? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 28, 2013, 03:51:34 PM Thanks a lot, it is so obvious when you point it out to me!
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on June 28, 2013, 04:20:30 PM - The reference point should be in the Mandelbrot set or at least not go to infinity till the maximal iteration allowed for the image is reached, right? At least for all points using it as reference. Yes. If it's a periodic point that's a bonus, because if the period is say P then the coefficents for the approximation (eq. 3-5) are eventually periodic, and I think it works out that the approximation is good until about 2P. Furthermore you only need to compute P X_n at high precision for the later eq1 iterations, because they repeat after that. Quote How is this point found best so that the distances for all the points/pixels in the image remain small enough? Should it best be in the image itself? If not, how far can it be away till we get precision issues when using doubles only? I think the "best period" has to do with "partials": Define the partials as each n such that |X_n| is less than |X_m| for all m < n, starting with n = 1, X_1 = C. Then if P is a partial of a point C, Newton's method can be used to find the centre of period P, which is likely to be a good reference point. The problem is that if you have an image with lots of different C, they might have different partials, and (so far) the only way I found to compute partials accurately is with full precision iteration. (Using eq1 for partials fails at the same places that the reference point isn't good enough, namely deep embedded Julia sets). A reference point outside the image could be a good one, provided you have enough bits of precision to distinguish neighbouring pixels in the delta. A formula "G" involving the distance of a pixel from the reference and the distance between neighbouring pixels could be worked out. Quote - What to do when (2) does not converge fast enough with A, B and C alone? Fallback on (1)? Search a new and better reference point? (2) should be good until about 2P, but only for points that have P as a partial. Embedded Julia sets are hard because there are a lot of diverging partials, see the last image on: http://mrob.com/pub/muency/atomdomain.html http://mrob.com/images/0-muency/ejs2-7e-17-apd.jpg Each coloured region would have a different best reference point - depending on the formula "G" mentioned above the outermost yellow region might be ok for the whole image, but for deep embedded Julia sets it would fail, and the innermost blue region wouldn't be a suitable reference for most of the image. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Ben Weiss on June 29, 2013, 12:23:20 AM Interesting to read this thread.
I discovered and implemented this same perturbation technique in the engine for KPT Fraxplorer in the 1990's, allowing it to do zooms to about 10^300. (You can still find this software sold for PC as part of Corel's KPT Collection.) The trick (as you've discovered) is to try to find the deepest point in the window to use as the high-precision "central orbit" around which the double-precision perturbations are computed. For deep M-set zooms, the central point will ideally be in a mini-Mandel, if there is one. Deep zooms containing multiple significant-sized mini-Mandels are problematic, though the minis tend to get sparser (relative to their sizes) as you zoom deeper. Bignum libraries are helpful here, because multiplications on 1024-bit numbers can be done significantly faster than the naive n^2 schoolbook approach. (See the Karatsuba algorithm, for instance.) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 29, 2013, 11:04:19 AM The location was in the text file attached. To this post, I've attached the text file with the coordinates for the image I linked to. If you blame Windows or the hardware you are usually very wrong, but this time I really think I found a bug, and it's more probably in Intel's CPU than in Windows.Between e300 and e600 I am using scalinig and that works fine when I tested the 32-bit version of my program. But when I tested the 64-bit version, it does not work from e451 (or something). It is the exact same code, just compiled with different options. I need to investigate this further, to be sure that it is not because of me. But it seems that precision is lost when multiplying and dividing with a large value of format 1eP (where 151<=P<=300) - by 64-bit code and not by 32-bit code - in the same machine and processor. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Syntopia on June 29, 2013, 12:00:31 PM If you blame Windows or the hardware you are usually very wrong, but this time I really think I found a bug, and it's more probably in Intel's CPU than in Windows. Between e300 and e600 I am using scalinig and that works fine when I tested the 32-bit version of my program. But when I tested the 64-bit version, it does not work from e451 (or something). It is the exact same code, just compiled with different options. I need to investigate this further, to be sure that it is not because of me. But it seems that precision is lost when multiplying and dividing with a large value of format 1eP (where 151<=P<=300) - by 64-bit code and not by 32-bit code - in the same machine and processor. If your program is a Windows C++ application, I think there is a more likely explanation: 64-bit code use SSE2 per default (which means 64-bit of internal precision for doubles), while 32-bit code use x87 FPU (which had 80-bit of internal precision) per default. Try running with fp:strict (or is precise?) (http://msdn.microsoft.com/en-us/library/e7s85ffb%28v=vs.80%29.aspx) and see if the output matches. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 29, 2013, 03:05:35 PM If your program is a Windows C++ application, I think there is a more likely explanation: Microsoft's C++ compiler does not support 80-bit fp anymore since at least VC5. So no, I don't think this is the case here. 64-bit code use SSE2 per default (which means 64-bit of internal precision for doubles), while 32-bit code use x87 FPU (which had 80-bit of internal precision) per default. Try running with fp:strict (or is precise?) (http://msdn.microsoft.com/en-us/library/e7s85ffb%28v=vs.80%29.aspx) and see if the output matches. I've tried all fp options with the same result, works in 32-bit but not in 64-bit. I suspect this is relevant on mcflays problem too Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Syntopia on June 29, 2013, 06:17:39 PM Microsoft's C++ compiler does not support 80-bit fp anymore since at least VC5. So no, I don't think this is the case here. All versions of VC++ for x86 supports x87 FPU instructions (which means 80-bit registers may be used for intermediates). Even Visual Studio 2012 (where /arch:SSE2 became default), will emit x87 instructions: "...As a result, your code will actually use a mixture of both x87 and SSE/SSE2 for floating-point computations. " http://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.110%29.aspx Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 30, 2013, 01:08:15 AM Syntopia, thanks a lot for this info, I will investigate this further!
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Syntopia on June 30, 2013, 09:40:23 AM Here is an example, which will give different results on 32-bit (if using x87) and 64-bit:
Code: int _tmain(int argc, _TCHAR* argv[]) When running this on VC++ 2008 (x86) with default settings, I get equal results, as expected since x87 registers have 15 bits of exponent. When running this on VC++ 2013 (x64) with default settings, I get a zero for the product. SSE registers only have 11 bits of exponent (standard doubles). The default settings for VC++ 2013 has changed, but when running this on VC++ 2013 (x86) with "/arch:IA32", I get equal results, and with "/arch:SSE2", I get a zero for the product. But, as the docs state, the compile will choose as it seems fit whether to use SSE2 or x87 in this mode. Running with strict fp, does not change this behavior, which is rather interesting. According to the docs, the strictness seems to be only enforced at function calls. Bruce Dawson (Fractal Extreme) has written more about intermediates: http://www.altdevblogaday.com/2012/03/22/intermediate-floating-point-precision/ Now, since you cannot force a 32-bit program to only use SSE registers, and you cannot make a 64-bit program use x87 registers, I guess that means you cannot create programs (in VC++ at least) that will guarantee the same results on both 32-bit and 64-bit? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on June 30, 2013, 10:51:40 PM Now, since you cannot force a 32-bit program to only use SSE registers, and you cannot make a 64-bit program use x87 registers, I guess that means you cannot create programs (in VC++ at least) that will guarantee the same results on both 32-bit and 64-bit? And what about other languages, as Java?Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Syntopia on June 30, 2013, 11:06:38 PM I wondered about that as well, since we use 32-bit and 64-bit Java code at work for scientific calculations.
According to the JLS, if you use the 'strictfp' keyword: "Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. " As I read this, Java calculations (with strictfp) must be exactly equal on all platforms. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on July 01, 2013, 04:02:09 AM FWIW, Nanoscope's post-e308 scaling is working perfectly on 64-bit Windows. Java, no strictfp. I don't think I've implemented it the same as Kalle though. Kalle seems to be using a pair of doubles whose product is the real value of delta. I'm using one double and an exponent, and most iterations don't need to care about the exponent. The innermost post-e308 loop in Nanoscope is just:
delta_scaled_n+1 = delta_scaled_n * reference_orbit_n + delta_scaled_0. No delta-squared, because if delta is O(10-308) or smaller, delta squared is smaller than delta by a similar factor and is lost in the noise. No 2* because the copy of the reference orbit used for this loop is premultiplied by 2. If the reference orbit's not about to escape (and if it does, it takes delta with it as they're sure to diverge past the bailout distance), it's confined in a disk of radius 2, so its doubled version is in a disk of radius 4, and the modulus of the first term in the sum above is at most five times larger than the previous, if delta_scaled_0 is still comparable in magnitude to delta_scaled_n, and more usually delta_scaled_0 is smaller. So, basically delta_scaled's modulus grows by a factor of four or less most iterations, and that means it takes delta_scaled around 500 iterations to go from O(1) to O(10308). Only then is delta_scaled (and delta_scaled_0) rescaled and the stored exponent adjusted. This makes for a very fast inner loop below e308. In principle, this method allows zooming to nearly arbitrary depths; there's no further barrier at e616 or anything like that. I've also greatly streamlined the memory use, without even having to recalculate the high precision orbit every frame or persist it to disk. High precision points are only needed in three places:
So we only need to store:
And to compute:
The high precision R_i are traversed twice, though, first to build the arrays of doubled doubles and again gradually to build up the sequence of ABC_i values. Small price to pay. I've also found the need to identify the highest iteration region in an image pre-calculation and sometimes use a second reference point there. The algorithm I'm currently using for this proceeds in two phases. First, it samples 100 points in the image region using perturbation theory (fast!), sorts them by iterations, discards all but the top ten, and then does some graph theory manipulation to identify a big cluster of close-together points, by looking for the closest pair of samples, and then all samples transitively reachable from those two by sample-to-sample hops no longer than 1.5x their separation. The resulting possibly-reduced set of points tends to be a "blob" of high-iter material which, if off-center (i.e. not containing the primary reference point), may not be rendered correctly. This blob's diameter is measured (longest distance between any two of the samples in it) and its barycenter (average of the member samples' coordinates), and if it's significantly bigger than 1 pixel but significantly smaller than the previous examined region, the process is recursively applied to the smaller region to refine the estimate of the high iter region's core's size and center. When the "blob stops shrinking" or reaches only a few pixels in width, the second phase begins. If the "blob" is now tiny (only a few tens of pixels max), they're all iterated with high precision normal Mandelbrot calculations and the highest iteration point is returned; if the blob's still substantial, high precision calculations take over from low but a recursive refinement algorithm that takes logarithmically many points in the blob's diameter is used instead of brute scanning to try to guess the highest-iter point, gradient-climbing to reach it. Once the high-iter point is identified, its iteration count is checked for being bigger, by more than 10, than the iteration count the PT algorithm assigns. If it is off by ten or more iterations, that means PT is bailing early in that region and we need a second reference point. The highest-iter point is used as that point, which means a second 2*S_i array and D_i, E_i, F_i series coefficients. Also, points in the image are iterated using PT with each set in turn, and the highest iteration wins. This seems to clear up the "blank blobs" in the test images I've thrown it at so far, and even a corrupted minibrot in one test (where the reference point was in an incomparably smaller minibrot some several diameters of the larger minibrot away from it). Sadly, the detection of the need for a second reference point is slowish, taking a minute or so in the e70-e100 few-thousand-iter "shallows" and half an hour at e300+ and 1e5+ iterations (java.math.BigDecimal is slow). I am, of course, working on figuring out ways to squeeze more speed out of the highest-iter-point-finding algorithm. Even as things are, it seems to be as accurate as UF and dozens to hundreds of times faster, depending on the zoom. AIUI, Superfractalthing also has some method for determining when a second reference point is needed; I don't know about Kallesfractaler, though, or the methods either use. I've described mine in the hope that it may be helpful to either of their authors, and in the hope that someone might have a useful suggestion for speeding my own up. Similarly, I hope my explanation of Nanoscope's e308+ loop structure can help Kalle to overcome his(?) difficulties with different behavior on different processor architectures, and to be able to go past e616. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on July 01, 2013, 07:17:03 AM :embarrass: great, do you plan to make nanoscope available for others ?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on July 01, 2013, 08:32:23 AM Similarly, I hope my explanation of Nanoscope's e308+ loop structure can help Kalle to overcome his(?) difficulties with different behavior on different processor architectures, and to be able to go past e616. I also made the same kind of custom datatype with a double as the mantissa and an integer as the exponent, to be able to get past e616.However I did not want to use that until e600 and instead scale ordinary doubles between e300 and e600, which works fine in 32-bit. The solution is to use the custom datatype earlier in 64-bit, at about e450. My first tries on series approximation and binary search shows that I should be able to render "tick-tock" in only 1.5 seconds. But it does not render correct, I probably didn't get the minuses and the pluses correct though... :) Edit: I am beginning to understand that function (2) cannot be used by itself, it can only be used to initiate function (1) so that it does not have to begin from iteration zero. A fractal that only use function (2) will look like http://www.fractalforums.com/images-showcase-(rate-my-fractal)/series-approximation/ which I think is kind of beautiful, however not what is recognized as a Mandelbrot fractal though... So, since function (2) is only accurate to about half of the iterations needed, we will unfortunately not be able to render tick-tock 640x360 in one second, something just below 10 seconds seems more realistic. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on July 01, 2013, 09:47:49 PM :embarrass: great, do you plan to make nanoscope available for others ? Most likely. Needs more testing and work, and if it's to be usable by non-techies, a real user interface, first. I might be releasing the source code sooner than there's a nontechie-suitable executable artifact, though. Most likely on Github. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on July 02, 2013, 12:18:45 PM I have a question to mrflay and Pauldebrot, since you have implemented the "series approximation":
I believe you are validating the approximation in several pixels in the images, in order to find the highest iteration where the approximation is valid? Is that really gaining anything? When I test different pixels I always get the exact same number of valid iterations... I finally understand mrflays statement "the time taken rendering Mandelbrot images is largely independent of depth and iteration count, and mainly depends on the complexity of the image being created". :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on July 02, 2013, 12:45:17 PM I have a question to mrflay and Pauldebrot, since you have implemented the "series approximation": I believe you are validating the approximation in several pixels in the images, in order to find the highest iteration where the approximation is valid? Is that really gaining anything? When I test different pixels I always get the exact same number of valid iterations... Noting that after a short time, A, B, and C are separated by roughly equal numbers of orders of magnitude, I use the current values of B and C to estimate the uncomputed D, coefficient of delta4, and make sure that it times the fourth power of the image side length remains negligibly small. There's no testing against pixels; it just works. On the other hand, I've overhauled blob-purging (already). Now instead of switching to high precision calculations for whole grids of pixels, it does only a handful at full precision. First, the initial search for a high iter region terminates if either five or more pixels yield identical, non-maxiter smooth iteration values (blob!) or the "net" around it gets tiny or stops shrinking much; then, the center of the "netted" region is iterated at high precision and checked for discrepancy with the PT approximation at the same point. If they differ, the center is used as a reference orbit to continue the process: the net tightens some more, if a blob of constant iter now resolves into structures around a smaller blob (or a point). When the net again stops tightening, the center is again checked at full precision. If the iterations are higher than the current secondary reference point, that becomes the new secondary reference point. In any event, if the net stops shrinking or becomes 1 pixel or so in size, the process terminates and full image rendering can begin. This new method of locating any needed secondary reference point is about twice as fast as the old, and more accurate besides; on that test image where the old took 30 minutes, the new takes 15, despite being single threaded (the old parallelized some things, and I have six-core hardware here). The downside: the slow bits (new reference orbit calculations) aren't amenable to parallelizing. (Keep in mind that that test image is below e308 and has 300,000+ iterations everywhere -- 400,000 in the very centers of the blobs.) I've also substantially sped up image renders with two reference points. The renderer tracks the lowest iteration count (as returned using the primary reference point) for which a discrepancy was observed between iterations using both reference points, and the highest iteration lower than that for which both were used but no discrepancy was observed. At first, the lowest is set to maxiter and the highest to zero, and points all get both reference points used. Any point that iterates with the primary reference point to a count higher than either "water mark" gets the secondary reference point used, and the max of the iteration values from both iterations used. Any point iterated with both reference points is also used to update the two "water marks", using the iteration count from using the primary reference point to set them. Finally, any point where using the primary reference point gets an iteration count lower than both "water marks" is taken at face value, without using the other reference point. If the blobs don't occupy a large percentage of the image pixels, this results in a near-2x speedup, to near parity with blob-free images. In the very near future I'll be knocking your socks off in the Images Showcase forum with a result from all of this. ;) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on July 02, 2013, 04:16:06 PM In the very near future I'll be knocking your socks off in the Images Showcase forum with a result from all of this. ;) Looking forward to that :)Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on July 12, 2013, 11:59:32 AM I wondered about that as well, since we use 32-bit and 64-bit Java code at work for scientific calculations. According to the JLS, if you use the 'strictfp' keyword: "Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. " As I read this, Java calculations (with strictfp) must be exactly equal on all platforms. strictfp will disallow higher precision results..aka cannot convert a multiply plus add to fused madd instruction.. all basic operations must be properly rounded results per op. Java's strictness disallow most FP transforms by default and strictfp only applies to basic ops. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on July 15, 2013, 01:56:54 PM I am adding this comment to the appropriate thread as well:
Here is a location that might be a challenge for those who are trying to create general fractal explorer programs that are able to take care of all kinds of glitches: Code: Re: -1.768534924421349949270981466087798476715853694537361755308932708832468117755950400059653117782799902337478638501072448963628214932441920842176948908374018641322144530898392300564007162704979935800934871014049179313829574155128361677427135196101360338791366078063894990715467902483187609339593823325014485511210158987366776835280397149444804359644147713966607524271943068601381762700362 Further, the series approximation function in the linked pdf document contains only the terms A (for delta), B (for delta^2) and C (for delta^3). Does anybody know what the function would be for calculating a fourth term D for delta^4? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on July 15, 2013, 03:19:32 PM I expect that adding more terms gives quickly diminishing returns.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on July 15, 2013, 07:52:54 PM As I've mentioned in a couple of other threads how you compute complex powers is very important to prevent precision loss....up to massive catastrophic cancelling...aka all of the result is garbage although the result can be well represented.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on July 31, 2013, 10:49:35 PM Can blobs still happen when the series approximation is not used if the reference point is inside or near the image and it does not escape for the valid max iteration for the whole image (which looks correct with that max iteration if sufficient arbitrary precision is used)? If so, why can they still happen?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on August 01, 2013, 01:49:28 AM Blobs have nothing to do with the series approximation. Blobs result when points in the image "resonate differently" from the reference point in substantial ways, traveling far from the reference orbit while still not escaping. Nearby points in a blob end up with deltas with many "static" nonzero significant figures before the first ones that differ, and lack of precision can render them indistinguishable, resulting in the blob. A reference point that travels with them (generally one from the core of the blob itself works best) will avoid producing that blob as those many static figures in the deltas become zeros and thus don't consume any of the available mantissa precision. However, another part of the same image may become a blob with the alternate reference point, so sometimes it is necessary to use two.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 01, 2013, 09:02:56 AM Yes, if the reference point, even if it eventually ends up in a minibrot, have too few iterations, compared to the blob areas, within depths reachable from the double datatype, there will be blobs.
If a reference point is added in the center of one of the blobs, it usually correct the other blobs of same type/shape. Series approximation cause other glitches though, the diagonal lines mentioned and also "surfing along curved edges" is not possible at all. I will add a movie later showing what I mean with that. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 01, 2013, 10:14:50 AM Yes, if the reference point, even if it eventually ends up in a minibrot, have too few iterations, compared to the blob areas, within depths reachable from the double datatype, there will be blobs. If the reference point is in a minibrot it can't have too few iterations compared to other points in the image unless the general maxiter for the image is set too low. That is a separate issue. The problem with the rounding errors I can understand, though. I have not seen such a case yet but I don't do 'very' deep zooms. Does anyone have an example for this that is not zoomed in very deep?Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 01, 2013, 12:46:31 PM If the reference point is in a minibrot it can't have too few iterations compared to other points in the image unless the general maxiter for the image is set too low. But these high iterations might be too deep and not reachable from a double in the blob's area. On the same level as the blob, the reference point in the minibrot have fewer iterations than the blob area.I have not seen such a case yet but I don't do 'very' deep zooms. Does anyone have an example for this that is not zoomed in very deep? It's not hard to find them, just zoom near but not inside a minibrot and then center the zoom to find another minibrot. When the pattern of the first minibrot is repeated and doubled, you will usually get blobs if you go deep enough. A double doesn't handle more than about some 20 decimals correct, so it makes sense that you don't see this unless you go twice (hmm... I mean the power of 2) as deep as that, i.e deeper than 1e40. An example Code: Re: -1.99213324664384300764723417856669787618617795243197913361627207256668566332812499 The blobs are visible at 1e35, 4e4, and 8e44. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 01, 2013, 03:12:29 PM But these high iterations might be too deep and not reachable from a double in the blob's area. On the same level as the blob, the reference point in the minibrot have fewer iterations than the blob area. If maxiter is such that it's high enough for the picture when no precision issues occur then the reference point in the minibrot has maxiter iterations. Anything else in the picture not in the Mandelbrot set will escape before maxiter is reached. So if in a blob maxiter is reached maxiter is too low for the picture or it's an effect of rounding errors (e.g. pixels in the blob would have escaped before maxiter is reached if sufficient precision was used). So are you saying pixels in the blob not only become indistinguishable from each other due to lack of precision but also continue to not escape although they should have escaped before maxiter is reached? If so, do they all escape together at the same time with a higher maxiter?Quote It's not hard to find them, just zoom near but not inside a minibrot and then center the zoom to find another minibrot. When the pattern of the first minibrot is repeated and doubled, you will usually get blobs if you go deep enough. Thanks for the location. I will have a look when I start zooming this deep.A double doesn't handle more than about some 20 decimals correct, so it makes sense that you don't see this unless you go twice (hmm... I mean the power of 2) as deep as that, i.e deeper than 1e40. An example Code: Re: -1.99213324664384300764723417856669787618617795243197913361627207256668566332812499 The blobs are visible at 1e35, 4e4, and 8e44. How do you automatically decide on a reference point and make sure it iterates to maxiter before you process the picture? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 01, 2013, 04:24:38 PM How do you automatically decide on a reference point and make sure it iterates to maxiter before you process the picture? I just select the pixel in the center as reference and add references later to correct the glitches.But for the example, I zoomed to the minbrot at 1e47 and "locked" the reference point there and then zoomed out again. Here is a picture of the location I mentioned, zoomed to 1e35 and with the reference point in the 1e47 minibrot, with no additional reference points. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 01, 2013, 04:50:08 PM So are you saying pixels in the blob not only become indistinguishable from each other due to lack of precision but also continue to not escape although they should have escaped before maxiter is reached? If so, do they all escape together at the same time with a higher maxiter? No, they escape at the same iteration but not necessary at the highest iteration. There might be other parts in the same picture, not belonging to a blob, with higher iterations than the blob. So it is a challenge to detect the blobs automatically... :)Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 02, 2013, 03:14:50 PM I have just started deep zooms with the delta formula and use automatic reference point assignment. So far no blobs. I also added the distance measure computation with a delta formula. I want it for colouring purposes. And it might come handy for other things. ;D
Needs a lot more testing, though, to see if blobs happen or not. The series extension I won't consider for now since its speedup is limited to about half the time compared to without. ? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 02, 2013, 03:47:19 PM The series extension I won't consider for now since its speedup is limited to about half the time compared to without. ? If you look at time comparisons in the thread about "Kalles Fraktaler" you'll see that the speedup was 10 times for the "tick-tock" location.Series approximation let you skip iterations in the delta function. The amount of iterations that can be skipped is dependent on the image's complexity, i.e. iteration span, rather than depth or the maximum iteration count. The automatic assignment of reference point sounds interesting though. Is it possible to compare points without calculating them with full precision? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 02, 2013, 06:01:12 PM If you look at time comparisons in the thread about "Kalles Fraktaler" you'll see that the speedup was 10 times for the "tick-tock" location. How do you decide how many iterations to skip?Series approximation let you skip iterations in the delta function. The amount of iterations that can be skipped is dependent on the image's complexity, i.e. iteration span, rather than depth or the maximum iteration count. Quote The automatic assignment of reference point sounds interesting though. Is it possible to compare points without calculating them with full precision? To be safe so far I have done all reference point calculations with my default arbitrary precision (1000 bits). Double precision won't work for my approach.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 02, 2013, 11:09:26 PM I just select the pixel in the center as reference and add references later to correct the glitches. I get this region when using 1.0E-34 as size in the real direction.But for the example, I zoomed to the minbrot at 1e47 and "locked" the reference point there and then zoomed out again. Here is a picture of the location I mentioned, zoomed to 1e35 and with the reference point in the 1e47 minibrot, with no additional reference points. I can see the region is critical. Depending on where you look the dominant period modulating the iterations changes several times hopping from from center to center in the picture to centers far away from the picture. And the center of the picture is close to zero for i and close to 2 for r which combines very far away values. Worst case behaviour for the deltas, I guess. I can see clearly distortions for the distance measure based on deltas. These get distorted more quickly than iterations since the formula is more complicated. For iterations it depends which reference point is chosen. I have to look into this more to see if one point works properly for all the picture and which one it is. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 03, 2013, 05:09:37 PM How do you decide how many iterations to skip? I do as mrflay, I compare the values from the approximation functions with the pertubation function on a couple of pixels. I select the 4 corners. Quote I have to look into this more to see if one point works properly for all the picture and which one it is. I believe that's not possible. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 04, 2013, 01:18:31 AM I do as mrflay, I compare the values from the approximation functions with the pertubation function on a couple of pixels. I select the 4 corners. I believe that's not possible. I use this location for now (left lower corner and right upper corner)-1.9921332466438430076472341785666978808861779524319777569397215373725755380248565573828125 -0.000000000000000000000585323508730791567761461851578556877376388157622575720310458828125 -1.99213324664384300764723417856669786998617795243197362691006993179024516211505125953125 -0.000000000000000000000585323508730780667761461851579977962847908357994317968845615078125 It has distortions like yours (it's zoomed in a bit into yours). I think I found a point that works for all of it. I need to verify my theory why and if this point works and how to find it automatically (found it 'manually'). Going back to your original location: So far what I see is that a large part of the picture has a 'dominant' period from a minibrot far away. Using that minibrot as reference renders pretty much the whole picture useless. If one uses minibrots in the picture the higher the dominant period they belong to the better the results... Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 04, 2013, 08:08:08 PM I think I found a point that works for all of it. I need to verify my theory why and if this point works and how to find it automatically (found it 'manually'). To be continued... Yes you are right, for the location above it is possible to render the image without blobs from one reference point. That is because the center do not have any distinct pattern.But this location (the top on the page) is not possible to render with one reference point only: http://www.fractalforums.com/images-showcase-(rate-my-fractal)/other-worlds'-frightening-digital/ If you use the center, you will have blobs around, if you use the center of one of these blobs, all these blobs are solved but instead the center becomes a blob. Therefore I think it is impossible to have only one reference point for all pictures. But I would be glad if you could prove that I am wrong and show how to find the best reference point automatically :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on August 05, 2013, 02:32:24 AM If I understand correctly, the blobs happen in regions where the magnitude of the derivative
Using the notation of the pdf document, the derivative of wrt Could anyone verify? (I can't do it myself :-\) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 05, 2013, 01:06:52 PM If I understand correctly, the blobs happen in regions where the magnitude of the derivative <Quoted Image Removed> becomes too small (or too big?) at some iteration(s). Taking the minimum (and the maximum?) of <Quoted Image Removed> would give some information about the areas where floats are no more sufficient and where blobs occure. I'll test it later today. A blob could be a region where the derivative becomes bigger than some threshold, I guess. But it's not conclusive at first sight. The formula for the delta is precise. The blobs are due to rounding errors, not fast changes of the deltans as a function of delta zero. The question is how are rounding errors correlated with this derivative. Possibly not.Using the notation of the pdf document, the derivative of <Quoted Image Removed> : <Quoted Image Removed> wrt <Quoted Image Removed> is : <Quoted Image Removed> <Quoted Image Removed> Could anyone verify? (I can't do it myself :-\) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on August 05, 2013, 06:43:06 PM I just noticed that the derivative I gave in my previous post is just the standard derivative wrt c. lol! after thinking a little about it, it is just obvious.
@hapf: Thank you in advance :). Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on August 06, 2013, 01:11:44 AM @hapf: You are right. It seems that derivative have nothing to with the blobs. The areas where the derivative vanishes are always inside de Mset.
Another try ;D (remembering a article about floating point accuracy issues somewhere in the net): cancellation which induce accuracy loss happens usually when subtracting two numbers which difference is very small. In the formula: if: or: (which is equivalent) we will loose significant digits. This phenomenon may occure several times in the loop implying that the numerical errors accumulates. Maybe there is also some kind of resonance. I don't know though how these errors accumulate. (Ok! I have checked this by using only double floats). Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 06, 2013, 05:57:16 AM If you're working on one of these it would probably be a good idea to review "what every computer scientist should know about floating-point arithmetic".
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 06, 2013, 02:54:55 PM If you're working on one of these it would probably be a good idea to review "what every computer scientist should know about floating-point arithmetic". The relevant formulas for delta i and delta r have not much to optimize. There is one term (a˛-b˛). Replacing it with(a-b)*(a+b) actually delivered worse accuracy in the example I tested. :hrmm: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on August 06, 2013, 06:48:39 PM If you're working on one of these it would probably be a good idea to review "what every computer scientist should know about floating-point arithmetic". That was it IIRC!Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hobold on August 06, 2013, 10:58:27 PM The relevant formulas for delta i and delta r have not much to optimize. There is one term (a˛-b˛). Replacing it with Numerics is tricky and can be quite frustrating. The proper way to do these kind of things isn't really by trial and error ("let's see if this makes things more accurate!"). In a perfect world, you would have the opportunity and the means to analyze the programmed formulas, and find out if there are any (at least statistical) guarantees about relative magnitudes, or about same/opposite signs, and so on. And then you would pick the most accurate way of computation and write that into the program.(a-b)*(a+b) actually delivered worse accuracy in the example I tested. :hrmm: In practice, there are quite a few cases where no really accurate way of computation is known, you can only minimize the losses somewhat. And often the analysis does not yield any guarantees. Then the most accurate way would require a check at runtime, and a conditional branch to the appropriate form of computation. Testing can be very expensive, and even the conditional branch can be very expensive when it behaves unpredictably. Numerics just isn't pretty. I see it more as a necessary evil to make floating point math robust and reliable, on top of its virtues of being fast and convenient. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 07, 2013, 01:28:22 PM @hapf: The entire formulation must be considered to find the desired balance between speed & accuracy.
WRT the mentioned, a quick mental review of the two forms it seems impossible for a2-b2 to be more accurate the (a+b)(a-b), but my numerical analysis is really rusty. Can you can an example of values to demonstrate the contrary? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 07, 2013, 04:11:28 PM @hapf: The entire formulation must be considered to find the desired balance between speed & accuracy. I used http://www.fractalforums.com/index.php?topic=16457.msg63060#msg63060 (http://www.fractalforums.com/index.php?topic=16457.msg63060#msg63060) and looked at the iterations in a blob area. I compared both formulas results against precise results. Average deviation was bigger for (a-b)*(a+b). I compared some pixels, not all pixels in the blobs.WRT the mentioned, a quick mental review of the two forms it seems impossible for a2-b2 to be more accurate the (a+b)(a-b), but my numerical analysis is really rusty. Can you can an example of values to demonstrate the contrary? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 07, 2013, 04:31:54 PM cancellation which induce accuracy loss happens usually when subtracting two numbers which difference is very small. Wouldn't that be equal to check that Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on August 07, 2013, 11:15:41 PM I would say it is equivalent to:
One thing worth to verify is to: Check if If true set If the blob effect is due to cancellation then it would be replaced by some (maybe deformed) details. That said, I'm not sure what is exactly happening. For now this superfractalthing looks to me just like numerical black magic. I'm just trying to understand. :'( Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 08, 2013, 10:07:20 AM Sterbenz theorom: given two floating point values x & y where y/2 <= x <= 2y, then x-y is exact.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 08, 2013, 10:28:02 PM Follow-up on x2-y2 vs. (x+y)(x-y). With a little more thought I've realized that the second can have more error than the first, but it should never be more that one ULP of properly rounded. But considering I screwed up the first time take this with a grain of salt. However the first can have much larger errors.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 14, 2013, 01:31:45 PM I have tested this new rendering method quite some time now. The challenge is clearly to find good reference points. Without them blob detection and blob fixing becomes more and more of an issue depending on where you zoom and how much you zoom.
If you let the computer pick a point at random in the region/picture it will usually not be in a minibrot and blob detection is unavoidable as many points run out of available iterations from the reference point. If you let the computer automatically find a minibrot, which one should it use? Can't be too far outside the region or accuracy breaks down and blobs are created. In the region finding it is not (always) trivial, as far as I can see. And once it's found it might still create blobs somewhere in the picture. So blob detection seems basically unavoidable, and lacking a method to identify blobs reliably and find good reference points among the blobbed pixels there is no telling how long the blob fixing goes on, using full precision at every step and endangering the speed of the method. Nonetheless the results that can be obtained from your 'average' locations are spectacular and in minutes you see complexity you had to wait for for days without the method or were simply out of reach in the 80s, when it all began. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 14, 2013, 01:50:36 PM I have tried to validate that
It seems that some glitches is simply due to insufficient precision, no matter what, and there is no common behavior of numbers in the series. Just to be sure, here is how I calculated the validation above, which includes complex division: I then get the following code for the division and the validation (0.001 is an arbitrary small number, I have tried smaller and bigger): Code: cr = (dr*xr+di*xi) / (xr*xr+xi*xi); Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: knighty on August 14, 2013, 03:07:56 PM There is a typo in my previous post: I've written
I did some experiments with a basic implementation that doesn't use multiprecision arithmetics. The attached pictures are zooms around the point: ( -1.7490030131, 0.000247672). The colors represent the values of The first uses the reference point: ( -1.7490030131, 0.000247672) and the second the reference point: (-1.7490030131+9.09e-7, 0.000247672+11.39e-7). Both are inside minibrots. in perticular notice the "shape" of the blue dots. There are two types: cone shaped and flat ones. I think that blobs would appear in the blue flat dots but not cone shaped ones. This of cours when zooming much more. Not in this particular example. The values of Code: mandel2(tx,ty,mi){Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 19, 2013, 07:23:26 PM AIUI, Superfractalthing also has some method for determining when a second reference point is needed; I don't know about Kallesfractaler, though, or the methods either use. I've described mine in the hope that it may be helpful to either of their authors, and in the hope that someone might have a useful suggestion for speeding my own up. How does Superfractalthing decide a new reference point is needed and how is it determined?I so far have tried to find suitable minibrots in or around the image region, which seems to be difficult in some cases. No good method yet that is fast and works everywhere. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 24, 2013, 08:26:07 PM Here's a nice place to use for checking your anti 'corruption' measures. :dink:
Render it at 2K plus to see where the issues likely are. Not (well) visible at PAL/NTSC resolution. 3.491243948744602226845164903446013604574954671252471332414684967283103122394453166881753622839962804126553654590343280 405480576210221670E-01 7.044912918643927975113013191745694904413230679707124075989897868290741298182991608687727632191553399184489116483374676 984467558071736600E-01 3.362630349E-126 (sorry, the old parameters were wrong. :embarrass: ) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 28, 2013, 10:24:42 AM Some members here have expressed their hopes that it would be possible to use only single precision float datatypes when rendering Mandelbrot fractals with this pertubation theory, in order to implement it in GPU, and I did investigations that showed that it was not possible.
However, I did some tests by changing the mantissa member of my floatexp class to be of float instead of double, and the locations I tried so far renders fine with that. So, the problem using single precision float may not be the precision of the mantissa, which seems to be sufficient. The problem may instead be that the pertubation calculations have intermediate steps that exceeds the exponent range of the float datatype, (10^-38 - 10^+38) I hope those who wants to implement this in GPU can use this information and make an extremely fast unlimited Mandelbrot explorer! :D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 28, 2013, 11:51:13 AM Have I every mentioned that squaring first drastically increases the bound on error? :) Seriously...pull out a power of two scale factor. Out of curiosity I'd assume that someone has tried comparing straight doubles vs. unevaluated sequences (double-double & quad-doubles are examples) for visual impact. If they increase then the techniques behind can be used to create a computation sequence with performance somewhere in the middle of using straight doubles and a generic method.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 28, 2013, 12:11:53 PM So, the problem using single precision float may not be the precision of the mantissa, which seems to be sufficient. I'm using long double which has a huge exponent range (-4932 - +4932). It does not stop the blobs/distortions from popping up. The mantissa is the problem here. For less demanding regions float might be fine with larger exponent range, but it will fail when zoomed deeper in long before long double will fail.The problem may instead be that the pertubation calculations have intermediate steps that exceeds the exponent range of the float datatype, (10^-38 - 10^+38) I see only two solutions to this problem. - Use arbitrary precision also with formula (1)(no series approximation), with just enough bits to avoid the distortions. That robs the method of its superior hardware float speeds, but is still quite some faster than using full arbitrary precision with bits as required for the normal approach. - Reliably detect the distortions and assign better suited references in these regions. How to do that automatically, reliably and fast is an open question to me. If any of you have the solution I'm all ears to hear about your approach. Consider that series approximation approximates (1) and reliably keeping it under control not to deviate too much from (1) will not solve the problems with (1) itself coming from rounding errors summing up gradually to more or less visible corruptions of the image. The higher resolution your image the more different places can pop up that are corrupted and need to be addressed. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 28, 2013, 11:26:07 PM I'm using long double which has a huge exponent range (-4932 - +4932). It does not stop the blobs/distortions from popping up. I was not referring to the blobs, my previous test using float was not able to create images at all.But with long double you would be able to zoom to e4932 without having to create any custom datatypes. I wonder how performance is on the long double datatype compared to double in a 64-bit CPU, does anybody know? Also, is the float datatype really faster on a 64-bit CPU, I would imagine it would be faster on 32-bit but not on 64...? - Use arbitrary precision also with formula (2), with just enough bits to avoid the distortions. I don't think this will help, the series approximation just gives you iterations that can be skipped on formula (1), and it is still formula (1) that is used to calculate the pixels. If you would use arbitrary precision on formula (1) it might solve all blobs, you would only gain a little performance with series approximation on simple locations but loose performance on complex ones.- Reliably detect the distortions and assign better suited references in these regions. How to do that automatically, reliably and fast is an open question to me. If any of you have the solution I'm all ears to hear about your approach. ... The higher resolution your image the more different places can pop up that are corrupted and need to be addressed. Indeed there can be many blobs on the same image and more to appear when the resolution is increased, and I haven't found any reliable way to detect them all (Pauldebrot might?). I rely on the ability to eventually add references manually...This one is particularly nasty: http://www.fractalforums.com/images-showcase-(rate-my-fractal)/flake/ Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 29, 2013, 09:41:00 AM I meant arbitrary precision on formula 1, not 2. On 2 it's useless, of course. ;D
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 29, 2013, 10:01:04 AM Has anyone attempting seeing how equipotential lines are in the problem areas or the proximity of periodic points or how the gradient field looks, etc?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 29, 2013, 10:04:50 AM This one is particularly nasty: Is it looking correct on your image? Did you tweak that a lot? I get your image pretty much directly when rendering with the central minibrot. Does not look very problematic to me (at smaller sizes). Just kind of boring/blobby look when not enough colours are pumped into it.http://www.fractalforums.com/images-showcase-(rate-my-fractal)/flake/ Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 29, 2013, 10:12:59 AM Has anyone attempting seeing how equipotential lines are in the problem areas or the proximity of periodic points or how the gradient field looks, etc? What problem areas? Areas where distortions happen? These areas are due to the reference point so they come and go with different reference points. What often happens is that the distance measure clips there too leaving blobs or dithered areas behind where there should be proper structure. So the gradients and equipotential lines get distorted.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on August 29, 2013, 10:43:43 AM I was thinking long the lines of choosing reference points.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on August 29, 2013, 11:27:22 AM I was thinking long the lines of choosing reference points. The solution must come from a better understanding why one reference point produces more rounding errors with a specific point than another. 2 main factors to look into:- distance of reference point (generally the farer away from the region/picture/point the worse) - dominant period of point and reference point and how well the 'jumping around patterns' are in harmony (to be defined clearly what in harmony means regarding to rounding errors) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 29, 2013, 02:51:20 PM Is it looking correct on your image? Did you tweak that a lot? I get your image pretty much directly when rendering with the central minibrot. Does not look very problematic to me (at smaller sizes). Just kind of boring/blobby look when not enough colours are pumped into it. There are a lot of small spirals in this flake image, and many references are needed to render them all...Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on August 29, 2013, 03:13:17 PM The solution must come from a better understanding why one reference point produces more rounding errors with a specific point than another. 2 main factors to look into: From what I understand from Pauldebrot's explanation, and animation, of his solution is that he tried to narrow down areas where the iterations increase until it ends in a plateau with equal iterations - and that is where the blob is. But my experience is that the blobs also can occur in the middle of areas with decreasing iterations, or areas where the iterations increase and then a narrow surrounding of decreased iterations just around the blob. Or many other situations.- distance of reference point (generally the farer away from the region/picture/point the worse) - dominant period of point and reference point and how well the 'jumping around patterns' are in harmony (to be defined clearly what in harmony means regarding to rounding errors) I think his approach is correct though, that the all blobs appear as a plateau on increasing iterations, but since our images are based on pixels, pixels may not be enough resolution to identify increasing iterations surrounding plateaus. It's like a landscape with hills and valleys, and some of the hill-tops are chopped off - these are what we are to find. They usually have a round shape, but since they can be in the edge of an image, they can have any shape. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 17, 2013, 06:09:36 PM AIUI, Superfractalthing also has some method for determining when a second reference point is needed; I don't know about Kallesfractaler, though, or the methods either use. I've described mine in the hope that it may be helpful to either of their authors, and in the hope that someone might have a useful suggestion for speeding my own up. I don't know about speed up potential but once you have a region located that contains a blob or is inside a blob and you look for the pixel with the highest iteration count to serve as a second reference you can instead of checking pixels simply compute the location of the period center of a minibrot in that region. A reasonable guess for a suitable period is the highest iteration count you have seen so far in that region minus one or two starting the computation from the pixel that had that count. If periods get very large though computation time gets quite long. Arbitrary precision is required. One can try to speed up the calculations by using PT again, but the benefits are unfortunately quite limited since rounding errors spoil the result quickly (e.g. endless loops and other anomalies). Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on September 17, 2013, 10:21:13 PM Beside that, how are things going with your long double SFT program?
I'm very interested in the long double datatype, and Microsoft's compiler does not support it. I tried "Bloodshed Dev-C++" which supports the 12 byte long double datatype. However the Dev-C++ program had slower performance than my custom datatype. It would be interesting if anyone could confirm my findings. Is the long double datatype very slow compared to double (some 20 times slower)? Or is Microsoft's compiler super optimized and superior to other compilers? Or did I do something else fundamentally wrong? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 18, 2013, 10:31:23 AM Beside that, how are things going with your long double SFT program? Long double on Linux is 16 bytes (8 significand, 15 bits exponent, 1 bit sign, rest unused). It is not much slower than double.I'm very interested in the long double datatype, and Microsoft's compiler does not support it. I tried "Bloodshed Dev-C++" which supports the 12 byte long double datatype. However the Dev-C++ program had slower performance than my custom datatype. It would be interesting if anyone could confirm my findings. Is the long double datatype very slow compared to double (some 20 times slower)? Or is Microsoft's compiler super optimized and superior to other compilers? Or did I do something else fundamentally wrong? 64 bit significand is not enough to avoid blobs/corruption, unfortunately. So I'm currently working on the blob fixing part of the program. Automatic reference point generation is done and works well. Quite cool to let the program zoom in automatically to a minibrot in the neighbourhood of a pixel jumping from E-20 to E-40 or E-100 to E-400. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: aleph0 on September 20, 2013, 07:17:27 PM While mrflay's perturbation theory paper and the programs it has spawned are great (I use all of them), I noticed there is a small error at the start of the paper. It doesn't affect the utility of what follows in the paper, but it's worth being aware of.
Rather than add unnecessary noise to this thread, I've started a new thread to address it here: - http://www.fractalforums.com/general-discussion-b77/terms-z0-and-c-in-the-mandelbrotjulia-iteration-formula/ Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 20, 2013, 08:27:36 PM While mrflay's perturbation theory paper and the programs it has spawned are great (I use all of them), I noticed there is a small error at the start of the paper. It doesn't affect the utility of what follows in the paper, but it's worth being aware of. I don't understand the formula for delta2 in the paper. I get something else. Rather than add unnecessary noise to this thread, I've started a new thread to address it here: - http://www.fractalforums.com/general-discussion-b77/terms-z0-and-c-in-the-mandelbrotjulia-iteration-formula/ Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 20, 2013, 08:30:16 PM Question to those of you who use the series approximation. How many percent of the iterations can you skip
on average (without visibly degrading the picture)? What are the best and worst percentages you have seen? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: lycium on September 20, 2013, 08:39:21 PM I finally had a proper look at this paper last night, and asked my boss about it today. We both agree, that the "smallness" of the numbers don't really help anything - IEEE floating point stores mantissa and exponent, so it's in a sense "scale invariant". If you wanted to take advantage of the limited range, it would probably involve fixed point arithmetic.
Nevertheless, the real issue I have with this method is that it's not a true acceleration for the same computation. It's a kind of approximation, and the deviation from the "true" result is essentially impossible to quantify since it's a chaotic system. So it's something like apples and oranges comparison, no? Edit: I also noticed the uncommon domain in the URL (.co.nf), and had to look up where it's from - Norfolk Island! That's pretty remarkable, since there are only about 2000 people there :o Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 21, 2013, 09:47:37 AM I finally had a proper look at this paper last night, and asked my boss about it today. We both agree, that the "smallness" of the numbers don't really help anything - IEEE floating point stores mantissa and exponent, so it's in a sense "scale invariant". If you wanted to take advantage of the limited range, it would probably involve fixed point arithmetic. Well, the point is that you can calculate the actual images while zooming in far beyond what double usually allows (due to the inability to add a very "small" number to a "big" number) by not adding a "small" number to a "big" number but multiplying "small" numbers with "big" numbers and adding "not too different size" numbers. And it does work indeed very well for many images while others have areas where the double mantissa has not enough bits and rounding errors pile up to the extent that the result is severly distorted. There are alternative reference points for these areas that avoid distortion so the method in principle works for all zoom levels and offers SIGNIFICANT speed ups compared to a brute force arbitrary precision standard approach. Quote Nevertheless, the real issue I have with this method is that it's not a true acceleration for the same computation. It's a kind of approximation, and the deviation from the "true" result is essentially impossible to quantify since it's a chaotic system. So it's something like apples and oranges comparison, no? The first formula is exact up to the rounding errors of whatever format you use to compute it. Mathematically it is as exact as the original formula and it computes the same thing. Actually, for deeper zooms it is practically far more exact as the original formula when using the same floating point format because it goes on delivering useful results while the original formula gives just coarse numeric chaos or a constant image. The second formula (series approximation) is inexact and has to be used with care or serious damage is done to the computations. The real remarkable formula for me is the first. The second is gravy for some types of images and better not be overindulged in or you get tummy trouble. ;DTitle: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Nahee_Enterprises on September 21, 2013, 11:09:43 AM I also noticed the uncommon domain in the URL (.co.nf), and had to look up where it's from - Norfolk Island! That's pretty remarkable, since there are only about 2000 people there :o Actually, getting Domain Names under some small country designation usually requires very little money, and they are less likely to be enforced by the various rules and regulations that sometimes happen in other countries. And sadly, such places are also used by a lot of spammers and bogus web site owners. :sad1: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: SeryZone on September 21, 2013, 04:58:26 PM Hello to all!!! I guess, It's very hard & complexity location:
re 0.250,002,621,568,580,738,997,691,523,223,923,403,858,705,697,470,944,821,494,7 im -0.000,000,006,774,686,923,476,700,530,474,801,910,940,390,679,981,369,231,565,2 Zoom: 1e54 I have started render it. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 21, 2013, 07:27:29 PM Hello to all!!! I guess, It's very hard & complexity location: I hope you have a Petaflop computer if you want to see this region in high res and soon. :dink:re 0.250,002,621,568,580,738,997,691,523,223,923,403,858,705,697,470,944,821,494,7 im -0.000,000,006,774,686,923,476,700,530,474,801,910,940,390,679,981,369,231,565,2 Zoom: 1e54 I have started render it. Needs more than 16 Million iterations... Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on September 21, 2013, 08:25:34 PM Question to those of you who use the series approximation. How many percent of the iterations can you skip It is very dependent of the location. on average (without visibly degrading the picture)? What are the best and worst percentages you have seen? Best - all but some 10 of some 100000. That is very deep near -2,0i Worst - some 2-3 of some 10000000, in a close-up of a deep minibrot Mrflay says in his paper that series approximation is dependent of the complexity of the image. My non-mathematical expression is that this means the range of iterations in the same image. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 21, 2013, 08:47:57 PM It is very dependent of the location. Am I reading this correctly?Best - all but some 10 of some 100000. That is very deep near -2,0i Worst - some 2-3 of some 10000000, in a close-up of a deep minibrot Best: 100% minus some 10 (e.g. 70-80% or so) of iterations in the range of some 100000? Worst: 2-3% of iterations in the range of some 10000000 (that must take very long to render even at smaller resolutions) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: SeryZone on September 22, 2013, 04:09:15 PM I hope you have a Petaflop computer if you want to see this region in high res and soon. :dink: Needs more than 16 Million iterations... I use 50 000 000 iterations. 2x2 AA. If walk - means walk! I fluff that it maybe can renders more than 12 days! I want look to this location!!! I have 8-Core 4GHz AMD Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 23, 2013, 11:41:12 AM I use 50 000 000 iterations. 2x2 AA. If walk - means walk! I fluff that it maybe can renders more than 12 days! I want look to this location!!! I have 8-Core 4GHz AMD I don't think it looks fundamentally different from the same region zoomed out to more computation friendly iteration numbers (2 Million or so).Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on September 23, 2013, 03:07:14 PM Am I reading this correctly? Series approximation give me 95739 iterations of SeryZone's location, if it requires 50 million it will indeed take some time to render it...Best: 100% minus some 10 (e.g. 70-80% or so) of iterations in the range of some 100000? Worst: 2-3% of iterations in the range of some 10000000 (that must take very long to render even at smaller resolutions) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: brainiac94 on September 28, 2013, 11:02:45 PM The concept is amazingly simple yet so powerful - Words are failing me. Thank you, mrflay, for this method. You even made a Java implementation.. I am speechless.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on September 29, 2013, 11:45:45 AM The concept is amazingly simple yet so powerful - Words are failing me. Thank you, mrflay, for this method. You even made a Java implementation.. I am speechless. It's quite something, isn't it, especially if one can get rid of the "blobs" in a timely fashion? ^-^Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: brainiac94 on October 03, 2013, 04:28:49 AM get rid of the "blobs" I downloaded SFT's code and started rendering a zoom without reading more than maybe one page of this thread. I have since run into the blobs and I dread them. I have taken the time to identify all my blobbed frames and, so close to completing the video, am willing to spend lots of computing time eliminating them.. I even resorted to pasting parts of good frames over the blobs in Paint.NET by hand.. Have you guys come to any "working" way to get rid of them, regardless of efficiency? Edit: After actually reading a good part of the thread, I tried to split the blobbed frames vertically and render each half individually. My idea was that it would result in different reference points, and it does indeed work like a charm. Implementing this and merging the PNGs after rendering is trivial and picking out the broken frames by hand is okay for me, so I will just tell my software which frames I want re-rendered in this fashion and the blobs will be defeated. Once again, great work! I am so happy to finally have this free and incredibly efficient software. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 03, 2013, 06:37:31 PM Edit: After actually reading a good part of the thread, I tried to split the blobbed frames vertically and render each half individually. My idea was that it would result in different reference points, and it does indeed work like a charm. Implementing this and merging the PNGs after rendering is trivial and picking out the broken frames by hand is okay for me, so I will just tell my software which frames I want re-rendered in this fashion and the blobs will be defeated. I doubt that works in general. I don't know how SFT selects reference points, though.Does it work for this region simply by splitting vertically in the middle? -1.4286834450720908323536745652315210519302441679686062023167081505113436391520073310684621209340498784840833268742809294590859491122325334517211060328215717496653589864847131768204309481202118089862775783597674485966256739928525464654718845489972747832732448165677988906514523111972E+00 -1.6249714167279050622903119235098671074408472668686211688386758706636769058023399093938140040045751978736837152053493586322683075141206689859218984124859502172196525489346454846749412611777998816497558114213964228961216131628268228308266344518028972043035404782111712652663530081419E-01 5.491739575E-268 (horizontal size) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: brainiac94 on October 03, 2013, 10:25:36 PM I doubt that works in general. It's not 100% certain, but I implemented three different ways to split the image (vertically, horizontally and both) and that seems to be helping. My computer is still re-rendering the blobbed frames, but I'll give it a try once that's done. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 04, 2013, 10:17:15 AM It's not 100% certain, but I implemented three different ways to split the image (vertically, horizontally and both) and that seems to be helping. Divide and conquer can help depending on how references are chosen. But at worst many subdivisions are needed till the sub image is so small that any issues with the chosen reference have subpixel size and are not visible any more.My computer is still re-rendering the blobbed frames, but I'll give it a try once that's done. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 04, 2013, 10:35:20 AM I doubt that works in general. I don't know how SFT selects reference points, though. I cannot even see that this location contains any blobs?Does it work for this region simply by splitting vertically in the middle? ... But I guess you mean the 64 nodes in the circle? You need to render this image in a very high resolution to notice at all that they are blobs... Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 04, 2013, 12:50:38 PM I cannot even see that this location contains any blobs? I mean the 32 nodes in the middle third of the picture at my given horizontal size.But I guess you mean the 64 nodes in the circle? You need to render this image in a very high resolution to notice at all that they are blobs... If rendered with the central minibrot as reference. If you see no corruption at say 1000*750 pixels could you upload your image somewhere? Maybe it's the way you colour the image that hides the corruption. Or there is a bug in my code. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 04, 2013, 12:55:46 PM I mean the 32 nodes in the middle third of the picture at my given horizontal size. It may also be differences in the way we use the zoom magnification level.If rendered with the central minibrot as reference. If you see no corruption at say 1000*750 pixels could you upload your image somewhere? Maybe it's the way you colour the image that hides the corruption. Or there is a bug in my code. I consider this image be zoomed to 5.49E+268 and you are saying 5.49E-268 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 04, 2013, 02:38:09 PM My zoom level is the horizontal size. :)
5.491739575E-268 = horizontal size (real max - real min, no rotation assumed) So do you get blobs in the 32 bulbs at that size? Your pic is too small to see it well. You have 64 bulbs at that position. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 04, 2013, 04:43:29 PM Yes, if I zoom out to 1e266 there are 32 blobs pairs.
My automatic function finds and solves them for some resolutions, for others it doesn't... We may call the blobs in the pairs for A (the bigger one) and B (the smaller one). Even though all 32 A-blobs can be solved with the same new reference point inside one them, this reference does does not solve the B blobs, and vice verse. Fortunately all pixels in the bigger A blob have the same iteration count value, 39987, and the smaller B have the value 40025, so as long as the blob can be identified and a new reference point can be selected, it is easy to re-render the pixels with these iteration counts. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on October 13, 2013, 10:30:34 PM I figured out how to measure the inaccuracies that accumulate and lead to blobs.
In these images, darker pixels have more error (and the error is the only thing shown), so if the reference was perfect it would be pure white. The first image uses a reference in the minibrot at the center, and the second image uses a reference at the pixel with the worse error in the first image. http://mathr.co.uk/misc/2013-10-13_deblobber_1.png http://mathr.co.uk/misc/2013-10-13_deblobber_2.png I also uploaded my reference implementation source code (which also contains the parameters used for the first image): http://mathr.co.uk/misc/2013-10-13_deblobber.c Happy deblobbing! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 14, 2013, 01:57:37 PM I figured out how to measure the inaccuracies that accumulate and lead to blobs. Interesting claude, have you tried your function on the location from hapf?In these images, darker pixels have more error (and the error is the only thing shown), so if the reference was perfect it would be pure white. The first image uses a reference in the minibrot at the center, and the second image uses a reference at the pixel with the worse error in the first image. http://mathr.co.uk/misc/2013-10-13_deblobber_1.png http://mathr.co.uk/misc/2013-10-13_deblobber_2.png I also uploaded my reference implementation source code (which also contains the parameters used for the first image): http://mathr.co.uk/misc/2013-10-13_deblobber.c Happy deblobbing! Because I think the blobs are unfortunately not only because of "loss of significance" but also because the limited precision of the hardware data-types, and that it would be possible that the "loss of significance" would not be visible but there would still be blobs...? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 14, 2013, 05:13:33 PM Interesting claude, have you tried your function on the location from hapf? My location needs at least 2 references because double has not enough precision. It's not a case where a better reference does it for the whole image (up to some size in pixels). How many references are needed depends on the complexity of the image and the size in pixels, even when the best references are used. The more pixels the more one can potentially see local detail where the double runs out of precision. How quickly it runs out of precision does depend on the reference used as well, in addition to image complexity and size in pixels.Because I think the blobs are unfortunately not only because of "loss of significance" but also because the limited precision of the hardware data-types, and that it would be possible that the "loss of significance" would not be visible but there would still be blobs...? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on October 14, 2013, 08:05:04 PM double has not enough precision Right, that's true - I'm surprised it even works as well as it does. But it's not so much precision as what happens when going out of range - when values underflow the normal range they lose precision (or even become zero). Here's a table of numeric limits:
precision: number of mantissa bits range: number of exponent bits epsilon: smallest positive value such that 1 + epsilon != 1 normal: smallest positive normal number nonzero: smallest positive number finite: largest finite power of two I also included the square root of some of these values in the tables. The "sqrt normal" column is what I would use as a guideline for chosing which floating point type to use, comparing it with the pixel spacing in the image. I'd use double up to about 1e-150 (though I noticed that distance estimation can exceed range and cause problems from around 1e-140 or so) then switch to long double until about 1e-2460, then either use software floating point with a wide range (mpfr etc) or use a double int pair, using the int to extend the exponent range, keeping the double scaled near 1. If long double isn't available (eg: GPU) then I'd use the (double,int) thing earlier. long double is not necessarily slower than double - in fact it was 10% faster for hapf's location (presumably subnormal / denormal doubles take longer to compute than normal doubles). Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 16, 2013, 04:27:33 PM claude, maybe you are on to something though!!!
Maybe this can be used to locate where to put additional references, and also to indicate which pixels needs to be re-rendered with the additional reference. But I don't like your triple square root for every iteration, can't it be done without them? ;) I have discovered that my way of solving glitches, by replacing the pixels with the same iteration count in a blob, is not efficient on some locations, especially for stretched dense Julia patterns that arise after close passage of one of a minibrots dense tentacles. Here is an example Code: Re: -1.9855484133529534182456788035170260405619874319858542762764067467 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 17, 2013, 04:38:50 PM claude, maybe you are on to something though!!! The error will likely overflow if you don't use the root. And recursive error propagation is important. When I tried something like thisMaybe this can be used to locate where to put additional references, and also to indicate which pixels needs to be re-rendered with the additional reference. But I don't like your triple square root for every iteration, can't it be done without them? ;) I did not consider proper propagation and the resulting measure was not good enough for detecting corruption reliably. Quote I have discovered that my way of solving glitches, by replacing the pixels with the same iteration count in a blob, is not efficient on some locations, especially for stretched dense Julia patterns that arise after close passage of one of a minibrots dense tentacles. Corruption can start way earlier before constant blobs show up. So this error measure can help you find the potentially corrupted places. Here is an example Code: Re: -1.9855484133529534182456788035170260405619874319858542762764067467 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: quaz0r on October 19, 2013, 04:24:08 AM so did anyone end up having any thoughts on if this could be applied to 3D fractals?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on October 19, 2013, 11:51:44 AM when i asked a mexican pysics prof, he was wondering why we were not using the method all the time, because they are ;)
so, it is obviously perfectly appliable to other stuff as well, and might work as well in the 3d world, but it is a time consuming act to crteate such a derivative, and for 3d, we have just scratched the surface, in the mandelbrot we are now so deep, but in 3d we are just happy playing in the floating point range of single precision and being happy when using double precision haha, just my 5 cents for now! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on October 19, 2013, 03:46:25 PM I wrote up the maths for applying perturbation technique to the derivatives (including interior distance estimation):
http://mathr.co.uk/mandelbrot/perturbation.pdf (http://mathr.co.uk/mandelbrot/perturbation.jpg) 7 layers rendered 1920x1080 10000 maxiters 256bits mpfr reference long double deltas view height 1e-28 view center -1.98550202011904056068063519696893288601496598579e+00 + 2.885647596682972207197242785497600947886440918943e-05 i reference period 242 reference point -1.9855020201190405606806351970070281728451e+00 + 2.8856475966829722071972434856944234406073e-05 i calculations took 3m45s (13m45s CPU), considerably longer spent taking 5 of those layers and colouring/combining in Gimp (ended up with 57 layers/groups, mostly non-destructive) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Roquen on October 19, 2013, 09:29:10 PM The blue lines are period boundaries?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: claude on October 19, 2013, 09:56:40 PM Yes - edge detection filter on the period layer (iteration count when |z| reached its minimum). The other layers are binary "did it escape", integer iteration count, fractional iteration count, final angle, distance estimate (interior and exterior), error estimate.
Currently thinking about modular data interchange between different programs http://www.fractalforums.com/programming/separation-between-calcuation-and-colouring/ Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: simon.snake on October 20, 2013, 12:59:30 AM The black ring two thirds to the right are like ants defending their queen.
Interesting shades. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 21, 2013, 06:17:20 PM Thanks claude, I have used a variant of your method http://www.fractalforums.com/movies-showcase-(rate-my-movie)/many-colors/msg67653
I wish there were a way to find any internal structure in thos one-iteration blobs arising from passing the elephant valley of a minibrot. Can you create an image of such blob with structure? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 21, 2013, 08:19:35 PM Thanks claude, I have used a variant of your method http://www.fractalforums.com/movies-showcase-(rate-my-movie)/many-colors/msg67653 Coordinates?I wish there were a way to find any internal structure in thos one-iteration blobs arising from passing the elephant valley of a minibrot. Can you create an image of such blob with structure? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 21, 2013, 09:35:57 PM Coordinates? The final Minibrot in the movie is at Code: Re: -1.985548413352953418245678803517026040561987431985854276276406746845711126058992474579439478412845298466360323561521794573490777860670882406445312 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 22, 2013, 09:22:10 AM The final Minibrot in the movie is at Like this?Code: Re: -1.985548413352953418245678803517026040561987431985854276276406746845711126058992474579439478412845298466360323561521794573490777860670882406445312 (http://img19.imageshack.us/img19/7751/qv96.jpg) http://img19.imageshack.us/img19/7751/qv96.jpg (http://img19.imageshack.us/img19/7751/qv96.jpg) Can be done with one good reference point. (Excuse the horrible colours. They show detail at least.) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: blob on October 22, 2013, 10:27:40 AM Like this? (Excuse the horrible colours. They show detail at least.) Nothing wrong with those colors at all, I really like that kind of coloring. O0 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 22, 2013, 11:23:41 AM Nothing wrong with those colors at all, I really like that kind of coloring. O0 :ok: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 22, 2013, 05:25:33 PM Like this? I also like your colors :), but what I wanted to see was if claude's error function, with all the square roots and use of the complex datatype instead of treating the imaginary and real parts separately, would give any structure in the big one-iteration-count blob at right... :)Can be done with one good reference point. (Excuse the horrible colours. They show detail at least.) Anyway, where did you put that one reference, is it inside one of the dense round formations just right of the center of the image? I can also get a decent image if I put one reference there, but the image will still not be correctly rendered. The reindeer-horn shaped glitches do get some structure inside, and I selected colors on the images below to make it more visible, but the structure is simpler than the real structure. It might not be significantly visible on this image but it will be more obvious if you zoom in on one of the reindeer horns. But I am not sure, you may be able to get a correct image with one reference only since I believe you use long double also for this zoom level? Here is how it looks when I render the location with one reference only: (http://biphome.spray.se/karl.runmo/glitch1.jpg) And here with additional references in the reindeer horns: (http://biphome.spray.se/karl.runmo/glitch2.jpg) Close-up on the horn with one refrence (http://biphome.spray.se/karl.runmo/glitch3.jpg) And with additional references (http://biphome.spray.se/karl.runmo/glitch4.jpg) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Nahee_Enterprises on October 23, 2013, 01:46:41 AM .............. But I am not sure, you may be able to get a correct image with one reference only since I believe you use long double also for this zoom level? Here is how it looks when I render the location with one reference only: http://biphome.spray.se/karl.runmo/glitch1.jpg (http://biphome.spray.se/karl.runmo/glitch1.jpg) And here with additional references in the reindeer horns: http://biphome.spray.se/karl.runmo/glitch2.jpg (http://biphome.spray.se/karl.runmo/glitch2.jpg) Close-up on the horn with one refrence http://biphome.spray.se/karl.runmo/glitch3.jpg (http://biphome.spray.se/karl.runmo/glitch3.jpg) And with additional references http://biphome.spray.se/karl.runmo/glitch4.jpg (http://biphome.spray.se/karl.runmo/glitch4.jpg) Until you showed the close-up, it was difficult to discern any real difference between the two images. :D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on October 23, 2013, 10:49:29 AM Anyway, where did you put that one reference, is it inside one of the dense round formations just right of the center of the image? That is the multi million dollar question. :dink:You have to put the reference where the image has the highest iterations. ;D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on October 23, 2013, 04:45:53 PM That is the multi million dollar question. :dink: I just checked this, and found that it is possible to get a correct image of this location with one reference only, if long double is used.You have to put the reference where the image has the highest iterations. ;D Interesting :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: tit_toinou on November 01, 2013, 06:41:01 PM Hi all,
This software sounds amazing but I'm getting that famous "1 024" error and nobody said how to fix it ! I've wandered through the thread and found no info besides that is is a localization error.. Could s-o help me please? Thanks ;D . Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Botond Kósa on November 02, 2013, 03:29:55 PM Hi all, This software sounds amazing but I'm getting that famous "1 024" error and nobody said how to fix it ! I've wandered through the thread and found no info besides that is is a localization error.. Could s-o help me please? Thanks ;D . As a workaround try to set the regional settings to English (United States) in Control Panel. This worked for me on Windows 7 x64. Title: :pray: Post by: hapf on November 02, 2013, 05:58:19 PM Looking at the images one can now create in reasonable time I want to :pray2: sometimes
and :music: Hallelujah! :D Title: Re: :pray: Post by: Kalles Fraktaler on November 02, 2013, 10:43:06 PM Looking at the images one can now create in reasonable time I want to :pray2: sometimes :spgloomy: please show us!and :music: Hallelujah! :D Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on November 03, 2013, 01:10:32 PM Ok, just one. :dance:
(http://imageshack.com/a/img842/5701/qdrs.jpg) http://imageshack.com/a/img842/5701/qdrs.jpg (http://imageshack.com/a/img842/5701/qdrs.jpg) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on November 03, 2013, 05:00:13 PM Cool!
Is it deep? Or is it DEEP? ;) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Wat on November 03, 2013, 10:06:43 PM Read your paper.
I'm not used to some of the notation. What does Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Wat on November 03, 2013, 10:56:24 PM Read your paper. ...it stands for the ignored part of the approximation.I'm not used to some of the notation. What does <Quoted Image Removed> stand for? The approximation works as long as Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on November 04, 2013, 11:22:04 AM Cool! Moderate: 5.982021482E-43Is it deep? Or is it DEEP? ;) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on November 04, 2013, 03:06:41 PM Five Brownie points if you can tell me what goes on in this video:
http://www.youtube.com/watch?v=8wLyTDDdRb0 :dink: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on November 04, 2013, 03:51:23 PM Five Brownie points if you can tell me what goes on in this video: Are you changing the position of the reference point??www,youtube.com/watch?v=8wLyTDDdRb0 :dink: Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on November 04, 2013, 03:56:29 PM Are you changing the position of the reference point?? :nono:Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Botond Kósa on November 04, 2013, 09:41:52 PM :nono: Are you doing the series approximation beyond the point where it produces a distorted image? Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on November 05, 2013, 09:39:48 AM Are you doing the series approximation beyond the point where it produces a distorted image? :yes:(In this example one can skip safely about 400 iterations. The video shows skipping from 390 to 2750 iterations. The lesson to be learned: Skipping degradation happens in jumps and not any distorted picture is obviously distorted at first sight.) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on November 05, 2013, 01:53:12 PM :yes: I should have recognized it. I did a similar image with series approximation all the way(In this example one can skip safely about 400 iterations. The video shows skipping from 390 to 2750 iterations. The lesson to be learned: Skipping degradation happens in jumps and not any distorted picture is obviously distorted at first sight.) http://www.fractalforums.com/images-showcase-(rate-my-fractal)/series-approximation/ I had a hope that it would be possible to have arrays of A,B and C for every iteration and then find the bailout iteration by binary search on these array. But the result is a bunch of large circles, not looking like a Mandelbrot fractal at all. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on November 05, 2013, 04:33:47 PM I should have recognized it. I did a similar image with series approximation all the way That does not work because the error is not continuously going up or down, it jumps around. http://www.fractalforums.com/images-showcase-(rate-my-fractal)/series-approximation/ I had a hope that it would be possible to have arrays of A,B and C for every iteration and then find the bailout iteration by binary search on these array. But the result is a bunch of large circles, not looking like a Mandelbrot fractal at all. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Mircode on November 18, 2013, 11:44:49 PM Hey, guys!
First: Amazing work! I stumbled upon it while looking for some arbitrary precision Mandelbrot implementation in CUDA. It felt like finding happiness while searching for ways to make more money :P Some remarks on this whole issue: It takes some time to read the whole thread, it would be cool if someone with some insight could summarize all the findings so far or maybe even publish them on Wikipedia. I am also interested in the progress of Pauldelbrot's program, are there any updates on that? And I also have some simple feature requests for Kalles Fraktaler 2: - Maybe I am just too stupid but it feels like it is not possible to change the aspect ratio of the image. That would be very useful. - Also, rotation of the rendering and better zoomlevel control would be nice. How about: aspect ratio of the image is determined by the aspect ratio of the window or can be predefined, the mouse-down-point determines the center of the next image, the mouse-up-point determines the the upper right corner of the image (which also defines the rotation angle) I hate people who only demand stuff, so I will try to make a contribution myself by creating a WebGL based player that imports zoom-out pictures from Kalles Fraktaler 2. One will be able to choose between scrolling and auto-zoom. @Kalles Fractaler: It would also be very cool if one was able to export not just rendered color images, but also "raw data" like iteration, estimated distances, ... per pixel. That way the coloring can be done dynamically using WebGL and GLSL shaders which will allow super sexy effects, for instance an emboss effect with the mouse as lightsource. Looking forward to this! Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Pauldelbrot on November 19, 2013, 01:38:25 AM I am also interested in the progress of Pauldelbrot's program, are there any updates on that? Sorry; it's been on the back burner lately. I'll report any future progress... Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: simon.snake on November 21, 2013, 12:25:50 AM Excuse my possibly stupid question but is this method of rendering able to work with other fractal types, burning ship, etc.?
Would be pretty impressive for those other types of fractal. I guess there would be limits, but having had the reasoning why this works fly over my head with a large whoosh, I wouldn't know where to begin. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 10, 2014, 02:46:18 PM How many percentages of iterations can you skip here? :dink:
-1.9998932137214844260699049350864386104439321454783886763742616969527203348379237560E+00 0.0 horizontal size: 4.086827785E-73 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 10, 2014, 04:21:59 PM How many percentages of iterations can you skip here? :dink: 87.5 ;D-1.9998932137214844260699049350864386104439321454783886763742616969527203348379237560E+00 0.0 horizontal size: 4.086827785E-73 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 10, 2014, 04:49:08 PM 87.5 ;D How do you decide?Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 10, 2014, 05:35:56 PM How do you decide? By comparing the series approximation function with the perturbation function for a couple of pixels, I use the corners. If the difference is mor than some 0.01% then it is time to stop.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 10, 2014, 06:00:06 PM By comparing the series approximation function with the perturbation function for a couple of pixels, I use the corners. If the difference is mor than some 0.01% then it is time to stop. I think you are way too restrictive with 0.01%. An error in the iterations of 0.1 % or even 1 % is usually invisible. This region has a very small range for iterations. Using the error relative to the range (which maximises error) and keeping the max error < 1 % one can skip 99.95% of iterations here. :banana:Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 10, 2014, 06:51:47 PM Unfortunately other areas with very low iteration range are very sensitive to error from series approximation.
I am thinking of the "surfing along curved edges" Re: -1.99909583197699652777778166894532 Im: 0.00001369052463107638888599999998 Magnification 1.04857E6 or size=0.0000038147 The big empty area with horizontal stripes gets incorrectly one-colored. I don't know if there is a way to identify the difference. Also your location, if I calculated the magnification correctly, is a shape like a "wasp waist". I you zoom on the top or bottom edge of the waist, the color outside the waist will be incorrect. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 10, 2014, 07:38:58 PM Unfortunately other areas with very low iteration range are very sensitive to error from series approximation. (This is an area that needs no perturbation.) I see no horizontal stripes. I see a vertical mandelbrot set filament and the colours curving around the tip. I'm not using integer iterations, I always use smooth iterations. I can skip 14 iterations if I forceI am thinking of the "surfing along curved edges" Re: -1.99909583197699652777778166894532 Im: 0.00001369052463107638888599999998 Magnification 1.04857E6 or size=0.0000038147 The big empty area with horizontal stripes gets incorrectly one-colored. I don't know if there is a way to identify the difference. the use of perturbation. All looks fine. Quote Also your location, if I calculated the magnification correctly, is a shape like a "wasp waist". I you zoom on the top or bottom edge of the waist, the color outside the waist will be incorrect. It's part of the real axis and shows a cross. Whether I skip 59614 iterations or 0, it looks the same with smooth iterations. With integer iterations it might not work exactly the same. It might also depend on how you colour given the iteration type. As long as the order of iterations is not changed my colouring stays the same. Yours might change with the same order.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 10, 2014, 08:14:16 PM Are you using a bailout value higher than 2?
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 10, 2014, 08:35:17 PM Are you using a bailout value higher than 2? Yes. Otherwise the distance measure/smooth iterations show artifacts when zooming in deeper.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 10, 2014, 08:49:39 PM Yes. Otherwise the distance measure/smooth iterations show artifacts when zooming in deeper. Thank you so much hapf!I have not consider this or tried it. If I allow 1% mismatch I still get a correct image on the edge of the "waist" of your image - which is not a waist but a cross with a high bailout value. And then the approximation allow me to skip 59624 iterations - the same as the lowest iteration number in the image. That allows me to skip 100% :chilli: I need to make a new version of my program soon, and I would like to re-render flora-fantasy some day, which required a lot of manual work because of these approximation glitches. :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 10, 2014, 09:37:09 PM I'm glad it works for you too. It's the first time I had a region where I could skip about the average iterations (e.g. 100%). There are also places where it's close to 0%. :sad1:
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 10, 2014, 09:51:45 PM I'm glad it works for you too. It's the first time I had a region where I could skip about the average iterations (e.g. 100%). There are also places where it's close to 0%. :sad1: Yes, unfortunately it is maybe not so revolutionary after all. For Dinkydau's tick-tock location, which we used to compare different programs, there is no noticeable difference. The big difference is only for special locations. However I am glad that series approximation does not cause any glitches with higher bailout. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Dinkydau on February 10, 2014, 10:21:57 PM So there are certain locations where series approximation works exceptionally well. How to recognize or find those locations? What do those locations have in common? That may be something to consider when making deep zoom videos.
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on February 11, 2014, 12:37:33 AM So there are certain locations where series approximation works exceptionally well. How to recognize or find those locations? What do those locations have in common? That may be something to consider when making deep zoom videos. It works best when the iteration span is as low as possible. And that is close to -2,0i which maybe doesn't hold so much more to discover.But still, pertubation is by itself much faster than full precision calculation. And interesting zooms can be made with parts that are a little invariant where series approximation is effective. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: hapf on February 11, 2014, 11:10:38 AM So there are certain locations where series approximation works exceptionally well. How to recognize or find those locations? What do those locations have in common? That may be something to consider when making deep zoom videos. Usually one can skip about x iterations which x = the period of the dominating minibrot of a region (if it has one). So if one is at a minibrot and starts zooming to a deeper minibrot iterations go up and after some time the deeper minibrot becomes dominant and skipping potential goes up. Depending on what rises more quickly skipping percentage goes up or down. It's usually best somewhere in the middle between minibrots. And best in areas with the lowest iterations and the highest period minibrots dominating them.Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: brainiac94 on March 25, 2014, 11:31:26 PM I'm getting artifacts like this:
(http://i.imgur.com/HE0YdLW.jpg) Any ideas on how it comes to be? Has anyone else had this phenomenon? Real: -1.77141562653553072087638211096855389764771008971382423143211441081145375818115327035845299873625422302265303904903841922021273095269287447408175985526269838947295031635916599490469137541292122865482567107874167461180701571998676515548139388465659838153472711527330567520142099997354944001631463402399841931474822443360672410061864 Imag: 0.006645363434267916540946696811601051901593155560343777682138714815833572760403114894511952396139982392251931854419516 13335713523517468140843796479565414583671584493278254102581063476450373270778498869586037578271439682867120658868499536 591655497514199913518836865293656165549475597542258143298403434036126462408843043696547931425 Size: 1.125E-300 Iterations: 70.000 Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: SeryZone on March 25, 2014, 11:40:24 PM I'm getting artifacts like this: (http://i.imgur.com/HE0YdLW.jpg) Any ideas on how it comes to be? Has anyone else had this phenomenon? Real: -1.77141562653553072087638211096855389764771008971382423143211441081145375818115327035845299873625422302265303904903841922021273095269287447408175985526269838947295031635916599490469137541292122865482567107874167461180701571998676515548139388465659838153472711527330567520142099997354944001631463402399841931474822443360672410061864 Imag: 0.006645363434267916540946696811601051901593155560343777682138714815833572760403114894511952396139982392251931854419516 13335713523517468140843796479565414583671584493278254102581063476450373270778498869586037578271439682867120658868499536 591655497514199913518836865293656165549475597542258143298403434036126462408843043696547931425 Size: 1.125E-300 Iterations: 70.000 Do you try to re-set parameters? On 1e300 I don't see anything. (http://s5.hostingkartinok.com/uploads/images/2014/03/7267226fd73f9800c210e0053eb82e00.png) But... Try MandelMachine, Kalles Fraktaler to rendering images - it gives better result and can solve any perturbation glitches Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: brainiac94 on March 26, 2014, 12:39:30 AM Do you try to re-set parameters? On 1e300 I don't see anything. (http://s5.hostingkartinok.com/uploads/images/2014/03/7267226fd73f9800c210e0053eb82e00.png) But... Try MandelMachine, Kalles Fraktaler to rendering images - it gives better result and can solve any perturbation glitches Thank you, I'll try that! It's definitely persistent - I've rendered this image at various magnifications from 298 to 306 several times (on three different machines too) and it always happens.. It's interesting that you see a satellite though, because I don't.. Is 1e300 in your software the same scale as in SFT? Then again it's unlikely that I gave you satellite parameters by chance.. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: SeryZone on March 26, 2014, 08:18:14 AM Thank you, I'll try that! It's definitely persistent - I've rendered this image at various magnifications from 298 to 306 several times (on three different machines too) and it always happens.. It's interesting that you see a satellite though, because I don't.. Is 1e300 in your software the same scale as in SFT? Then again it's unlikely that I gave you satellite parameters by chance.. Yes, yes, 10^300 is 10^300 at anything software, no doubt))) Please, give me true parameters - you got interesting location =) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: Kalles Fraktaler on March 26, 2014, 01:08:19 PM Yes, yes, 10^300 is 10^300 at anything software, no doubt))) Please, give me true parameters - you got interesting location =) Sometimes, or perhaps whenever the exponent is negative, the magnification is entered as the size of the height or the with of the image.If this size is compared with the non-zoomed view as 4, then it is 4/1.125E-300 = 3.56e300 (use Kalles Kalkylator http://biphome.spray.se/karl.runmo/calc.htm :)) If I use the location parameters and magnification 3.56e300 I end in the Minibrot, this view seems to be around 1e280. Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: 3dickulus on April 09, 2014, 03:53:21 AM I'm getting artifacts like this: (http://i.imgur.com/HE0YdLW.jpg) Any ideas on how it comes to be? Has anyone else had this phenomenon? Real: -1.77141562653553072087638211096855389764771008971382423143211441081145375818115327035845299873625422302265303904903841922021273095269287447408175985526269838947295031635916599490469137541292122865482567107874167461180701571998676515548139388465659838153472711527330567520142099997354944001631463402399841931474822443360672410061864 Imag: 0.006645363434267916540946696811601051901593155560343777682138714815833572760403114894511952396139982392251931854419516 13335713523517468140843796479565414583671584493278254102581063476450373270778498869586037578271439682867120658868499536 591655497514199913518836865293656165549475597542258143298403434036126462408843043696547931425 Size: 1.125E-300 Iterations: 70.000 I've been playing around with SFT engine for a bit and found the same artifacts when zooming through E-1800 to E-1850. I added this bit of code (from "Numerical Recipes in C") to the "Details" class and call it instead of using this equation n = (r*r+i*i) ...use... n = cMag(r,i); Code: /// compute the magnitude of a complex number. It seems to have cleared up the boxy mosaic artifact... (still rendering) prevents overflow in the intermediate steps. The artifact I was seeing was like the image you posted but with more layers, gone now :) Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: quaz0r on October 09, 2014, 01:27:27 AM there is also a complex data type in c++ with associated functions (std::abs() to return the magnitude for instance) if you wanted to eliminate the possibility of error due to off-the-cuff roll-your-own implementation :)
Title: Re: SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Post by: cKleinhuis on August 17, 2016, 11:59:31 PM lol, people, i am not following this thread, but i just wanted to cut it down to a new thread, suddenly realising it is the already cut of thread of the originating thread for the mandelbrot speed up public knowledge gain, so i made it sticky, at some point it will be cutted off again, but just after a major breakthrough (searching smiley db) :stickingouttongue: |