Welcome to Fractal Forums

Fractal Software => Announcements & News => Topic started by: hapf on February 22, 2016, 03:53:39 PM

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 22, 2016, 03:53:39 PM

Quote from: 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.

I'm currently working on a better understanding of skipping limits in general.... In time I might have more to share. :dink:

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 26, 2016, 06:27:27 PM

By the way, how much slower are extended long doubles with separately stored exponent compared to regular long doubles when performing standard iterations and no assembly language coding is used?

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 26, 2016, 10:17:03 PM

Quote from: hapf on February 26, 2016, 06:27:27 PM

By the way, how much slower are extended long doubles with separately stored exponent compared to regular long doubles when performing standard iterations and no assembly language coding is used?

Any programming language and especially ASM is light years faster than Java based.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 27, 2016, 12:51:48 AM

Quote from: stardust4ever on February 26, 2016, 10:17:03 PM

Any programming language and especially ASM is light years faster than Java based.

I'm not talking about Java. Rather something like C or C++.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on February 27, 2016, 03:56:57 AM

long double does not really seem relevant regardless. GPU sorts of devices dont have long double and even CPUs have larger and larger vector units nowadays which also do not do long double so for all intents and purposes long double is a bazillion times slower compared to properly utilizing the resources available on both cpu and gpu :-\

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 27, 2016, 05:21:29 AM

Quote from: quaz0r on February 27, 2016, 03:56:57 AM

Really no current CPU or GPU tech is ideally suited to doing fractal rendering. I'm a pretty hardcore retrogamer and there is much talk of using FPGAs to simulate retro video game systems in realtime hardware where current emulation technology falls short. Kevtris is one of the pioneers of gaming on FPGA cores and he alledgedly produced a realtime Mandelbrot zoomer, although I've never seen it in use and I doubt it goes extremely deep.

Quote

The following systems have been fully emulated, 100% as best as I can tell.
All games available and ROMs were tested and fully work as far as I know.

Sega Master System
Game Gear
Colecovision
NES/Famicom
Atari 2600
Atari 7800
Intellivision
Odyssey^2
Adventure Vision
Supervision
RCA Studio 2
Fairchild Channel F
Videobrain
Arcadia 2001
Creativision
Gameboy
Gameboy Colour (not 100% yet, still debugging. runs 99% of games so far)

(nonvideogame things)
SPC player (SNES music)
Mandelbrot realtime zoom/pan/julia

http://blog.kevtris.org/blogfiles/systems_V105.txt

Maybe someone could use an FPGA to design a Fractal calculation core using say 1024-bit (or larger 2048, 4096, etc...) integer maths or some BS like that, instead of relying on fixed precision 64-bit CPUs. I think Intel will begin including FPGA coprocessors in it's CPUs beginning in 2018. Even if the FPGA core were only one tenth the speed of the main CPU, the 1024 bit or whatever native ALU would be insanely faster than modern 64-bit CPU tech. The FPGA would only be used for raw number crunching and no fancy pants instruction sets, so transistor count could be relatively low. CPU would handle rendering and iteration depth and everything else. Once a usable bignum FPGA core is established, it could be duplicated to add additional multiprocessor "cores" until the FPGA space is full. Because it would only need to handle add+multiply, the cores could be made insanely lean.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on February 27, 2016, 06:22:14 AM

yeah i saw that stuff too about fpgas, emulation, and the guy doing a mandelbrot renderer on it. it is of course always a silly and ridiculous thing any time someone says something like "real time mandelbrot". :snore: and yeah, an fpga/whatever designed with fractal number crunching in mind would be awesome, but it is basically just a fantasy as nobody cares that much about fractals except a handful of us on this forum ;D

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 27, 2016, 07:28:54 AM

Quote from: quaz0r on February 27, 2016, 06:22:14 AM

If FPGA coprocessors became standard equipment in addition to integrated GPU/CPU dies, then cost would drop and people could start to seriously think about designing special interest processors that would never be practical to manufacture. An FPGA can basically clone any piece of silicone logic provided it contains enough gates to do the job.

Yes it is true nobody cares about fractal rendering, but highly specialized appications like cryptography or protein synthesis that require massive amounts of calculations on general purpose CPU could use a "clean slate" ie a custom logic core tailored to it's use. It generally requires Gigahertz level CPUs to emulate with perfect cycle accuracy old Game machines which barely clocked a few megahertz. Bruce Dawson of Fractal Extreme wrote some really good essays on his blog about the benefits of 64-bit CPUs and why arbitrary precision math becomes so slow. Fractal Extreme was lightyears faster than anything else out there before perturbation method (ie render one pixel in arbitrary integer and deduce the rest of the image in float) was discovered.

A custom stripped down 1024-bit CPU core could do a single multiplication where a 64-bit CPU would take hundreds of operations. Even if the hypothetical 1024-bit FPGA core was arbitrarily limited to 100Mhz top speed, it would beat the pants off a 4Ghz Intel i7 core in terms of render efficiency. Assuming the cores were open source and desktop CPUs with FPGA in their dies become common, users could improve on each others' designs. Everything in the software package would be x86-64 code except the arbitrary integer math via FPGA.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 27, 2016, 09:31:55 AM

Quote from: quaz0r on February 27, 2016, 03:56:57 AM

I'm not sure what you are talking about. Long doubles are much slower compared to what doing what exactly? Basic Mandelbrot iterations?

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on February 27, 2016, 10:46:14 AM

compared to the performance of using double with CPU vector units / GPUs

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 27, 2016, 11:38:43 AM

Quote from: quaz0r on February 27, 2016, 10:46:14 AM

compared to the performance of using double with CPU vector units / GPUs

double can not be used for perturbation beyond 10^-308. Quite limiting. So either extended double with separate exponent or extended long double with separate exponent are used. Hence my question. How much slower is the extended version compared to not extended (for example in Kalles program or Mandelmachine)?

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 27, 2016, 01:50:22 PM

Quote from: stardust4ever on February 27, 2016, 07:28:54 AM

A custom stripped down 1024-bit CPU core could do a single multiplication where a 64-bit CPU would take hundreds of operations. Even if the hypothetical 1024-bit FPGA core was arbitrarily limited to 100Mhz top speed, it would beat the pants off a 4Ghz Intel i7 core in terms of render efficiency. Assuming the cores were open source and desktop CPUs with FPGA in their dies become common, users could improve on each others' designs. Everything in the software package would be x86-64 code except the arbitrary integer math via FPGA.

Yes, but that only moves the point where perturbation is needed to higher magnifications. Perturbation and skipping remain very important tools independent of the CPU word length.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 27, 2016, 08:56:49 PM

Quote from: hapf on February 27, 2016, 01:50:22 PM

Yes, but that only moves the point where perturbation is needed to higher magnifications. Perturbation and skipping remain very important tools independent of the CPU word length.

Even with perturbation, it often takes 30+ seconds on my 4.2Ghz AMD rig to calculate the first pixel at arbitrary precision. Sometimes I must wait for a second or third pass because the calculated pixel was off center. When I'm 10^7000 or 8000 zooms deep within the set, that first pixel invokes a considerable wait time, even if the rest of the image is rendered instantly. Going multiple thousands of zooms deep into the rabbithole invokes manually advancing the Mandelbrot three to four zoom levels at a time (8-16x) then waiting for the image to render, and advancing once again. Rendering itself, especially at high resolution, doesn't take hours, days, or weeks like it used to, but getting to the target formation requires long hours of methodical zooming, mostly just clicking into the centroid.

So while the overall process is vastly faster with perturbation, the lead times on calculating that slow as balls first orbit could still be improved significantly by writing custom cores to handle the work load. This would greatly help with exploration and possibly video frame rendering as well. But this will not be possible until FPGA cores become commonplace in desktop processors, and we have programmers knowledgable to utilize them.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on February 27, 2016, 09:28:20 PM

Quote from: stardust4ever on February 27, 2016, 08:56:49 PM

In my experimental mandelbrot-perturbator I cache the series approximation iterations of the centroid, so zooming further in only needs a few more iterations. Calculating it fresh for a brand new view (eg coordinates from a file) or when zooming off-center does take a long time. It's also sometimes possible to zoom directly to the next off-center departure lounge - if you know approximately how deep it will be (eg zoom from 1e-128 to 1e-192 to 1e-288 when julia morphing, the exponent is multiplied by 1.5 each time), and know that the central reference is high enough precision in a minibrot (meaning, it really is central - you can use Newton's method to find it once you know the period, and finding the period of the lowest period minibrot in a region is possible too). An example: http://mathr.co.uk/mandelbrot/2015-06-12_perturbator_deep_zoom_stress_test/ I definitely didn't do the zooming only 16x each frame - that would take insanely heroic amounts of boring manual time and effort!

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 27, 2016, 09:56:30 PM

Quote from: stardust4ever on February 27, 2016, 08:56:49 PM

So while the overall process is vastly faster with perturbation, the lead times on calculating that slow as balls first orbit could still be improved significantly by writing custom cores to handle the work load. This would greatly help with exploration and possibly video frame rendering as well. But this will not be possible until FPGA cores become commonplace in desktop processors, and we have programmers knowledgable to utilize them.

No doubt FPUs with more bits are always better than with fewer bits. We can use all they throw at us. But as Claude explained finding minibrots can basically be done automatically. It would be faster with more bits in the FPU, sure. But it takes not very long even at 10^-5000 and more with today's CPUs.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 27, 2016, 11:00:43 PM

Quote from: claude on February 27, 2016, 09:28:20 PM

I have actually attempted to use automatic zooming feature in say Kalles Fraktaler or other software. The way I do my zoom sequence, I often set up patterns with a large amount of identical objects lined together in a row. I also have what I like to call an even and odd method of building these formations. The even method produces 2^N number of similar objects lined in a row, with the centroid between the said objects, and an odd method consisting of 2^N-1 number of similar objects lined in a row, with a half-object on either side at the extremeties, and the centroid within the centermost object.

It is rather difficult to determine the true centroid of such a formation without first rendering at fairly high resolution and meticulously measuring the distance between outer extremeties, then carefully selecting a point equidistant to those two extremeties, and zooming in from there. I cannot "eyeball" it without holding a ruler to my HD monitor display, and oftentimes the software will mistakenly zoom into a "featured" object near the center when it needs to zoom between two such objects.

I imagine the auto brot finding software works by locating hotspots within the fractal image based on iteration depth, and choosing the location of the hotspot nearest the centroid, when the true centroid may not appear as a hotspot at all. So I have my trademark "X of Xs" formation, and it has been duplicated sixteen times. The software sees this:

XXXXXXXXXXXXXXXX

And the true centroid is located here:

XXXXXXXX·XXXXXXXX

But the software notices the location where the bars of the X intersect appears much hotter, so it instead zooms into one of the X patterns ajacent to the centroid, say here, denoted by capitalization:

xxxxxxxX·xxxxxxxx

And the software continues down the wrong path, until it inevitably intersects the same pattern again, and again takes the wrong path. I come back hours later to find the engine has failed to locate the minibrot, and probably never will. I use some algebra to estimate the location of the target formation, back up to this general area, and sure enough just as I suspected, the software failed to properly identify the cerntroid of a formation.

I haven't played with fractals in a while, but I have found Mandel Machine to be much, much faster than Kalles Fraktaler, and the "locate minibrot" function in KF to be less than perfect in certain situations. Software may have improved somewhat than the last time I played with it; IDK.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 28, 2016, 12:22:49 AM

Quote from: stardust4ever on February 27, 2016, 11:00:43 PM

And the software continues down the wrong path, until it inevitably intersects the same pattern again, and again takes the wrong path. I come back hours later to find the engine has failed to locate the minibrot, and probably never will. I use some algebra to estimate the location of the target formation, back up to this general area, and sure enough just as I suspected, the software failed to properly identify the cerntroid of a formation.

Here is an example location of where the algorithm failed, in my Pterodactyl Canyon Render. I made this in summer of 2014, just realized I failed to ever upload it. Full download available at 3600x2700 resolution on deviantart page.
http://stardust4ever.deviantart.com/art/Pterodactyl-Canyon-593472412
(http://img07.deviantart.net/c47a/i/2016/058/7/b/pterodactyl_canyon_by_stardust4ever-d9tc68s.png)
Kales Fraktaler failed to find the centroid of the image. In the middle bone span where the 7 "X of Xs" formations reside, Kalles Fraktaller selected the point in between the central "X of Xs" formation and the one adjacent to it, failing to locate the true centroid. I forget how far the simulation ran before I killed it. Here are the coordinates. In fact, the exact position where the centriod deviation occurred is preserved in the coordinate data. See attached.

Real= -1.769797003221398115912725130438998327994233694990687460403123213691394762798997343276853841064249384314392735766803307337049665460755808389013248912202462392189032875057823197659362732380873696894875347373595161248407157606303961329755736109322011630746286872455033371782761711152485963814840985495119858112247809563217001440012335481392958891277404641915770292234769570579423526083615869119473397655144269230554048451408287129839729482745812536821304009849356175786421926754317166054095017677737478909629824101459411484678651540446085496579356154087444768864107144068903495747107840142587494964830790373105466387017637804940200093226948331098336564024101191304782846009251093956024054859850114380942506295799272703040122491695848188554900910110348500660088142142935996917999415780413409072318505658318370986389714499389359946017922054389605549307239863818771223517117958828030858448235437369940778504548655809414086286410278094103602829312453365743012069479897322687170061953674357190866700112517607208995688167519085493168568587128984804788006359593471007812934992508284738813218401067186129216920419813413598507086914378451166514659356530201296859316650641129911816376644360695899121978646876258352313348564609725007303215079702633145899631663504174247063662618357201794491755664334581161063251718266469929996804838236903448728496690668143319600874089515125291764268345534981174976291977855698805746925229399729615225109605245345830722655517606147744507997235610446150765888279849316729036292301646101698262415387848655551453813389172582295590171380746790465457505657035692901532708877919123668700059980974391493025
Imag= 0.004503808149118977453591027370762118116191847489651632102771075493630536031121753213019458488948070234821894347490919 75232128719902266967792409275276218671134664739202538733880630147980377066457243173553858784184258065626405478713476529 94375685863015511904074453632654407731289619946868720085884280405841386804671414034982833768121999000401733388984737998 50835523341852444210373993799979274072458522457971439601401283190488219977380751679864657632594486990141780409069050808 53533679083210095437351400022620788443700681865056074859184889623921225508741770547501475133877301147491846294015630493 19594413147950329230917914373568299313895801070552430312839787385413077643433921434686758800882730741386718858427487804 80173527152642383437688144097648231731279522222357988455250353865370120443546331395472996006556618614941953429666058354 64910451202485512530423175907298924572677884684325102852936015719933302605823099958630951988450410491580664701963842251 46135190645341340161891884063141465638742680614101092435645795624718302058131414609501281021540435472453888874524109018 14702121578711328524425442226752168664749086242203613749999027884515745350840633982861734634138141253642303937961493945 45838176191438823739844915158113285022936463789829746280707055929391192625872076997627990447836359937976951672647199177 81872517689037585583899463944250055017306480718807197254236743510423432718914191161718864625412816080818679138546319519 75989748541205329675986737013154577653006827691952880225127567357459621316524513472420563020300861878311519895655738526 548297377841163569759373958805028572872157804020781688771768375820124065
Zoom depth: 2.00000000000E1596

Sorry if this is OT. I haven't logged in in a while and this thread got a bump notification in my email.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on February 28, 2016, 02:41:18 AM

Quote from: hapf on February 27, 2016, 11:38:43 AM

double can not be used for perturbation beyond 10^-308. Quite limiting. So either extended double with separate exponent or extended long double with separate exponent

my only point was that long double is not very relevant in an HPC sort of context, since CPUs can crunch multiple doubles at a time and GPUs dont even have long doubles.

it also seems worth mentioning that there are no hard limits like e308 when using series approximation with perturbation, since the series approximation gets you part of the way there and you dont start iterating from the very beginning. the soonest ive seen double fall off the cliff is maybe e400, and ive seen it hold up for quite a ways e.g. e2000 or so. it depends on the location of course.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 28, 2016, 10:47:00 AM

Quote from: quaz0r on February 28, 2016, 02:41:18 AM

my only point was that long double is not very relevant in an HPC sort of context, since CPUs can crunch multiple doubles at a time and GPUs dont even have long doubles.
it also seems worth mentioning that there are no hard limits like e308 when using series approximation with perturbation, since the series approximation gets you part of the way there and you dont start iterating from the very beginning. the soonest ive seen double fall off the cliff is maybe e400, and ive seen it hold up for quite a ways e.g. e2000 or so. it depends on the location of course.

Interesting. I did not look at this since I use long double anway (why bother with double if you have long double?). Double is certainly attractive when you can use the GPU with it. The moment the deltas become too small long double is better. And once deltas are too small for long double hardware floats with bigger exponents become very useful.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 28, 2016, 11:34:56 AM

Quote from: stardust4ever on February 28, 2016, 12:22:49 AM

Kalle's program uses some kind of pattern matching, I think, trying to find the center of the symmetric structures. If all you want is going in direction of the central minibrot there is a much simpler and more reliable solution. At this location the central minibrot is already dominant, meaning its period is dominating the region entirely (at realistic image sizes) and it's simple to compute the exact location of the minibrot and where it is in the image (see Claude's posting). If the central minibrot is not yet dominant it might be be possible to compute what its period is nonetheless and proceed the same way. If you want to deviate a specific way there are likely again rules how to do it automatically. If the deviation happens at a juncture where the central minibrot becomes dominant there often are multiple regions with different dominant periods in the image and the periods can be computed and their minibrots reached automtically. I have not looked into this but IMHO it is entirely or at least partially possible to do it automatically and reliably.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 28, 2016, 02:10:23 PM

Quote from: hapf on February 28, 2016, 11:34:56 AM

I don't know the details regarding periodicity but generally only points within the set (Minibrots, etc) have periodicty in which the orbit path converges into a stable pattern. Some points along the edge of the set also never escape and never converge into a repeating path. Locations like -1.75 + 0i and 0 + 1i are examples.

Given the immense complexity of the image location here, it is no surprise the software algorithm failed to find the centroid. I forget offhand how many arms this formation has (edit: 8 "Magnum Opus Ex Lite" formations, 8192 individual "X" chromosomes, and 32768 arms - wow) but it is huge. My technique basically find a feature at low zoom level (mini julia), distort it (zoom into the edge of shape), then creates a barbell and later an X pattern. Zoom offcenter to duplicate the X pattern, rinse and repeat.

Zooming off center of a formation produces a new formation twice as complex at roughly 1.5x the zoom depth (and 2x the iterations), rotated about the pint of the original deviation. The exact zoom depth is sometimes less than that if the sub feature zoomed into has high complexity. Also at 1.75x the depth (and 3x the iterations) of the deviation point, the original feature is quadrupled. And obviously, and deviation from the centroid, when zoomed into, will produce a minibrot at twice the depth.

But by repeated deviations at select intervals, the complexity of a formation grows by a factor of 2 every time, one can achieve some truly remarkably complex formations at insane depths. It is not surprising the minibrot finding algorithm can sometimes fail in such instances.

Regarding dominance of the central minibrot, I am not sure how that is calculated, but every sub-feature of said formation has a mini somewhere, albeit at deeper depth compared to the central one. It may well be the exact location at which the central minibrot becomes "dominant" as you say, given it is one of the "fork in the road" points when a new level of complex shape is achieved. I can either continue through the intersection towards the destination (minibrot) or take another detour.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on February 28, 2016, 11:23:49 PM

Quote from: hapf on February 26, 2016, 06:27:27 PM

By the way, how much slower are extended long doubles with separately stored exponent compared to regular long doubles when performing standard iterations and no assembly language coding is used?

Quote from: stardust4ever on February 28, 2016, 12:22:49 AM

I think I have solved that in the latest versions.
Previously the pattern center was searched for using the iteration data, however that can be very chaotic. So I change that to search on the image data (RGB values) which is much better. But indeed, not perfect...

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 28, 2016, 11:56:29 PM

Quote from: Kalles Fraktaler on February 28, 2016, 11:23:49 PM

In Kalles Fraktaler you can force which datatype to use (Actions->Special->Use long double always/Use floatexp always)
I compared stardust's location in depth 1.5E294 (no Auto glitch solving)
* floatexp (a double as mantissa and an integer as exponent) is about 4 times slower than long double.
* long double is about 4 times slower than double.
I think I have solved that in the latest versions.
Previously the pattern center was searched for using the iteration data, however that can be very chaotic. So I change that to search on the image data (RGB values) which is much better. But indeed, not perfect...

So you have no long double mantissa with an int exponent but only double with an int exponent and this is 16 times slower than a regular double?

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 29, 2016, 02:23:05 AM

Quote from: Kalles Fraktaler on February 28, 2016, 11:23:49 PM

I wouldn't sweat it. The date stamp to that file was from June 2014, a year and a half ago so I would imagine the software had been updated since. :tongue1:

I noticed Mandel Machine now has a "find centroid" option, but only zooms 2 at a time and waits for the entire image to render. I typically zoom using tiny rectangles about 5 or so zoom levels at once, and typically I only need to wait for the first orbit to complete to advance unless I'm off center. But i wish it had an "auto" function like Kalles Fraktaler so i could wak away and do other things besides spending hours clicking through thousands of zoom levels at the PC. I typically listen to music to pass the time... :whistle2:

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on February 29, 2016, 09:38:33 AM

Quote from: hapf on February 28, 2016, 11:56:29 PM

So you have no long double mantissa with an int exponent but only double with an int exponent and this is 16 times slower than a regular double?

Yes. And addition/subtraction is slower than multiplication/division since then the exponents needs to be adjusted to each other.

The floatexp data type is also useful when using many terms in series approximation
Because when using for example 5 terms, the last one often go outside the boundaries of double.
However they come often back again and and can go to magnitudes that have influence.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 29, 2016, 10:26:16 AM

Quote from: Kalles Fraktaler on February 29, 2016, 09:38:33 AM

When using long double the extended type's (double or long double) main use is series approximation indeed (normal perturbation iterations
work without extended types and long double to ~10e-4900 and more and that is is most of the time enough).
The slowdown of 16 is for multiplications or additions or a mix of them?

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on February 29, 2016, 10:35:41 AM

Quote from: stardust4ever on February 28, 2016, 02:10:23 PM

Regarding dominance of the central minibrot, I am not sure how that is calculated, but every sub-feature of said formation has a mini somewhere, albeit at deeper depth compared to the central one. It may well be the exact location at which the central minibrot becomes "dominant" as you say, given it is one of the "fork in the road" points when a new level of complex shape is achieved. I can either continue through the intersection towards the destination (minibrot) or take another detour.

In this location the central dominant minibrot has period 418864. Computing the zero crossing of the corresponding polynomial locates the minibrot at

-1.76979700322139811591272513043899832799423369499068746040312321369139476279899734327685384106424938431439273576680330733704966546075580838901324891220246239218903287505782319765936273238087369689487534737359516124840715760630396132975573610932201163074628687245503337178276171115248596381484098549511985811224780956321700144001233548139295889127740464191577029223476957057942352608361586911947339765514426923055404845140828712983972948274581253682130400984935617578642192675431716605409501767773747890962982410145941148467865154044608549657935615408744476886410714406890349574710784014258749496483079037310546638701763780494020009322694833109833656402410119130478284600925109395602405485985011438094250629579927270304012249169584818855490091011034850066008814214293599691799941578041340907231850565831837098638971449938935994601792205438960554930723986381877122351711795882803085844823543736994077850454865580941408628641027809410360282931245336574301206947989732268717006195367435719086670011251760720899568816751908549316856858712898480478800635959347100781293499250828473881321840106718612921692041981341359850708691437845116651465935653020129685931665064112991181637664436069589912197864687625835231334856460972500730321507970263314589963166350417424706366261835720179449175566433458116106325171826646992999680483823690344872849669066814331960087408951512529176426834553498117497629197785569880574692522939972961522510960524534583072265551760614774450799723561044615076588827984931672903629230164610169826241538784865555145381338917258229559017138074679046545750565703569290153270887791912366870238890702486377674493961627842425415072641536223340784982438486048756109238181153075391103742999718461989487988255182749425809658290851105686957800331487046619356847741786931568734133797812990312933679468689355633257241932332586807751783991361005487951858068862626827875513314445086552403572026135269341415265563914895613317095945080129111249617399947471951570374601941026322586575889678534000148411715548247602090863178460885536238487047026969052782268862081294620522011538188275677933094565746782844741895263212598E+00
4.503808149118977453591027370762118116191847489651632102771075493630536031121753213019458488948070234821894347490919752 32128719902266967792409275276218671134664739202538733880630147980377066457243173553858784184258065626405478713476529943 75685863015511904074453632654407731289619946868720085884280405841386804671414034982833768121999000401733388984737998508 35523341852444210373993799979274072458522457971439601401283190488219977380751679864657632594486990141780409069050808535 33679083210095437351400022620788443700681865056074859184889623921225508741770547501475133877301147491846294015630493195 94413147950329230917914373568299313895801070552430312839787385413077643433921434686758800882730741386718858427487804801 73527152642383437688144097648231731279522222357988455250353865370120443546331395472996006556618614941953429666058354649 10451202485512530423175907298924572677884684325102852936015719933302605823099958630951988450410491580664701963842251461 35190645341340161891884063141465638742680614101092435645795624718302058131414609501281021540435472453888874524109018147 02121578711328524425442226752168664749086242203613749999027884515745350840633982861734634138141253642303937961493945458 38176191438823739844915158113285022936463789829746280707055929391192625872076997627990447836359937976951672647199177818 72517689037585583899463944250055017306480718807197254236743510423432718914191161718864625412816080818679138546319519759 89748541205329675986737013154577653006827691952880225127567357459621316524513472420563020300861878311519895655738526548 29737784116356975937395880502857287215780402078167418834602295096014173047038182390355477059048628119343002217338189674 84428900612407421285966391654470156922336601567981570299684787648714514350236588685564191491795576963451396365624203611 89623693814216660262167258794137460777065623334381376669587093792227710384619914833779522355034279775231366236846879929 65077410226071259699613708732240144706025226046260403350230398624904436384826525344982234790191805054228954439652523570 302168603714064304338213704267058855190821114715226120756650420403035424042014899248446596447E-03
2.0E-2105
There is another juncture at 1.7E-1851 .
Now a question for Kalle and other fractal champions: How much can you skip near the minibrot? ;D
A program option suited best for your needs would allow you to click on a pixel where you want to use a minibrot deep down in the neighbourhood of that pixel, locate the minibrot, compute one or more fork locations in between and generate images of the fork locations for you so you can click again on other pixels to deviate from the central minibrot. And so on. Pretty straightforward to implement.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on February 29, 2016, 06:19:35 PM

Quote from: hapf on February 29, 2016, 10:35:41 AM

Now a question for Kalle and other fractal champions: How much can you skip near the minibrot? ;D

Between 2095304 and 2513168 of the minimum 4196216 at 1e2105 depending on the number of terms in approximation.

Quote from: hapf on February 29, 2016, 10:35:41 AM

A program option suited best for your needs would allow you to click on a pixel where you want to use a minibrot deep down in the neighbourhood of that pixel, locate the minibrot, compute one or more fork locations in between and generate images of the fork locations for you so you can click again on other pixels to deviate from the central minibrot. And so on. Pretty straightforward to implement.

That's an interesting suggestion indeed!

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on February 29, 2016, 09:08:54 PM

Quote from: hapf on February 29, 2016, 10:35:41 AM

In this location the central dominant minibrot has period 418864. Computing the zero crossing of the corresponding polynomial locates the minibrot at

<snip>
Now a question for Kalle and other fractal champions: How much can you skip near the minibrot? ;D

A program option suited best for your needs would allow you to click on a pixel where you want to use a minibrot deep down in the neighbourhood of that pixel, locate the minibrot, compute one or more fork locations in between and generate images of the fork locations for you so you can click again on other pixels to deviate from the central minibrot. And so on. Pretty straightforward to implement.

Hey that would be awesome! ;D Did you manually zoom to the center or use computer algorythm to find it? This is exactly what I want. Gone are the days of waiting days or weeks or months [!] for a single image to render, but the main hangup with exploring these formations is the mind-numbing constant zooming into the centroid of features. Everytime I select a fork point, I zoom through the center of every single fork-in-the-road formation I've seen thus far, as well as tons of other junk formations, before arriving at the target. I can always tell when the target is close because the iteration bands become very dense approaching it. Overall this process requires thousands of mouse clicks over may hours even with the speedup associated with perturbation. I have to wait for that first orbit to complete before eyeballing it and zooming into that black circle in the center. If there was a way to automate it, walk away from the PC, software finds minibrot, then backup to the general area where the location exists.

I attempted to join the voyage to minibrot last night using the "locate centriod" option in Mandel Machine. This requires clicking the button or pressing spacebar with each pass, and I fabricated a system to automate this feature. I plugged in a game controller with turbo function into the PC, and used the joytokey app to map a button to the spacebar. Tie the button down with a rubber band to simulate repeated spacebar presses. I watched for a few dozen zoom levels and it appeared to be working. I check it today and to my horror the software has at some point locked onto an infinite spiral where it remained until hitting the zoom limit of 2^-10000. Well it worked for a few hundred zoom levels at least before going into left field. :tongue1:

Another idea I have tossed around in my mind on multiple occasions: once an interesting formation is found at a reasonably deep zoom depth, an inflection point is selected to be zoomed into, at a point approximately 50% deeper and exactly twice the iteration count, the original formation is wrapped twice around the inflection point. Zoom depth is compressed, so that features approaching the inflection point wrap around it twice. I imagined a new zoom movie format using a tubular image of arbitrary length with polar coordinates and log scale on the axis. Essentially a zoom is like travelling through a tube. And after the feature has gone through a periodic doubling, the patterns on the unrolled tube would be exactly the same, just doubled. Which leads me to another point, if all we are doing is creating a more complex formation by duplicating parts of a simpler formation, this image could be extrapolated without zooming thousands of zoom levels down the rabbit hole. Lock on the inflection point about which you want to distort and duplicate the image. Convert the fractal from rectangular to polar coordinates, then duplicate the cylindrical image. Convert back to rectangular and you've got a mapping that looks exactly or very close to what you will find by zooming down the rabbit hole. You've now got a rectangular grid full of pixels that are scattered about within the source formation. Render the actual locations these pixels within the grid and you have a preview of your deep zoom formation without the extra precision of zooming deeper within the set. You could also create patterns that don't exist within the Mandebrot set. For instance you could extrapolate an formation with period three symmetry which do not exist within second order fractals such as the mandelbrot. Simulated periodicity rather than old fashioned very deep zooming could create some interesting results. At the very least, you could at least preview your target formation before deciding if it is worth the effort to zoom there. O0

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 01, 2016, 12:26:56 AM

Quote from: stardust4ever on February 29, 2016, 09:08:54 PM

Hey that would be awesome! ;D Did you manually zoom to the center or use computer algorythm to find it? This is exactly what I want.

I did it automatically since the minibrot was already dominant (e.g. the period is the same for all pixels) so I knew which polynom's zero crossing to compute. Takes some time because the Newton steps must be done at full arbitrary precision.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 01, 2016, 01:04:12 AM

Quote from: hapf on March 01, 2016, 12:26:56 AM

Is there a software app I can use for the 'brot finder? It would save some time for sure.

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: cKleinhuis on March 01, 2016, 01:49:42 AM

people, i would like to split this topic and lock it down, where would you place the cut ?!

Title: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 01, 2016, 01:53:10 AM

Quote from: cKleinhuis on March 01, 2016, 01:49:42 AM

people, i would like to split this topic and lock it down, where would you place the cut ?!

Sorry bout that... :-X

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: cKleinhuis on March 01, 2016, 02:03:23 AM

np, the thing is to keep the original topic intakt whilst enabling an ongoing discussion, overlong topics are of no use for people, since i knew the originating thread was like 2 years old i splittet it at the longest pause between posts, just continue as nothing happened, just some minimal effort cleaning up in the meantime ;)

i just think the originating topic is one more super-epic topic here in the forums, beside of the famous mandelbulb/mandelbox topics where the development of such can be traced, and this pertubation technique - although long existant before we found it, and it has been used before by kais power tools fractal implementation - this thread marks the development of useable and available mega ultra deep zoom mandelbrots possible...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Pauldelbrot on March 01, 2016, 04:45:26 AM

Quote from: hapf on March 01, 2016, 12:26:56 AM

Who needs Newton steps? Once you know the dominant period p just find the pixel for which the pth iterate is of smallest magnitude. The minibrot should be inside that pixel somewhere. The software can auto-zoom to a few-pixels neighborhood of there, then repeat calculating the first p iterates of this new image to find the next zoom target point.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 01, 2016, 04:55:16 AM

Quote from: hapf on February 29, 2016, 10:35:41 AM

Your coordinates worked like a charm! :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 01, 2016, 10:47:12 AM

Quote from: Pauldelbrot on March 01, 2016, 04:45:26 AM

That's an interesting idea, but for the iterations to be fast and use perturbation one needs a reference. Where is the reference coming from? Ad hoc references need full precision iterations as well. And how long can it last when you zoom in repeatedly? If one uses a minibrot we are back to square one. Are you suggesting full precision iterations all the time? If not, what reference should be used?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Pauldelbrot on March 01, 2016, 04:46:38 PM

Quote from: hapf on March 01, 2016, 10:47:12 AM

Compute center of image to full precision to p iterations. Compute rest with perturbation and find minimum of iteration p. Repeat. :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 01, 2016, 05:21:12 PM

Repeatedly rendering zoomed in images to find the minibrot will take linear time, because you get only a constant few more bits of precision each time. Newton's method has quadratic convergence when you get close enough, which means the number of accurate bits doubles each time. One iteration of Newton's method will take around twice the time of calculating the center of the image to p iterations at high precision, let alone calculating the image pixels. So I think Newton's method will be a lot more efficient.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Pauldelbrot on March 01, 2016, 05:39:03 PM

Maybe. It depends how much high precision arithmetic actually is needed, how fast convergence actually is under these circumstances, and the like. I have had very odd and unreliable results trying to use Newton's method for any polynomial of degree much above 45. That would limit its utility to minibrots of low period.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 01, 2016, 08:06:35 PM

Quote from: Pauldelbrot on March 01, 2016, 05:39:03 PM

I use a modified version of Newton regularly for periods in the 10000s and more. Even 100000s work (see above example). Of course large periods can take minutes and more to finish, but it works quite well. From a point one can usually find several minibrots with a period < point's escape iteration number, including the dominant period. Can be less than five, can be dozens, depending on the location. Some periods will quickly or (grumble!) later on fail (due to values going to infinity), others can loop forever, still others converge after many Newton iterations. But usually it takes less than 20 iterations, often less than 10. Adequate bits are necessary or the search fails. Have not had a location yet where no minibrots in the 'hood could be found. One can also go minibrot hunting from a point with a target period >> point's escape iteration by using Newton iteratively and switching horses on the fly as needed, so to speak. It's fun clicking near the tip at -2 and ask for a period 34000 minibrot. ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 01, 2016, 10:51:14 PM

Quote from: hapf on March 01, 2016, 08:06:35 PM

@hapf Glad you've created a solution for finding minis. It seems like I could really use a software algorithm for locating minibrots. Would save a ton of time. Do you have something available with a decent GUI I could use?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 02, 2016, 09:46:05 AM

Quote from: stardust4ever on March 01, 2016, 10:51:14 PM

I'm afraid not. I'm not even on Windows. This functionality would be best added to Kalle's or Botond's program so it's integrated with the rest.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 03, 2016, 11:02:41 AM

Quote from: hapf on March 02, 2016, 09:46:05 AM

I'm afraid not. I'm not even on Windows. This functionality would be best added to Kalle's or Botond's program so it's integrated with the rest.

If this thing could be added sometime, that would be great. Thanks.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 05, 2016, 11:39:01 AM

Quote from: cKleinhuis on March 01, 2016, 02:03:23 AM

this pertubation technique - although long existant before we found it, and it has been used before by kais power tools fractal implementation

I've read this before but I haven't seen any references to it. Is there any?
If not I am sceptic. And did it use series approximation? And without pauldelbrot's glitch solving method it wouldn't be much useable anyway...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 05, 2016, 07:38:46 PM

my impression was that there was just the one initial reference point and no series approximation

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 05, 2016, 10:52:49 PM

Quote from: stardust4ever on March 01, 2016, 04:55:16 AM

Your coordinates worked like a charm! :)

FYI, I posted another image in my Pterodactyl series. Zoomed in the old fashioned way in Mandel Machine to a final depth of 7845 zoom levels deep. That soft-limit of 10000 zooms is getting closer. Sorry if I'm thread crapping.
http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/pterodactyl-vertebrae/msg91074/#msg91074

I just wanted to thank people again for solving the arbitrary precision problem with fractal zooming. At nearly 8000 zoom levels and 1.6 million iterations, each orbit is taking 30+ seconds to compute on my rig. Too bad calculating orbits can only use one CPU thread at a time. Computing high resolution images at this depth using the old Fractal Extreme methods would literally be impossible. Kudos for making this possible... O0

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 06, 2016, 01:41:11 PM

Quote from: stardust4ever on March 05, 2016, 10:52:49 PM

I just wanted to thank people again for solving the arbitrary precision problem with fractal zooming. At nearly 8000 zoom levels and 1.6 million iterations, each orbit is taking 30+ seconds to compute on my rig. Too bad calculating orbits can only use one CPU thread at a time.

Well, one can split every iteration up into real and imaginary part, and iteration and distance, if one uses distance. Because of parallel processing overhead this split into 2 or 4 threads pays only off when the number of bits gets high enough. But it definitely can.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 06, 2016, 04:49:27 PM

Quote from: stardust4ever on March 05, 2016, 10:52:49 PM

Too bad calculating orbits can only use one CPU thread at a time.

Actually it can at be splitted into at least 3 threads, since the 3 squaring operations can be executed in parallel.

Code:

			xin = srsi - sr - si + iref;
			xrn = sr - si + rref;
			xr = xrn;
			xi = xin;
			sr = xr.Square();                // thread 1
			si = xi.Square();                // thread 2
			srsi = (xr + xi).Square();       // thread 3

I've implemented it in KF (when going beyond e600) and discussed this with Botond, however KF is much slower than MM calculating deep references even in mutliple threads, and Botond has not yet implemented it in MM (is he active at all these days?)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 07, 2016, 06:36:17 PM

I wrote a blog post about series approximation, mainly to retract a previous post in which I used symbolic algebra in an overcomplicated way (hi quaz0r!) - maybe it's useful as it has the (possibly well-known) general formulas for the series approximation with arbitrary order (thanks hapf) http://mathr.co.uk/blog/2016-03-06_simpler_series_approximation.html it also contains the observation that high precision isn't so necessary for the series coefficients

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 08, 2016, 08:36:58 AM

Quote from: Kalles Fraktaler on March 06, 2016, 04:49:27 PM

Actually it can at be splitted into at least 3 threads, since the 3 squaring operations can be executed in parallel.

Code:

			xin = srsi - sr - si + iref;
			xrn = sr - si + rref;
			xr = xrn;
			xi = xin;
			sr = xr.Square();                // thread 1
			si = xi.Square();                // thread 2
			srsi = (xr + xi).Square();       // thread 3

I'm not a software engineer, but I understand it's possible for CPU cores to share cache memory. Assuming each squaring operation takes a relatively constant amount of time (and it will if all threads are operating on cores at the same speed, and in the case of Intel Hyperthreading or AMD's Bulldozer architecture, both threads are not on the same core/module), then each thread produces a numerical result somewhere in the processor's cache memory. It is my understanding the way modern CPU architecture works, that lower level L1 cache is devoted to each core (Intel) or module (AMD), and the upper level L2 and L3 caches are accessible to the entire CPU. A forth CPU thread will need to apply the results of each multiplication and perform addition or other functions on it. How many CPU cycles does it require to fetch this information from other areas of the cache? Also I assume that perturbation rendering may take additional penalties because the results of each iteration must be stored somewhere in RAM so that it can be used to calculate the remaining pixels in float or low precision maths based upon the delta between orbits of nearby pixels. I also imagine the performance penalty for fetching each of three product values for summation from adjacent caches would be relatively constant and not increase exponentially as precision increases. Even if running three threads only decreased orbit time by 50%, that would still be a very welcome performance boost.

There are also other performance savings introduced by Fractal Extreme where Bruce Dawson noted that up to 75% of multiplication operations during a square (or half during a multiply) are basically discarded when the end result is computed, because they are either duplicate operations or least significant bits which get truncated from the final product. Further performance increases were gained in Mandel Machine by taking advantage of AVX instruction sets in newer AMD and Intel CPUs.

Overall Mandel Machine has been a God-send for extreme deep zooming. Also a shoutout to Kalles Fraktaler for his addition of my abs() variant fractal definitions, and excellent zoom movie software, even if it is a bit slower at insane deep mandelbrot sets. Now if only someone could implement a fool-proof brot-finding algorithm. The experimental feature in Mandel Machine is still a bit unreliable, although I haven't attempted to use the KF one recently.

Mandel Machine is much faster, even if it only consumes ~13% (one core) of my 8-core CPU while calculating orbits, at least according to Task Manager. Kalles Fraktaler is slower overall and as such I tend not to use it beyond 1e1000 or so for pure Mandelbrot deep zooms. I have noticed Kalles Fraktaler consumes a bit over ~30% or so CPU (between two and three cores) when calculating orbits. I have not done a benchmark recently but need to update Kalles Fraktaler on my desktop anyway.

Quote from: claude on March 07, 2016, 06:36:17 PM

One wierd side effect of exploring formations within Mandel Machine: When I zoom into a feature with extremely high detail (typically the target formation if I'm searching for a new fork point), the render speed slows to a crawl. Prior to the detailed formation and upon passing it, the remaining pixels appear almost instantly if I'm zooming at a medium resolution (800x600 or so), but right when I have the entire target formation in view, rendering of pixels on screen is not instant but takes some time to pass. A few seconds to a minute or so at medium resolution, to a few hours at very large (say 12800x9600 or something big like that) print quality resolution (which I scale down to 3200x2400 pixels or so in GIMP using bilinear filter for clean 4x4 antialias). I for one am not complaining. A gigantic image (12800x12800) at 8000 or so zooms taking five hours to complete is hella faster than a smaller image (3200x3200) at 3132 zooms taking over a month in Fractal Extreme.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 08, 2016, 09:07:12 AM

Quote from: stardust4ever on March 08, 2016, 08:36:58 AM

I'm doing my master images usually at 32K these days for clean versions up to 8K and ok 16K versions. But it really depends on the location. Some are so dense in parts that even 32K will not give an aliasing free 4K version.
Concerning the speed differences at different places on the way down it is expected. In between fork points one can usually skip a lot more safely than at fork points, when embedded Julia sets are popping up or period dominance changes. The amount of corruption removal needed also slows things down considerably at times.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 08, 2016, 10:55:26 AM

Quote from: hapf on March 08, 2016, 09:07:12 AM

With the type of formations I am used to exploring, I will zoom into a feature that I like, say an "X" formation, a spiral, what have you, then I will zoom to a point sideways to the feature. At approximately 50% deeper zoom depth and twice deeper iteration depth, a new, higher complexity feature appears, then rinse and repeat. I get a nice line of similar objects in a row, then zoom off somewhere to further perturb and manipulate the shapes, making snakes out of strait lines, or "X of Xs" etc... As I zoom through the glut of shapes on my way to the next fork point, it regurgitates previous patterns in the series as well as new formations of higher symmetry.

Eventually some several thousands of zoom levels deep, and hundreds of thousands to a few million iteration depth, I have generated a formation with up to 32768 or 65536 unique spiral arms or some other fragment of shape that collectively make up the larger shapes or formations, all at the exact same iteration depth, many of which are so small they do not fully resolve in the image, all contorted into some tightly knit formation. Typically I can tell when such a formation is approaching as the iteration bands become very dense, like close circles instead of sparsely placed shapes.

Suppose at a given very deep zoom depth, the first orbit takes 30 seconds to process, then part of the image renders, then the second orbit takes an additional 30 seconds, more pixels are rendered, and so on. Typically after a few such guesses, the full image resolves. Yet the individual pixels calculated at relatively low precision generally render almost instantaneously on screen when displaying simple features, but groupings of low precision pixels take much longer to render when the highly complex target formation appears.

Again I have no issue with the render times, because it is light-years faster than the old Fractal Extreme methods of rendering every pixel at full precision. I am just curious as to why the actual (low to medium precision) fast generated pixels (not the high precision slow orbits) take longer the more complex the formation. Do these high-complexity formations require higher precision to calculate the values of the pixels? If so how does the software know whether to render them fastly or slowly?

To me, this is the biggest speed boost of Mandel Machine over Kalles Fraktaller. Mandel Machine only renderings the low precision pixels slowly when it hits these complex objects. Kalles Fraktaller seems to render more slowly all the time. That tells me Mandel Machine is doing some heavy optimization during the times I am zooming through towards the centroid and rendering relatively simple shapes.

I also noticed that "glitch" formations I seem to encounter much less frequently in the most recent build of Mandel Machine than past experience dictates. But an option to automatically zoom into the centroid or minibrot locator would be most appreciated so I don't have to click the scroll wheel thousands of times over long hours.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 08, 2016, 11:59:23 AM

I don't know how Mandelmachine works internally in detail. But obviously once more than one reference is needed it takes longer. If there is no skipping with secondary references it takes longer still.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 08, 2016, 01:01:00 PM

Quote from: hapf on March 08, 2016, 11:59:23 AM

I'm not referring to the time taken for reference pixels but the fast pixels rendered based on the slow reference pixel take longer to generate when the image is complex enough.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 08, 2016, 01:13:07 PM

Quote from: stardust4ever on March 08, 2016, 01:01:00 PM

I'm not referring to the time taken for reference pixels but the fast pixels rendered based on the slow reference pixel take longer to generate when the image is complex enough.

With the primary reference and all secondary references? Then the amount of skipping possible must come down. Can you see how much is skipped? Also, when switching from long double to extended double for the iterations the rendering time must go up.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 08, 2016, 01:16:41 PM

Quote from: hapf on March 08, 2016, 01:13:07 PM

But when I zoom through the center of formation and continue, the rendering speeds back up. So the overall complexity of the julia formation must affect the precision level needed to accurately render the meat of the image.

I should try to zoom something truly insane, like 65534 Xs in a row. I've never gone past 256 such features because I couldn't locate the center visually. I sure hope the "find centroid" button works in such scenario... :tongue1:
http://stardust4ever.deviantart.com/art/Making-X-Fractals-155341193

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 08, 2016, 01:28:57 PM

Quote from: stardust4ever on March 08, 2016, 01:16:41 PM

But when I zoom through the center of formation and continue, the rendering speeds back up. So the overall complexity of the julia formation must affect the precision level needed to accurately render the meat of the image.
I should try to zoom something truly insane, like 65534 Xs in a row. I've never gone past 256 such features because I couldn't locate the center visually. I sure hope the "find centroid" button works in such scenario... :tongue1:

The Julia affects the skipping that is safe to do. And the button would work but might take quite some time to deliver. But much less than you manually for sure. ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 08, 2016, 01:40:13 PM

Quote from: hapf on March 08, 2016, 01:28:57 PM

The Julia affects the skipping that is safe to do. And the button would work but might take quite some time to deliver. But much less than you manually for sure. ;D

Thanks, I'll give it a shot sometime. My latest creation, Pterodactyl Graveyard, has 65536 chromosomal arms in it, but not all in a row! ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 08, 2016, 03:42:08 PM

the "fast" low-precision perturbed points take the longest to calculate when you are right on the complex julia formation you were zooming toward, then when youve zoomed past it, they are the fastest they will be between that point and the next complex julia formation, and will gradually get slower until you arrive there, just as youve described, due to how many iterations are being skipped by the series approximation, as hapf was indicating. say you start out skipping 10,000 iterations, with the average iterations for that location being 11,000, then maybe by the time you get to the next julia formation the skipped iterations have slowly increased to 15,000, but the average iteration there is 30,000. the number of iterations the perturbed points require has become much more. then once you zoom past that julia the same pattern of skipped vs average iterations repeats, though the overall number of iterations required still gradually increasing the deeper you go, which could be offset to some degree if you also increase the number of terms in the series approximation as you go, but the return on that seems to be negligible without using a prohibitively large number of terms.

unfortunately what all this means is that the interesting stuff we are after and actually want to render are the slowest spots you could choose to render :'(

oh and these locations also have the highest number of high-precision reference points required to achieve a correct render, so it is the slowest and most demanding in every way..

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 08, 2016, 06:34:06 PM

Where is the "button"?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 08, 2016, 06:46:32 PM

In KF2 after you've implemented it ;)

There should be enough hints in recent forum postings for you to be able to code it up :)

(I'd try myself but you haven't ported KF2 (or at least its build system) to Linux yet ;) ;) )

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 08, 2016, 07:52:27 PM

Quote from: quaz0r on March 08, 2016, 03:42:08 PM

... which could be offset to some degree if you also increase the number of terms in the series approximation as you go, but the return on that seems to be negligible without using a prohibitively large number of terms.

In the typical deep zoom scenario with a central dominant minibrot each doubling of coefficients gives you another reference period of iterations to skip till the iteration range of the image is reached. Whether it pays off depends on the period, image size and iteration range of the image.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 09, 2016, 10:27:47 AM

Quote from: claude on March 08, 2016, 06:46:32 PM

claude, I read your hints but I got stuck on the very first step, to determine the period of the minibrot.
What is "I" in the function m_d_box_period_new?

Code:

box->z[0] = box->c[0] = center + ((-radius) + I * (-radius));

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 09, 2016, 11:55:36 AM

The imaginary unit (square root of -1). It's how to construct complex numbers in C99.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 09, 2016, 12:26:26 PM

Quote from: claude on March 09, 2016, 11:55:36 AM

The imaginary unit (square root of -1). It's how to construct complex numbers in C99.

Code:

box->z[0] = box->c[0] = center + complex<double>(-radius, -radius);

? ;)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 09, 2016, 12:30:24 PM

yep, and similarly for the other corners of the box

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 09, 2016, 09:27:02 PM

Cool, works like a charm!
The period grows brutally, an also the required time, especially when close passing minibrots
Sometimes it fails to get the period but then I just need to do one or two further zooms and it works again. The cause is probably miss-centered guessing point or too close to a minibrot.
I haven't encountered the Newton function to fail yet, as long as I get the period :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 09, 2016, 09:36:44 PM

yay! :D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 09, 2016, 10:05:59 PM

Quote from: Kalles Fraktaler on March 09, 2016, 09:27:02 PM

Cool, works like a charm!

What exactly does the "button" do now? :hrmm:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 09, 2016, 10:52:52 PM

Quote from: hapf on March 09, 2016, 10:05:59 PM

What exactly does the "button" do now? :hrmm:

I'm just familiarizing a little with this function currently.
What should the "button" do?
Jump directly to the minibrot? Or jump to 3/4 depth of the minibrot, where the pattern in view is doubled?
Perhaps let the user choose?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 10, 2016, 12:24:55 AM

Quote from: Kalles Fraktaler on March 09, 2016, 09:27:02 PM

Quote from: Kalles Fraktaler on March 09, 2016, 10:52:52 PM

Kalles, I have a set of coordinates for you to play with. I have just earlier today generated a row of "X" chromosomes consisting of 1024 copies.

Please view my 1024X long formation here in the image gallery for coordinates and download of the Mandel Machine parameter file.
http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/1024x-long/

See also my deviantart page for full view of the formation. I'll admit he image (25600x640) is a bit lengthy with it's 40:1 aspect ratio.
http://stardust4ever.deviantart.com/art/1024X-Long-595637805

I haven't played with Kalles Fraktaller or updated recently but generally I find the "Find Centroid" button in Mandel Machine to be unreliable with the results being little better than human guessing. Zooming into the various points that lie between the little X chromosomes generate a form of binary gray code (if you find a short row of X chromosomes after zooming in a few levels, you have guessed wrong), the patterns therein which allow me to make an educated guess as to how many units sideways I need to move over. After a few tries I usually get it, but the process of trial and error is not quite intuitive. Perhaps you can zoom out of the 1024X formation a bit and test the minibrot finding algorithm.

Take care...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 09:27:11 AM

Quote from: stardust4ever on March 10, 2016, 12:24:55 AM

That's a cool looking place, and pretty easy on the CPUs too. ;D
Can you see how much Mandelmachine skips here? It's a very skippable place.
I have to look into this automatic fork points and other interesting places finding stuff some more, definitely. :yes:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 10, 2016, 09:52:20 AM

Quote from: hapf on March 10, 2016, 09:27:11 AM

Define "skippable" for me. Not sure what you mean. I purposely chose a seed location near the seahorse valley area of the large west minibrot with basic dendrites and low zoom depth, so I could take the XX formations to extreme proportions without excessive zoom depth or iterations.

Each "chromosome" has a pair of Xs embedded in it, although the true centroid is located between the two centermost chromosomes. Generally I find that the majority of the image renders successfully following the first orbit (I zoomed into the centroid about 60 zooms or so beyond the target formation so it is flawlessly centered for the purpose of rendering the image), and the little pairs of Xs within the centers of the larger X formations generally require a second pass to render. These orbits of these areas likely point to a different minibrot somewhere within the set with different periodicity. At normal aspect ratios and preview resolutions, you cannot resolve the individual X components while the entire formation is in view. Once zoomed in, it is impossible to determine visually which shape is the true centroid.

Reason why I posted this formation is because the "find centroid" button typically fails in formations like this where a single object is multi-replicated a gazillion times in a straight line. You may need to zoom out slightly here since the true centroid is located on the central pixel in this image. By knocking the image off center, one can select the "find centroid" tool to let the software attempt to relocate it. If when zooming a few dozens of zoom levels deep between two of the chromosomes, you find a formation consisting of a shorter row of little X formations, you are on the wrong path and guessed wrong, or the "find centroid" function has failed to select the correct path to the minibrot. The true centroid leads only to "X of Xs" formations with 4 or higher symmetry from here on to the Minibrot which should be located close to ~4000 zoom levels. A minibrot finding algorithm that fails on fringe formations such as this one would likely fail again and again because with every wrong turn it will eventually encounter the same tricky formations over and over, and possibly never locate the true minibrot.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 10:24:47 AM

Quote from: stardust4ever on March 10, 2016, 09:52:20 AM

Define "skippable" for me. Not sure what you mean.

One can skip here over 99% of iterations. Very skippable. ;D

Quote

Each "chromosome" has a pair of Xs embedded in it, although the true centroid is located between the two centermost chromosomes. Generally I find that the majority of the image renders successfully following the first orbit (I zoomed into the centroid about 15 zooms or so so it is fairly centered), and the little pairs of Xs within the centers of the larger X formations generally require a second pass to render. These orbits of these areas likely point to a different minibrot somewhere within the set with different periodicity.

The whole region is dominated by the central minibrot of period 82432 so it's trivial to go further in that direction and using this as reference the image can be rendered cleanly without further references according to my program (for the resolution I chose which was < 4K ). Minibrot has size ~5E-1197. There is no problem in such a case if you want to go towards the central minibrot. There is only a problem when the dominant minibrot is further up. Here something based on image features might be useful if you need to go down in the center of the current circular structures. Maybe the period of the upcoming minibrot can be computed from the current position before it's dominant. There must be some rules...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 10, 2016, 10:53:01 AM

Quote from: hapf on March 10, 2016, 10:24:47 AM

One can skip here over 99% of iterations. Very skippable. ;DThe whole region is dominated by the central minibrot of period 82432 so it's trivial to go further in that direction and using this as reference the image can be rendered cleanly without further references according to my program (for the resolution I chose which was < 4K ). Minibrot has size ~5E-1197. There is no problem in such a case if you want to go towards the central minibrot. There is only a problem when the dominant minibrot is further up. Here something based on image features might be useful if you need to go down in the center of the current circular structures. Maybe the period of the upcoming minibrot can be computed from the current position before it's dominant. There must be some rules...

How does one determine "dominance"? I imagine it's something totally different from iteration bailout or the general shapes or complexity of Mandelbrot features which we find so interesting. :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 11:34:50 AM

Quote from: stardust4ever on March 10, 2016, 10:53:01 AM

How does one determine "dominance"? I imagine it's something totally different from iteration bailout or the general shapes or complexity of Mandelbrot features which we find so interesting. :dink:

Each pixel has a "period" like the big cardioid and its bulbs and all the copies/minibrots with their bulbs and cardioids have. It is the iteration number at which the iterated value has its lowest absolute value. If all the pixels in the image have the same "period" as the cardioid of a minibrot in the region this minibrot is dominant in that image/region. The pixels either have the period of a dominant minibrot further down or further up or they have different periods because several (mini)brots have their own regions of dominance in the image. There can be thousands and thousands such as in some spirals spiraling towards a Misiurewicz point.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 10, 2016, 11:53:07 AM

Skippable due to Series Approximation I assume?

I loaded the location in KF in 640x360:
Max-iteration: 165163
Min-iteration: 163292
With 10 terms 154561 iteration can be skipped (94.7%), image rendered in 37 seconds
With 20 terms 159713 iteration can be skipped (97.8%), image rendered in 19 seconds
With 40 terms 162289 iteration can be skipped (99.4%), image rendered in 14 seconds
Using 100 terms unfortunately gives incorrect result and only gives a small number of additional skipped iterations.

Next doubling of "chromosomes" is this location, following your method and going just left of the leftmost chromosome:

Code:

re:-1.76973927107570278411520061419065946542347799372595152472101192040064094711336613121195702934273509531110920827719735988557827595999806330371323751859876701146210458806064544177069996999828391655185561042469808511402300223535883114455472484511423365855441119164893414414188906330197301018546484636691096364711626721208178249174072183033484198989852428081400589644144574714652215363016893192108533799955241566248299427809467589643090726924845245039740319491540054239489718441137692571568233952550429974345579671201229362878862729943368276039880766440708454565350593901104555321239593383546867095019659471571166180242494183400421258098231638606655519421918832801505565036377462175161679479913432266064848634617218812509508674693057633239911906027116361934291810218686634514232406561410364816866722072165101789409275784262461387890519359482022010390695157846380903429796008812574713407054196678588644723528860910520590905196670451139094295823495172577538778175845923533617587491427006033016602930900278404641562369796189524200550352924161304993887520131641880565034516078770708206943090725951473272863101719316646550470305393493596164656491513320724401548205844175371960034916997591335500423936357608167240915110205662919250126158696276192747025878258149810015608721712554623391357094690983844241174709909015252279070297968544176041518336849095481262345439207029158860533966756384084999639478493365075861692547428353717288319345008285956733788737950087166990901738963854816259215373861305911053377248373347327533386764341081400371266836934831405817979283935531422790742412459811321804473839844435089769762155990155250178014931357778215347716254080455258628723421585799192229526300512890358421750654418464175339338700097626083812582737428156995792247813443649353878917473590509904660167197369608670966587464420205758779389875106
im:0.00479575593386521785056156632204869711543048868866739207812561117523981061072803666759892986917797971367373649618307585237412544802866649204604791951282119532611555692231864126608560335395830677937445526989723059565598206590367891898467394911556358386179234972500593142081869841790362238266553240041814213356337388982751141354993190142472710950391187727081323027505479136452308448064386283517972781015524209855681335788673744269374677859162070197587477940738704947651087173844617863477560652949841356272962069000764292715737566241003234711235604702236267464602650182979303592890434112792457622396987721882609742859931177341818273187666138340519774842720206982492134896277509574980239897474381333076472746958026712349438349815843426360562006556338835568676503377969930912294441203580507236635231202356397041368243232643242096171465697636427613416621899589621369247195520694822931509253743782828991308508271169923822030731210535571166710661634286964536828249166255244271393901158417890480842237451269264760879763337428453836904776814955516384029161979047340525822848503691702878388529457727649610800474540097130947938914768777069390653907386626598219197537707103472852773928487954022576173090300830083242555816576865669179621054197697073306371497138708514154639978238654075859456762116645947307361805048300920909051144054863714541677404962777535046378220013445059535852715247670869344676733074159242947217492726089180421013247557742926237274643330802114405643723680982693493678065080321054992095840747165747342651598907576468756405957676973239464394898303249003035346570430635955169214125771039539353732135890401126564177895335144578423771521555862079611886138494457318930595157328431568295871786565347458710924343342091618717199655736488581664771241781759853956839288876770557346040681486625539604836220182498710582505322335248
zooms: 4478
zoom: 1.05E1348
size: 3.815E-1348

Iterations from 327205 of which 324577 (99.2%) can be skipped with 40 terms (1m11sec in KF)
Location parameters calculated with claude's methods in 55 minutes
Period of minibrot: 164864
Netwon-Rhapson iterations needed: 8
Zooms of minibrot: 5986.7

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 10, 2016, 11:59:46 AM

Quote from: hapf on March 10, 2016, 11:34:50 AM

Ah yes, that would explain why the middle sections of the "X" chromosomes do not resolve in the initial seed orbit, even if they have a lower bailout than the first seed value. I consider it good practice to zoom into the centroid at least a dozen or so zoom levels before backing out to the target formation. This ensures the seed pixel will have higher bailout than the rest of the image in most cases. Then I framing it by setting the exact zoom depth, aspect ratio, rotation, and color cycling. Then I save the fractal, increase the image resolution to high quality / large size, sit back and render, then save again the fractal iteration data plus the PNG output.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 12:13:11 PM

Quote from: Kalles Fraktaler on March 10, 2016, 11:53:07 AM

Skippable due to Series Approximation I assume?

Yes.

Quote

I loaded the location in KF in 640x360:
Max-iteration: 165163
Min-iteration: 163292
With 10 terms 154561 iteration can be skipped (94.7%), image rendered in 37 seconds
With 20 terms 159713 iteration can be skipped (97.8%), image rendered in 19 seconds
With 40 terms 162289 iteration can be skipped (99.4%), image rendered in 14 seconds
Using 100 terms unfortunately gives incorrect result and only gives a small number of additional skipped iterations.

100 terms give incorrect results? Then you try to skip too much. You can't skip much more since you have exhausted the period rule. :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 10, 2016, 01:15:42 PM

Quote from: Kalles Fraktaler on March 10, 2016, 11:53:07 AM

Code:

re:-1.76973927107570278411520061419065946542347799372595152472101192040064094711336613121195702934273509531110920827719735988557827595999806330371323751859876701146210458806064544177069996999828391655185561042469808511402300223535883114455472484511423365855441119164893414414188906330197301018546484636691096364711626721208178249174072183033484198989852428081400589644144574714652215363016893192108533799955241566248299427809467589643090726924845245039740319491540054239489718441137692571568233952550429974345579671201229362878862729943368276039880766440708454565350593901104555321239593383546867095019659471571166180242494183400421258098231638606655519421918832801505565036377462175161679479913432266064848634617218812509508674693057633239911906027116361934291810218686634514232406561410364816866722072165101789409275784262461387890519359482022010390695157846380903429796008812574713407054196678588644723528860910520590905196670451139094295823495172577538778175845923533617587491427006033016602930900278404641562369796189524200550352924161304993887520131641880565034516078770708206943090725951473272863101719316646550470305393493596164656491513320724401548205844175371960034916997591335500423936357608167240915110205662919250126158696276192747025878258149810015608721712554623391357094690983844241174709909015252279070297968544176041518336849095481262345439207029158860533966756384084999639478493365075861692547428353717288319345008285956733788737950087166990901738963854816259215373861305911053377248373347327533386764341081400371266836934831405817979283935531422790742412459811321804473839844435089769762155990155250178014931357778215347716254080455258628723421585799192229526300512890358421750654418464175339338700097626083812582737428156995792247813443649353878917473590509904660167197369608670966587464420205758779389875106
im:0.00479575593386521785056156632204869711543048868866739207812561117523981061072803666759892986917797971367373649618307585237412544802866649204604791951282119532611555692231864126608560335395830677937445526989723059565598206590367891898467394911556358386179234972500593142081869841790362238266553240041814213356337388982751141354993190142472710950391187727081323027505479136452308448064386283517972781015524209855681335788673744269374677859162070197587477940738704947651087173844617863477560652949841356272962069000764292715737566241003234711235604702236267464602650182979303592890434112792457622396987721882609742859931177341818273187666138340519774842720206982492134896277509574980239897474381333076472746958026712349438349815843426360562006556338835568676503377969930912294441203580507236635231202356397041368243232643242096171465697636427613416621899589621369247195520694822931509253743782828991308508271169923822030731210535571166710661634286964536828249166255244271393901158417890480842237451269264760879763337428453836904776814955516384029161979047340525822848503691702878388529457727649610800474540097130947938914768777069390653907386626598219197537707103472852773928487954022576173090300830083242555816576865669179621054197697073306371497138708514154639978238654075859456762116645947307361805048300920909051144054863714541677404962777535046378220013445059535852715247670869344676733074159242947217492726089180421013247557742926237274643330802114405643723680982693493678065080321054992095840747165747342651598907576468756405957676973239464394898303249003035346570430635955169214125771039539353732135890401126564177895335144578423771521555862079611886138494457318930595157328431568295871786565347458710924343342091618717199655736488581664771241781759853956839288876770557346040681486625539604836220182498710582505322335248
zooms: 4478
zoom: 1.05E1348
size: 3.815E-1348

:cantor_dance:
:thumbsup1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 02:25:05 PM

Quote from: Kalles Fraktaler on March 10, 2016, 11:53:07 AM

Next doubling of "chromosomes" is this location, following your method and going just left of the leftmost chromosome:
...
Location parameters calculated with claude's methods in 55 minutes
Period of minibrot: 164864
Netwon-Rhapson iterations needed: 8
Zooms of minibrot: 5986.7

What exactly did you do? You go left of the leftmost chromosome and then what?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 02:41:44 PM

Quote from: stardust4ever on March 10, 2016, 11:59:46 AM

Ah yes, that would explain why the middle sections of the "X" chromosomes do not resolve in the initial seed orbit, even if they have a lower bailout than the first seed value.

How so? And if you use the minibrot as reference they should work like the rest for some time zooming further in.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 10, 2016, 02:42:07 PM

Quote from: hapf on March 10, 2016, 02:25:05 PM

What exactly did you do? You go left of the leftmost chromosome and then what?

Then I followed the magic that claude described here
http://www.fractalforums.com/index.php?topic=18289.msg90972#msg90972

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 10, 2016, 03:22:44 PM

Quote from: Kalles Fraktaler on March 10, 2016, 02:42:07 PM

Then I followed the magic that claude described here
http://www.fractalforums.com/index.php?topic=18289.msg90972#msg90972

Ah, I did not see that posting before. Looks promising.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 09:42:11 AM

Quote from: Kalles Fraktaler on March 10, 2016, 11:53:07 AM

Next doubling of "chromosomes" is this location, following your method and going just left of the leftmost chromosome:
Location parameters calculated with claude's methods in 55 minutes
Period of minibrot: 164864
Netwon-Rhapson iterations needed: 8
Zooms of minibrot: 5986.7

So you ran the polygon algorithm left of the leftmost chromosome and after 55 minutes it spat out period
164864?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 11, 2016, 10:53:33 AM

Quote from: hapf on March 10, 2016, 02:25:05 PM

What exactly did you do? You go left of the leftmost chromosome and then what?

Zoom between the outside arms of the outermost chromosome. More specifically, there are seven sideways facing dendrites along the edge of each chromosomal arm counting from center to outer edge. To continue the pattern such that all chromosomes are equidistant to each other, zoom into the diamond-shaped julia midway between the endpoints of the third dendrites on the outer arms of the outer chromosome. There are several of these shapes one could zoom into but the distance from the center of the chromosome will determine the exact spacing between the center two chromosomes in the next target formation.

It's easier to take a screengrab but I'm away from the PC right now and don't feel like booting it as it is late.

EDIT: I appear to have misinterpreted the post. Hapf was referring to the automated process by which one finds the central minibrot (which also reveal the location of the next formation without manual progression)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 11, 2016, 11:47:19 AM

Quote from: hapf on March 11, 2016, 09:42:11 AM

So you ran the polygon algorithm left of the leftmost chromosome and after 55 minutes it spat out period
164864?

If so, I could really use this tool.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 11, 2016, 12:33:08 PM

Quote from: hapf on March 11, 2016, 09:42:11 AM

So you ran the polygon algorithm left of the leftmost chromosome and after 55 minutes it spat out period
164864?

Finding the period is just the first step of 3 steps, which in all took 55 minutes.
But it is fascinating that the period got exactly twice of the value that you calculated for the 1024 image :o

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 11, 2016, 12:51:14 PM

Quote from: Kalles Fraktaler on March 11, 2016, 12:33:08 PM

Finding the period is just the first step of 3 steps, which in all took 55 minutes.
But it is fascinating that the period got exactly twice of the value that you calculated for the 1024 image :o

Not too surprising though. Each "feature" in the progression has twice the complexity of the last. The 1024 X formation has 4096 arms, and the 2048X formation will have 8192 arms. Each arm also has a specific number of dendrites coming off it. The length of said arms, and period of the spirals therin are determined early on in the zoom sequence.

In fact, your period number, 164864, is divisible by 1024 x 161. And 161 = 7 x 23. No coincidence each "arm" have 7 segments. So I will postulize that if you zoomed all the way out to the original little "X" formation I zoomed sideways from, the period of said minibrot contained within would be 161. Or perhaps the 161 refers to the minibrot that lies in the center of the initial 2X formation. Every chromosome in the series has a pair of little chromosomes inside it.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 11, 2016, 12:57:09 PM

Quote from: stardust4ever on March 11, 2016, 12:51:14 PM

You don't need to write "will have" since the parameters I gave is indeed the 2048X image :)
You can try it in Mandel Machine. It renders in 640x360 in 5.5 seconds... (13 times faster than KF for that location)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 11, 2016, 01:41:24 PM

I added some info to my previous post. 164864 = 1024 x 23 x 7. Zoom way out, and I suspect the mini within the initial 2X formation might have a period of 161. How do I check for periodicity in Kalles Fraktaler?

Quote from: stardust4ever on March 11, 2016, 12:51:14 PM

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 11, 2016, 02:27:36 PM

Quote from: stardust4ever on March 11, 2016, 01:41:24 PM

Yep, the first 2X formation is located at 1.91E18 and has a period of 161, just as you predicted :)
I have already made a new version with the Newton-Raphson method, just haven't announced it yet

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 03:02:48 PM

Quote from: Kalles Fraktaler on March 11, 2016, 02:27:36 PM

Yep, the first 2X formation is located at 1.91E18 and has a period of 161, just as you predicted :)

The keys to the kingdom are the periods... :yes:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 11, 2016, 03:07:58 PM

Quote from: hapf on March 11, 2016, 03:02:48 PM

The keys to the kingdom are the periods... :yes:

Was gonna insert joke about my fiance holding the keys; decided it would be best not to. :gum:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 11, 2016, 03:54:24 PM

Quote from: stardust4ever on March 11, 2016, 03:07:58 PM

Was gonna insert joke about my fiance holding the keys; decided it would be best not to. :gum:

We don't know about such things. We only know about fractals :embarrass: :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 04:36:42 PM

Quote from: stardust4ever on March 11, 2016, 10:53:33 AM

Zoom between the outside arms of the outermost chromosome. More specifically, there are seven sideways facing dendrites along the edge of each chromosomal arm counting from center to outer edge. To continue the pattern such that all chromosomes are equidistant to each other, zoom into the diamond-shaped julia midway between the endpoints of the third dendrites on the outer arms of the outer chromosome. There are several of these shapes one could zoom into but the distance from the center of the chromosome will determine the exact spacing between the center two chromosomes in the next target formation.
It's easier to take a screengrab but I'm away from the PC right now and don't feel like booting it as it is late.
EDIT: I appear to have misinterpreted the post. Hapf was referring to the automated process by which one finds the central minibrot (which also reveal the location of the next formation without manual progression)

So you are only interested in one of the minibrots with period 164864 and not the others?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 11, 2016, 05:57:42 PM

Quote from: hapf on March 11, 2016, 04:36:42 PM

So you are only interested in one of the minibrots with period 164864 and not the others?

No, I am interested in using your minibrotlocator algorithm to explore features of the mandelbrot set without spending hours manually scrolling through thousands of zoom levels to reach them. It's like setting the fractal explorer on auto-pilot and walking away while your PC crunches the numbers.

I published the extreme aspect feature I purposely dug up because lining up multiple objects in a row tends to break many existing centroid locator algorithms. Your period checking algorithm appears to be much more accurate in that it relies on calculating periodicity rather than using patterns within the iteration bands to guide the centroid. Not only does this method appear faster, but not prone to errors like pattern matching of iteration bands.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 06:17:15 PM

Quote from: Kalles Fraktaler on March 10, 2016, 02:42:07 PM

Then I followed the magic that claude described here
http://www.fractalforums.com/index.php?topic=18289.msg90972#msg90972

Ok. The polygon approach has found you the lowest (?) period there it seems. The one stardust4ever was after and which seems to be central.
There are infinitely many minibrots in that polygon. If you don't abort once you found one some others are also reported?
(164867, 164870, 164876, 164882...) The whole thing should not take 55 minutes, though. You seem to have a bottleneck somewhere.
Finding period 164864 and computing the location is a matter of minutes at most.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 06:27:09 PM

Quote from: stardust4ever on March 11, 2016, 05:57:42 PM

I asked because there are tons of period 164864 in that location. My algorithm uses Newton, period identification of pixels (simple search for minimal iteration value) and nothing else. So Kalle has all he needs to give you what your heart desires. :music:
If you are after high periods from the top level it's not so easy to find something specific like period x in one go automatically. But in principle it's
doable.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 11, 2016, 07:42:27 PM

Quote from: hapf on March 11, 2016, 06:17:15 PM

Ok. The polygon approach has found you the lowest (?) period there it seems. ... If you don't abort once you found one some others are also reported?

It finds the lowest period only, continuing thereafter doesn't work because the box gets folded (wrapped by z^2) in half by the next iteration. See also the second-to-last paragraph of http://www.mrob.com/pub/muency/synchronousorbitalgorithm.html

EDITED to add: note that this works even in the case where there are no pixels with the dominant period (because the dominant region is too small and falls between pixels), so it can be used from way outside the embedded julia set, see fior examples the images here http://www.mrob.com/pub/muency/secondorderembeddedjuliase.html

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 11, 2016, 08:15:27 PM

Quote from: hapf on March 11, 2016, 06:17:15 PM

Finding the minibrot of period 82432 in the center takes "only" some 20 minutes.
But the time grows exponentially, more precision is required and period is equal to the number of iterations made.
55 minutes was to find the minibrot on the left of the leftmost X formation, with double period of 164864.
I estimate next doubling, i.e. the 4096X image of period 329728, to take about 5 hours.
I'll make a test-run of this tonight :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 08:31:39 PM

Quote from: Kalles Fraktaler on March 11, 2016, 08:15:27 PM

I find such periods as 164864 in less than 2 minutes. What arbitrary precision library are you using?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 08:40:37 PM

Quote from: claude on March 11, 2016, 07:42:27 PM

EDITED to add: note that this works even in the case where there are no pixels with the dominant period (because the dominant region is too small and falls between pixels), so it can be used from way outside the embedded julia set, see fior examples the images here http://www.mrob.com/pub/muency/secondorderembeddedjuliase.html

Yes, that seems the main advantage.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 11, 2016, 08:45:38 PM

Quote from: hapf on March 11, 2016, 08:31:39 PM

I find such periods as 164864 in less than 2 minutes. What arbitrary precision library are you using?

Does that also include the newton-raphson iterations to find the exact location parameters, and the size of the minibrot?
For this, that requires high precision division, I use http://speleotrove.com/decimal/decnumber.html

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 11, 2016, 09:15:16 PM

Quote from: Kalles Fraktaler on March 11, 2016, 08:45:38 PM

I'm not familiar with that library. I use mpfr. Of course Newton is included. That is the main expense. The size I do
a different way, but it's a small factor in the running time.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 12, 2016, 01:32:41 AM

Quote from: Kalles Fraktaler on March 11, 2016, 08:15:27 PM

Please do share the coordinates when you find it. This is awesome! O0

EDIT: I did a 25600x640 4x4 AA render of the 2048X formation in Mandel Machine. O0
http://sta.sh/028ljqxi5xf3

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 12, 2016, 09:21:11 AM

So my Newton-Raphson is 10 times slower than hapf's. (20min vs 2min)
Might be that decNumber is slower than mpfr, but probably not 10 times slower.
I have also wrapped decNumber in a C++ class CDecNumber to be able to use simple arithmetic expressions, and by doing so I think more temporary variables are used (creation, allocation, initialization). Furhter I am using a class wrapping complex math.
But my code is available for download, this code is in the file newton.cpp.

Attached is the 4096X image :o
The minibrot of 1024X, which was the original wish from stardust4ever, I think hapf can give it to us, in two minutes? ;)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 12, 2016, 09:31:38 AM

Quote from: Kalles Fraktaler on March 12, 2016, 09:21:11 AM

Ooooooo... :o

I'll download it later, thanks! :dink: How long did it take your program to locate the 4096 mini? Perhaps some optimization is in order? I feel almost guilty letting you find stuff while I relax. Beyond the 1024X formation, finding the centroid manually would be dang near impossible, and you must do it repeatedly with each new formation.

EDIT: My cores are burning a new render right now at 38400x640 4x4AA (60:1 aspect ratio, 153600x2560 native). Your sample file was off center so I had to locate centroid. Ironically, you zoomed into the wrong midget causing the center two Xs to be slightly closer together, making the centroid easier to identify, albeit this defect also messed with my OCD complex a bit. I wonder if the period of the 4096X mini will be perfectly divisible by 2048 as a result, or slightly off??? :tongue1:

EDIT2: I attempted to upload my 38400x640 PNG image (26.7Mb) to deviantart. Error, DA does not accept submissions greater than 200 megapixels. But it's only 24.5 megapixels, not 200+ :banginghead:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 12, 2016, 11:56:36 AM

I don't know how long time it took. I just started it and in the morning it was finished by I estimate it took 4-5 hours.
Sorry I missed the exact period (actually I saw that but I wondered if you would notice... And you did ;) )
I should have stored the location where the leftmost x was in focus and examine the resulting period before continue. I'll do that next time
The result was far in the formation so I had to zoom out a bit. Next time I'll zoom out by changing parameters rather than using the mouse, so that it keeps the position of the center

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 12, 2016, 12:22:12 PM

Quote from: Kalles Fraktaler on March 12, 2016, 11:56:36 AM

It's alright man. I counted dendrites everytime to be sure. Amazing that for my original XX Reactor Core and subsequent Magnum Opus Ex, I literally eyeballed the location between the arms every time, and although not perfect, it looked good enough. But my spiral arms in that sequence was much longer so that you could not actually see the interior cells within the chromosomes, meaning counting dendrites would have been more difficult. My first 32X formation on the way to the initial X of Xs formation had a slight gap between the center two chromosomes.

Do you have the period of the central minibrot in the 4096 formation? I'm curious as to how switching between midgets will impact the result. Since you appeared to zoom between the second dendrites rather than the third (and I am completely guessing here), maybe the period will be 2048 * 161 ±1? That would be something... :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 12, 2016, 12:46:19 PM

Quote from: Kalles Fraktaler on March 12, 2016, 09:21:11 AM

Your newton.cpp looks very familiar to me! ;) Looking at the decNumber website it said "optimized for 10s of digits, but works for many more", while MPFR is highly optimized for a wider range of precisions. Also, you probably don't need full precision for b and l in m_d_size(), which might speed it up quite a bit (no need for high precision division here, for example) - I'll try to experiment with this in my code later to see how it works.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 12, 2016, 01:43:40 PM

Quote from: stardust4ever on March 12, 2016, 01:32:41 AM

Please do share the coordinates when you find it. This is awesome! O0

EDIT: I did a 25600x640 4x4 AA render of the 2048X formation in Mandel Machine. O0
http://sta.sh/028ljqxi5xf3

Location of 82432 minibrot
-1.7697392710757027841152006141906594654234779937259515247210119204006409471133661312119570293427350953111092082771973598855782759599980633037132375185987670114621045880606454417706999699982839165518556104246980851140230022353588311445547248451142336585544111916489341441418890633019730101854648463669109636471162672120817824917407218303348419898985242808140058964414457471465221536301689319210853379995524156624829942780946758964309072692484524503974031949154005423948971844113769257156823395255042997434557967120122936287886272994336827603988076644070845456535059390110455532123959338354686709501965947157116618024249418340042125809823163860665551942191883280150556503637746217516167947991343226606484863461721881250950867469305763323991190602711636193429181021868663451423240656141036481686672207216510178940927578426246138789051935948202201039069515784638090342979600881257471340705419667858851219685966190797231145977198268039243169238831169502470679242625047521216680080745102102338697978848434690710623615151918273912523550802047059388477608402978284517054069348844790654147973180174452501518676787305014157012005952675554689866176991833832220619238422806837710687818636075410966006549937218884711696E+00
4.795755933865217850561566322048697115430488688667392078125611175239810610728036667598929869177979713673736496183075852 37412544802866649204604791951282119532611555692231864126608560335395830677937445526989723059565598206590367891898467394 91155635838617923497250059314208186984179036223826655324004181421335633738898275114135499319014247271095039118772708132 30275054791364523084480643862835179727810155242098556813357886737442693746778591620701975874779407387049476510871738446 17863477560652949841356272962069000764292715737566241003234711235604702236267464602650182979303592890434112792457622396 98772188260974285993117734181827318766613834051977484272020698249213489627750957498023989747438133307647274695802671234 94383498158434263605620065563388355686765033779699309122944412035805072366352312023563970413682432326432420961714656976 36427613416621899589621369247195520694822931509253743782829062500391710822844657024864444608408422058560922524446048148 92208734287500540251296138686660257059365390928468879124177736053405984117806338296754892838258823127354280279919545995 57464102604534423229962807181907379443588506315493789312605325008852448399498815461778112569598868130991918320226621576 9426778203932399E-03
4.0E-1197
My size is not exact as I don't use the precise formula (yet). But the image will show the minibrot and not too small.

164864
-1.769739271075702784115200614190659465423477993725951524721011920400640947113366131211957029342735095311109208277197359885578275959998063303713237518598767011462104588060645441770699969998283916551855610424698085114023002235358831144554724845114233658554411191648934144141889063301973010185464846366910963647116267212081782491740721830334841989898524280814005896441445747146522153630168931921085337999552415662482994278094675896430907269248452450397403194915400542394897184411376925715682339525504299743455796712012293628788627299433682760398807664407084545653505939011045553212395933835468670950196594715711661802424941834004212580982316386066555194219188328015055650363774621751616794799134322660648486346172188125095086746930576332399119060271163619342918102186866345142324065614103648168667220721651017894092757842624613878905193594820220103906951578463809034297960088125747134070541966785886447235288609105205909051966704511390942958234951725775387781758459235336175874914270060330166029309002784046415623697961895242005503529241613049938875201316418805650345160787707082069430907259514732728631017193166465504703053934935961646564915133207244015482058441753719600349169975913355004239363576081672409151102056629192501261586962761927470258782581498100156087217125546233913570946909838442411747099090152522790702979685441760415183368490954812623454392070291588605339667563840849996394784933650758616925474283537172883193450082859567337887379500871669909017389638548162592153738613059110533772483733473275333867643410814003712668369348314058179792839355314227907424124598113218044738398444350897697621559901552501780149313577782153477162540804552586287234215857991922295263005128903584217506544184641753393387000976260838125827374281569957922478134436493538789174735905099046601671973696086709665874644202058E+00
4.795755933865217850561566322048697115430488688667392078125611175239810610728036667598929869177979713673736496183075852 37412544802866649204604791951282119532611555692231864126608560335395830677937445526989723059565598206590367891898467394 91155635838617923497250059314208186984179036223826655324004181421335633738898275114135499319014247271095039118772708132 30275054791364523084480643862835179727810155242098556813357886737442693746778591620701975874779407387049476510871738446 17863477560652949841356272962069000764292715737566241003234711235604702236267464602650182979303592890434112792457622396 98772188260974285993117734181827318766613834051977484272020698249213489627750957498023989747438133307647274695802671234 94383498158434263605620065563388355686765033779699309122944412035805072366352312023563970413682432326432420961714656976 36427613416621899589621369247195520694822931509253743782828991308508271169923822030731210535571166710661634286964536828 24916625524427139390115841789048084223745126926476087976333742845383690477681495551638402916197904734052582284850369170 28783885294577276496108004745400971309479389147687770693906539073866265982191975377071034728527739284879540225761730903 00830083242555816576865669179621054197697073306371497138708514154639978238654075859456762116645947307361805048300920909 05114405486371454167740496277753504637822001344505953585271524767086934467673307415924294721749272608918042101324755774 29262372746433308021144056437236809826934936780650803210549920958407471657473426515989075764687564059576769732394643948 98303249003035346570430635955169214125771039539353732135890401126564177895335144578423771521555862079611886138494457318 93059515732843156829587178656534745871092434334209161871719965573648858166477124178175985395683928887677055734604068148 66255396048362201824987106E-03
8.0E-1801

329728
-1.769739271075702784115200614190659465423477993725951524721011920400640947113366131211957029342735095311109208277197359885578275959998063303713237518598767011462104588060645441770699969998283916551855610424698085114023002235358831144554724845114233658554411191648934144141889063301973010185464846366910963647116267212081782491740721830334841989898524280814005896441445747146522153630168931921085337999552415662482994278094675896430907269248452450397403194915400542394897184411376925715682339525504299743455796712012293628788627299433682760398807664407084545653505939011045553212395933835468670950196594715711661802424941834004212580982316386066555194219188328015055650363774621751616794799134322660648486346172188125095086746930576332399119060271163619342918102186866345142324065614103648168667220721651017894092757842624613878905193594820220103906951578463809034297960088125747134070541966785886447235288609105205909051966704511390942958234951725775387781758459235336175874914270060330166029309002784046415623697961895242005503529241613049938875201316418805650345160787707082069430907259514732728631017193166465504703053934935961646564915133207244015482058441753719600349169975913355004239363576081672409151102056629192501261586962761927470258782581498100156087217125546233913570946909838442411747099090152522790702979685441760415183368490954812623710090511242543608917349145489460218746793257338764367911285022883289062897447549864531670593639618293269919754424328199154461642505051474442950545512129612065538480436754189449243374455402063695195911267548833679802317275576476188543915475031364789399273115233379038627421088649020855711068234548337133910087974623387870195080066953919247961134181399464234373015837145112272610289097131091363912594607674348025596742166815160833789499510195821035859427778879593741772710817354555659829656706186885840812135338916553030076217012227562330543876469277608752973750164067876151245246259233381866230803348292290715834776568338009333475980843926459331892128780025573957692815238898466113022389848052053459522940406362857290067326891576631387464304793863617338320930824299047936065382705961860281865056902721884419223186529234893321540873195951071305612876439032604008291124876981974861633925782863084453524979923319564608387116832010057792691825272273903303402371563704744315198700910908844377944687296050041369717545265216393499672031992190943889616208372772553048963841081795026179698770958421574168437073984204125293513662359529913580852507804462311103835669649604439882040825600879568687357873533973193667508999150210175297730647460519426766598089591461498779912853983510872928739258345215721655413389930269090956885498898449199249910988493703064733865389752445354408708811E+00
4.795755933865217850561566322048697115430488688667392078125611175239810610728036667598929869177979713673736496183075852 37412544802866649204604791951282119532611555692231864126608560335395830677937445526989723059565598206590367891898467394 91155635838617923497250059314208186984179036223826655324004181421335633738898275114135499319014247271095039118772708132 30275054791364523084480643862835179727810155242098556813357886737442693746778591620701975874779407387049476510871738446 17863477560652949841356272962069000764292715737566241003234711235604702236267464602650182979303592890434112792457622396 98772188260974285993117734181827318766613834051977484272020698249213489627750957498023989747438133307647274695802671234 94383498158434263605620065563388355686765033779699309122944412035805072366352312023563970413682432326432420961714656976 36427613416621899589621369247195520694822931509253743782828991308508271169923822030731210535571166710661634286964536828 24916625524427139390115841789048084223745126926476087976333742845383690477681495551638402916197904734052582284850369170 28783885294577276496108004745400971309479389147687770693906539073866265982191975377071034728527739284879540225761730903 00830083242555816576865669179621054197697073306371497138708514154639978238654075859456762116645947307361805048300920909 05114405486371454167740496277753504637216725435211947686690717207242268279427062224063162157529921214604449515145333485 69697163947410860260042883945538333531867769572754496263728994570997655115727544947304655776134821781071432315077788681 93423822555039917522330571396889048290104744980464581866770334921864862190266138471198274482010210168316288917311981835 98293088638858711567120968177302873251999501276374450163902450481515972523418359944973605551138606416972280896996253069 20034682736487389472930049460779570255081356003065703425429406501150693392757174029256410860513000350138657898547495198 60970433307909167319792093324658408940088668436478021343464689378290662880864663036666289243225104846172650503844946615 93822786005863096074096988012554285208824809751306036128329950587835108205840064550189661056811559904010130757210069506 27190231016944759817240462704955514975031195066427207347197603388970387505837250901691346557551255520037069779877707927 76269792500678216496903521911500152926760572350990813834249475429067175023071726399813724479068890226360989110145376714 36110958254082603126359686713114884125214839162294452032294422326966181126948955205441251450291494114791213610990437840 86682825047148661008899020485879940592842198570843905373549040081151368303374112743502357124213109285192023209397856498 927549535788406353730878501858992074668205181907450423668960254535346712772096404311351455809816966666E-03
7.0E-2710

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 12, 2016, 11:50:18 PM

hapf, how much precision do you use for the 3 steps?
I used double exponent + 20, for example if magnification is 1e100 I used precision 220, since the minibrot you want to find when you are at e100 is found around e200.
I realize this is a big exaggeration when finding the period, and when I tried use something like exponent + 4, I succeeded reducing the time from 1 hour to 10 minutes for finding the 329728th period.
The same applies for finding the minibrot size.
But what about the Newton-Raphson iterations?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 13, 2016, 05:48:47 AM

Quote from: hapf on March 12, 2016, 01:43:40 PM

Location of 82432 minibrot
[...]
My size is not exact as I don't use the precise formula (yet). But the image will show the minibrot and not too small.

164864
[...]
8.0E-1801

329728
[...]

Nice. Thanks for publishing the coordinates. :dink: I've just finished making renders based on the "X of Xs" extension on the 1024X and 2048X patterns. I've come to the conclusion in this situation that less is more. The 1024X^2 pattern is more visually pleasing than the 2048X^2 or the 4096X^2 patterns. Ive just rendered a 4800x4800 sized image of the 1024X^2 formation (each arm has 512 chromosomes for a total 2048) in Mandel Machine with 4x4 Antialias (19200x19200 native). I had two renders going at once but it finished in less than 40 or so. I did not record the render time. Sure beats waiting for months like in the old days... O0

UPDATE: http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/reactor-core-ii-long-extended/msg91254/#msg91254

Quote from: Kalles Fraktaler on March 12, 2016, 11:50:18 PM

That's quite a reduction in time by reducing the precision. The trick is figuring out the lowest precision you can get away with for a given location without borking the image or computation. :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 13, 2016, 03:46:59 PM

Quote from: Kalles Fraktaler on March 12, 2016, 11:50:18 PM

You need the max abs difference of the exponents of involved numbers plus the bits for actual computations (about 64 and more). So for Newton it changes dynamically with the deltas computed. Using more bits than neeeded was likely the main reason you were much slower.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 13, 2016, 04:22:10 PM

Quote from: claude on March 12, 2016, 12:46:19 PM

Also, you probably don't need full precision for b and l in m_d_size(), which might speed it up quite a bit (no need for high precision division here, for example) - I'll try to experiment with this in my code later to see how it works.

Yep, the size algorithm works fine with b and l at 53 bits (so you could use extended double, not sure if double has enough exponent range here for deep minibrots), but z still needs full precision or you get bad results (how bad depends on how insufficient the precision is for the nucleus - can be a factor of a few 10s out, or much worse). Your precision for minibrot looks about right I think, but the box period algorithm can make do with just the precision needed for the current view.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 16, 2016, 11:47:09 PM

Here's a stardust4ever inspired location for your enjoyment. :hungry:

3.589641819829216607382609417707637501320749736599154187388156131262748633869720822102177100684166384145148327222689692 81488472407713155528345630704397417629670141110343170021721243757862646913901724545557060305164312180572254270986148389 59699368414675461998880249824565358234199284816122514292968303287346941310883255068644748074235559844802361435070498424 76526320116940586102672644826449938957783213094447195870362481455087226981524375556463246790978877939104974306759373654 95926868711176329970158813919842855781966304322941328563470672649835624313526503289759397615067366095073366638976613939 91053194884997066273036879409031967424512605175625111404211004144201249692853502015985612267872774541652491754754314221 20442479566766096374590170397985550548732406192212509063291992458610079232291946402423127151934651249247124593283076362 45689208991069282426422419901048427981761053143859632625842877434724756333636907669055033915059410143035962114836789002 1324294424168028670423525633418320025E-01
6.466670689777818471393024431453617731923847636419096970436633765407118059261810323272531697149210641561475145206899728 71390150695198587931606814482611490152723459684882730977059760038778133624338908343616998166488064800949328057501799440 60613108429195582449318242145813771930544484511788530467939993254684631925285391042706019498861457258147124466018368775 41315036835282952490756339100025232304644872081673629835710372300539925650667991602461845152324404502028158770953659501 62059820358633620871598958692529172113978947975464568215722988428558030334721223368913598969236580810803654649883636804 77086764974930105230400256420038951316574886116088454897889563727196824656125261469899519180134721371611896240819622553 32241748593258884044426820533406476454959343547969342125823929289523458306897581652466915315243113920948043450777960395 46530870503869617628545499870873124406583289807206160443088359970121647971308105278105739704155382549737732546138531492 3187346016701118771263346391791002905E-01
2.5E-649

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 17, 2016, 05:17:54 AM

Quote from: hapf on March 16, 2016, 11:47:09 PM

I like your dots! :dink:

In other news, I'm making excellent progress in my KF zoom movie. Unfortunately, I found a couple of glitch frames in my Kalles Fraktaler zoom movie of the 1024X Long location. At the edge of the 512 formation exactly at the halfway mark, part of the image renders incorrectly. :tongue1:

I think I may just upload the rendered AVI files to youtube as is, rather than attempt to correct the glitches. I'm using Fibonacci numbers for the infinite waves but I may chose a slightly less dense set of numbers for the AVI files. Also sadly I got a copystrike on YT for a gameplay video I did, so now I'm limited to 15 minute uploads for the forseeable future, and it will either play back either at ludicrus speed (6 frames per 2x zoom) or I will have to parse it into 2 or 3 separate 15-minute videos. I can splice it into two pieces (>30 minutes) if I do 12 or 13 frames per zoom... :hurt:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: cKleinhuis on March 17, 2016, 08:05:15 AM

hehe, that glitch looks like a sword ;)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 17, 2016, 12:37:56 PM

Quote from: stardust4ever on March 17, 2016, 05:17:54 AM

I like your dots! :dink:

:what:
The glitch looks like overskipping...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 17, 2016, 09:56:35 PM

Quote from: hapf on March 17, 2016, 12:37:56 PM

:what:
The glitch looks like overskipping...

Yep, that is the famous series-approximation-glitch... :embarrass:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 18, 2016, 02:52:12 AM

Quote from: hapf on March 16, 2016, 11:47:09 PM

Here's a stardust4ever inspired location for your enjoyment. :hungry:

Quote from: stardust4ever on March 17, 2016, 05:17:54 AM

I like your dots! :dink:

Quote from: hapf on March 17, 2016, 12:37:56 PM

:what:
The glitch looks like overskipping...

I was referring to the coordinates you posted earlier with the little dot-like patterns .... .... . .... .... The glitch pic was on an unrelated topic in the same post.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 18, 2016, 02:53:33 AM

Quote from: Kalles Fraktaler on March 17, 2016, 09:56:35 PM

Yep, that is the famous series-approximation-glitch... :embarrass:

Yeah. There were two really knarly glitch frames in the "Simply Awesome II" video frames I rendered a while back (I never posted video online). It is a reworking of my first deep Mandelbrot zoom.
http://sta.sh/01aqqf7kg83r
http://sta.sh/017skb4ouloa

That second link is the classic example of a worst case scenario, when you zoom outside of a minibrot and the resulting periodic double results in dense dumbbell like formations. I probably just leave them in there at this point than risk corrupting my frame data trying to fix them. Kalles Fraktaler is not alone as Mandel Machine screws up too on occasion.

PS - You get my PM regarding audio tracks? :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 18, 2016, 11:28:45 AM

Quote from: stardust4ever on March 18, 2016, 02:53:33 AM

When you render these frames without skipping are they correct? I guess so. Is the real reason for the problem known? I think I know what this is about.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 18, 2016, 11:31:24 AM

Quote from: stardust4ever on March 18, 2016, 02:52:12 AM

I was referring to the coordinates you posted earlier with the little dot-like patterns .... .... . .... .... The glitch pic was on an unrelated topic in the same post.

I got that. I saw no "dots" since I did not colour it that way. What structures you see depends a lot on how you colour a fractal.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 18, 2016, 11:46:05 AM

Quote from: hapf on March 18, 2016, 11:28:45 AM

When you render these frames without skipping are they correct? I guess so. Is the real reason for the problem known? I think I know what this is about.

I have found what typically causes glitch frames when doing zoom out videos in Kalles Fraktaler typically occur at fork points, ie the explorer has diverted the path off from the centroid, especially true with dense or complex features. Also as each zoom out frame contans the previous frame within it, only the outer 3/4 of pixels are rendered, so the glitch may be present in only one of the frames resulting in the frame border masking a portion of the glitch. I am currently rendering a zoom movie through the area. I do not know why, but color cycling causes massive slowdown when generating the AVI files.

I have also experienced at times glitches occuring at very deep zoom levels in Mandel Machine, but such glitches can usually be resolved by recentering the image. Sometimes it is fun to save or screengrab these mistakes. Typically they appear as oblong circles. Think deflated beach ball.

Quote from: hapf on March 18, 2016, 11:31:24 AM

I got that. I saw no "dots" since I did not colour it that way. What structures you see depends a lot on how you colour a fractal.

Your "dots" are actually pairs of smaller dots. I did not zoom in for close detail.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 18, 2016, 07:31:02 PM

you guys must have your series approximation set to bail too late? which works out often enough...until it doesnt. i noticed on the mandel machine thread that he mentioned using a single order of magnitude in his check, whereas ive found that 3 prevents these glitches from occurring. i havent encountered these glitches since i started doing it this way, though i havent gone super super deep very often like some of you guys do, so maybe even more vigilance is required than that, im not entirely sure? do any of you guys have this totally figured out for sure? claude maybe? KF and MM must still be too aggressive if they go off the rails still.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on March 18, 2016, 07:52:26 PM

I use something based on Botond's technique, but while it seems to work almost all the time I just came across what looks like a bizarre glitch near the end of a very deep zoom sequence (not to mention the aliased distance estimate moiré patterns being ugly-as).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 19, 2016, 02:42:51 AM

Quote from: claude on March 18, 2016, 07:52:26 PM

Could you maybe tweak the color pallet or cycling? Nearly the entire image is black save for a few dots. Hard to tell what is going on in there...

Here's a classic example of a "deflated beach ball" glitch I found not long ago in Mandel Machine. It is from just before the periodic double of the previously mentioned 1024X coordinates that Kalles Fraktaler posted. I first found this location by manually zooming and this glitch popped up at 3470 zoom levels. I have attached the mmf file (.ZIP). Sometimes a simple readjustment of the window will correct these glitches. They aren't super frequent but do crop up from time to time at very deep zoom levels. However I've yet to find a location that doesn't render properly after zooming into the centroid a few levels and backing up. It's more bothersome when it occurs within a zoom movie. There's supposedly a way to rerender individual KF frames but I don't know how and am too scared of corrupting the zoom out frames.

Edit: I tweaked the location a bit. There is a roughly ring shaped area surrounding the central X formation. Centering the image within this somewhat narrow iteration band will result in glitch formations every time. Subsequent renders of pixels inside the blacked out area generally show up properly. You can clearly see one of the arms of the "X" formation unobscured by the glitch pixel area. Try downloading the ZIP file (contains the MMF parameters) and use the rectangle tool to adjust the center of the image. Hint: you may want to disable super-sampling if it takes too long to render.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 19, 2016, 03:17:18 AM

Quote

I've yet to find a location that doesn't render properly after zooming into the centroid a few levels and backing up.

yeah, that gives you a better initial reference point which would be more resilient to these glitches. a crap reference point like when you go off-center maximizes the potential for these glitches to come through.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 19, 2016, 03:20:00 AM

Quote from: quaz0r on March 19, 2016, 03:17:18 AM

Not sure if you got my full post as I was making edits but there appears to be a donut shaped region with a certain range of iteration values that produces the glitch, every time. Try moving around the reference point. Farther out, the glitch disappears leaving a circular hole, which gets filled in by a centered reference point. Closer in to the target formation and the glitch disappears leaving a hole roughly shaped like the target formation.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 19, 2016, 09:48:27 AM

My feeling is that the first reference is too deep, it has connections to a deep minibrot
To put it more artistic and intuitive :)
If the first reference is put anywhere else it looses the deep connection, and all glitches are detected

Stardust, you can use the "examine zoom sequence" to browse the key frames and correct them if needed

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 19, 2016, 10:45:57 AM

Two remarks:

- How much skipping is safe is not easy to find out without actually computing errors all over the image. One can use methods like Botond's
(all contributions right of coefficient x must be much smaller than left of... but how much much smaller is small enough??)
- The corruption trigger 1/10000 is often safe, but not always! And it's also often too conservative meaning there is no need to switch to
another reference just because this threshold was hit. The pixel might be all fine iterating to the end.

Combine the two and safe error free images in all cases with optimal skipping and minimal references are not trivial at all to get.
:no:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 20, 2016, 02:14:17 AM

it seems this is the last big hurdle that needs to be properly solved for the series approximation / perturbation technique to be considered good to go / non-experimental. so far it seems we've all been more or less silently agreeing to lie to ourselves a bit and pretend that this is basically already good to go, though of course in reality if something only works "maybe" or "some of the time" or "to a certain degree" or "its anybody's guess," it is not in fact good to go. you geniuses need to figure out how to nail this stuff down once and for all :D :dink: :D :-*

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: lycium on March 20, 2016, 05:49:22 AM

Quote from: quaz0r on March 20, 2016, 02:14:17 AM

I 100% agree, and have been following the SFT / perturbation thing since the beginning, spoke with the author of UltraFractal about his investigations of the technique in 2014 at the Fractal Art Symposium... my comment from 2013 (http://www.fractalforums.com/index.php?topic=15559.msg66129#msg66129) still stands:

"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?"

I don't see how trading computer processing power for human effort (looking for glitches) is a winning strategy, or even a sure one - people have missed glitches before, and until there's some kind of proof of correctness (itself more difficult to compute than a reference image with direct iteration) the resulting image quality is dependent on the patience and eyesight of the person doing the rendering.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 20, 2016, 09:11:45 AM

Quote from: quaz0r on March 20, 2016, 02:14:17 AM

I am almost tempted to do something. We know there is a donut shaped zone of iteration data with a guaranteed failure every time when the reference pixel is located within it. If I zoom directly into this "no man's land" immediately outside the target formation, pick an inflection point, and continue the zoom until 50% deeper into the set where the fractal data essentially doubles itself, will the formations on either side of the new centroid be messed up? This will be a fun experiment to try later this week when I have some free time. :evil1:

Quote from: lycium on March 20, 2016, 05:49:22 AM

I don't see how trading computer processing power for human effort (looking for glitches) is a winning strategy, or even a sure one - people have missed glitches before, and until there's some kind of proof of correctness (itself more difficult to compute than a reference image with direct iteration) the resulting image quality is dependent on the patience and eyesight of the person doing the rendering.

I wouldn't say that exactly. Most of the Mandelbrot glitches I have seen are quite glaring. The Mandel Machine glitches often look like "deflated beach balls" and the Kalles Fraktaler glitch frames, when they occur in a movie, are typically the result of a forked path that travels away from the centroid. My objective is to find an image with the reference point focused about the true centroid relative to the rendered pattern, and still glitch out, making the image and the area surrounding it truly unsolvable through series approximation. A zoom path that deliberately forks at a location within the "donut of glitches" seems like a sure fire way to test the system. :evil1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 20, 2016, 09:51:31 AM

Quote from: lycium on March 20, 2016, 05:49:22 AM

There are safe ways to do this. They are simply not as fast as the less safe ways. But still magnitudes faster than the full arbitrary precision version when dealing with deeeep zooms. One should never forget that the perturbation approach unlike series approximation is no approximation but 100% correct like the original iterations. The glitches are due to accumulation of rounding errors, not an approximation in the formula. So there is always the possibility to reduce rounding errors by using more bits for the deltas. While this makes things a lot slower again the bits needed are far less than needed for the original iterations at full precision when zooming very deep. So speedups are still big. And series approximation can be made very safe if one is careful and not too ambitious with the percentage of skipped iterations. The problem there is that we lack a clear theoretical criterion that tells us it's safe till here and not beyond.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 20, 2016, 10:22:09 AM

Quote from: stardust4ever on March 20, 2016, 09:11:45 AM

A zoom path that deliberately forks at a location within the "donut of glitches" seems like a sure fire way to test the system. :evil1:

If you give me such a location I can try to see what is causing this.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 20, 2016, 12:14:35 PM

Quote from: hapf on March 20, 2016, 10:22:09 AM

If you give me such a location I can try to see what is causing this.

I attached a file here as zip because the forum does not allow mmf. Post is here:
http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/120/ (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/120/)

There is a donut-shaped region surrounding the complex formation that glitches when the reference pixel is in said region. I'm going to try to zoom further down the rabbit hole within the glitch region to see if it exacerbates the effect.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 20, 2016, 07:22:18 PM

Quote from: hapf

There are safe ways to do this ... The problem there is that we lack a clear theoretical criterion that tells us it's safe till here and not beyond.

my whole point was exactly this, regarding the series approximation. someone has yet to formulate a proper criterion which ensures the whole thing wont blow up, let alone getting you as far as you can possibly get with it in addition to ensuring its safety. again i would assert that implying it is basically good to go, or making allusions to its theoretical safety, does not equate to real-world correctness. it looks like we all have implementations that have been shown to blow up and produce incorrect results. not good to go.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 20, 2016, 07:57:38 PM

with regard to the approach botond described, checking that each term is smaller by some amount, maybe this amount should be dynamically set based on the zoom depth and/or some other criteria? are any of you already doing something like that? it seems that smaller values work at lower depths, with higher depths indicating larger values?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 20, 2016, 08:44:49 PM

Quote from: stardust4ever on March 20, 2016, 12:14:35 PM

I attached a file here as zip because the forum does not allow mmf. Post is here:
http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/120/ (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/120/)
There is a donut-shaped region surrounding the complex formation that glitches when the reference pixel is in said region. I'm going to try to zoom further down the rabbit hole within the glitch region to see if it exacerbates the effect.

I tried to reproduce the effect with overskipping with references in the region but could not. The errors look different and when skipping more (beyond the minimal iterations in the image) the outer parts become featureless, but the center does not become a donut. So this looks like a bug and not simply overskipping. How much do the programs want to skip here? What is the iteration max of the reference?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 20, 2016, 09:00:34 PM

Quote from: quaz0r on March 20, 2016, 07:57:38 PM

I tested many variants of this and with fewer coefficients it seems to be rather safe when wanting to skip with x coefficients to make sure all contributions from another x coefficients after that individually and together compared to the first x is so small that the absolute exponent difference is >= the negative exponent of the pixel size. But with more and more coefficients (128...) even this had cases that had errors above 1 percent, or 5. The more coefficients the more the contributions are spread over more and more coefficients going up and down in waves. The waves jump from level to level (based on the "keys to the kingdom") but the overall effect is hard to establish when coming closer to the maximum skip possible and many coefficients used. When playing it safe I simply could not get close to the real optimal skipping possible found with actually testing the image at various locations, at least not with many coefficients and all locations I looked at.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 21, 2016, 11:06:07 AM

Quote from: hapf on March 20, 2016, 08:44:49 PM

The "donut" in this instance is not a feature persay but a narrow band of iteration data surrounding the feature that produces glitches when the reference pixel is contained therein. Reference pixels within this donut shaped zone produce glitches using default settings in Mandel Machine v1.3.15.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 21, 2016, 07:46:22 PM

mandel machine might be set too lax in its glitch detection/correction in addition to the overskipping issue

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 22, 2016, 01:33:44 AM

@Kalles Fraktaler: Kalles Fraktaler is failing to find the centroid again. I am using latest version.

Size = 640x360
Zoom = 16

"Find Minibrot" command fails by zooming into the chromosome instead of between them. I have zoomed well into the glitch area of the mmf I posted on previous page. I zoomed up until this "64X" location using Mandel Machine, then decided to automate the process, so entered the coordinates into KF and used your "find minibrot" menu item and it fails. I assume it would repeatedly fail again and again to locate the centroid once it reaches a sufficiently long chromosome formation, and this error would likely repeat ad infinitum.

I wanted to find the periodic double of a known glitch location from within the Mandel Machine file I posted earlier but didn't feel like manually zooming to the approximately 2^-5535 zoom depth this would require. I only want to test the location to see if Mandel Machine barfs on it.
:hurt:

EDIT: I found the position manually. Apparently, this location I searched for doesn't glitch up at all. To view the original "glitch" you must reset the magnification to 3470. :dink:

MMF parameters...

Code:

image.width=1280
image.height=720
image.supersampling=2
position.re=-1.7697392710757027841152006141906594654234779937259515247210119204006409471133661312119570293427350953111092082771973598855782759599980633037132375185987670114621045880606454417706999699982839165518556104246980851140230022353588311445547248451142336585544111916489341441418890633019730101854648463669109636471162672120817824917407218303348419898985242808140058964414457471465221536301689319210853379995524156624829942780946758964309072692484524503974031949154005423948971844113769257156823395255042997434557967120122936287886272994336827603988076644070845456535059390110455532123959338354686709501965947157116618024249418340042125809823163860665551942191883280150556503637746217516167947991343226606484863461721881250950867469305763323991190602711636193429181021868663451423240656141036481686672207216510178940927578426246138789051935948202201039069515784638090342979600881257471340705419667858851219685966190797231145977198268039243169238831169502470679242625047521216680080745102102338697978848434690710623615151918273912523550802047059388477610120227482645505202901268310259531375914654127989863575658517285857298644046776833979372298401170515594247650694236040835088580636725197188883301838633826884891907725215420267621408231407868087863857155606555607233691975269649870535381564546102514139884292840878611927606673694598379606020367361658483137883367223105802511967374846046867768244164444838768374265954854033947228261298148439975283873913669268210784821270043045378977203278631694546469555524912082733758594148241573505499833138090100150440411001854828832965244988
position.im=0.0047957559338652178505615663220486971154304886886673920781256111752398106107280366675989298691779797136737364961830758523741254480286664920460479195128211953261155569223186412660856033539583067793744552698972305956559820659036789189846739491155635838617923497250059314208186984179036223826655324004181421335633738898275114135499319014247271095039118772708132302750547913645230844806438628351797278101552420985568133578867374426937467785916207019758747794073870494765108717384461786347756065294984135627296206900076429271573756624100323471123560470223626746460265018297930359289043411279245762239698772188260974285993117734181827318766613834051977484272020698249213489627750957498023989747438133307647274695802671234943834981584342636056200655633883556867650337796993091229444120358050723663523120235639704136824323264324209617146569763642761341662189958962136924719552069482293150925374378282906250039171082284465702486444460840842205856092252444604814892208734287500540251296138686660257059365390928468879124177736053405984117806338296754892837341507069125502543659126775790197583562065309265743403930782970442835855756964862590861406611214408287544430346102387396417375654652294552820157169020238943731165207653089997593275027403759259891988184570391468326105306257559441098144027014942084582917715350747076407623299327166201532840215419753271633485048688749655561442706732391867989832423455475081605888333753784925707440085445028189173333773877469260631083482242534267212635500091888677779450110195272426094961657170920294279611308694879151344530550580595486867216094
position.magnification=5197.0
position.rotation=90.0
computation.iteration_limit=1000000
rendering.inner_color=000000
rendering.outer_color=dddd00
rendering.transfer_function=1
rendering.color_density=-142.000
rendering.dwell_bands=0
rendering.palette=0.0,85,0,85,0.1,170,0,0,0.2,255,85,0,0.3,255,170,0,0.4,255,255,85,0.5,170,255,170,0.6,85,255,255,0.7,0,170,255,0.8,0,85,255,0.9,0,0,170
rendering.color_offset=501760
rendering.bump_mapping=false
rendering.bm_light_direction=0
rendering.bm_depth=50
rendering.bm_strength=50

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 22, 2016, 03:08:13 AM

The above coordinates at 3470 zooms:

Shown below are Automatic Precision and Float Precision.

All of the other available scaled precision levels selectable within Mandel Machine produce a glitch comparable to either of the two below images, so this exact coordinate is not-correctable without changing the reference point or beefing up the precision somehow. :banginghead:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 22, 2016, 03:19:07 AM

Last one, I promise, pinky swear...

You can have fun deliberately perturbimg the image by forcing the wrong settings!

X of Xs (automatic) vs X of Xs (floating point) :gum:

"Fun With Glitches.mmf"

Code:

image.width=1600
image.height=1600
image.supersampling=2
position.re=-1.7697392710757027841152006141906594654234779937259515247210119204006409471133661312119570293427350953111092082771973598855782759599980633037132375185987670114621045880606454417706999699982839165518556104246980851140230022353588311445547248451142336585544111916489341441418890633019730101854648463669109636471162672120817824917407218303348419898985242808140058964414457471465221536301689319210853379995524156624829942780946758964309072692484524503974031949154005423948971844113769257156823395255042997434557967120122936287886272994336827603988076644070845456535059390110455532123959338354686709501965947157116618024249418340042125809823163860665551942191883280150556503637746217516167947991343226606484863461721881250950867469305763323991190602711636193429181021868663451423240656141036481686672207216510178940927578426246138789051935948202201039069515784638090342979600881257471340705419667858851219685966190797231145977198268039243169238831169502470679242625047521216680080745102102338697978848434690710623615151918273912523550802047059388477608402978
position.im=0.0047957559338652178505615663220486971154304886886673920781256111752398106107280366675989298691779797136737364961830758523741254480286664920460479195128211953261155569223186412660856033539583067793744552698972305956559820659036789189846739491155635838617923497250059314208186984179036223826655324004181421335633738898275114135499319014247271095039118772708132302750547913645230844806438628351797278101552420985568133578867374426937467785916207019758747794073870494765108717384461786347756065294984135627296206900076429271573756624100323471123560470223626746460265018297930359289043411279245762239698772188260974285993117734181827318766613834051977484272020698249213489627750957498023989747438133307647274695802671234943834981584342636056200655633883556867650337796993091229444120358050723663523120235639704136824323264324209617146569763642761341662189958962136924719552069482293150925374378282906250039171082284465702486444460840842205856092252444604814892208734287500540251296138686660257059365390928468879124177736053405984117806338296754892838258823
position.magnification=3473.0
position.rotation=-8.5
computation.iteration_limit=400000
rendering.inner_color=000000
rendering.outer_color=dddd00
rendering.transfer_function=1
rendering.color_density=-142.000
rendering.dwell_bands=0
rendering.palette=0.0,85,0,85,0.1,170,0,0,0.2,255,85,0,0.3,255,170,0,0.4,255,255,85,0.5,170,255,170,0.6,85,255,255,0.7,0,170,255,0.8,0,85,255,0.9,0,0,170
rendering.color_offset=221184
rendering.bump_mapping=false
rendering.bm_light_direction=0
rendering.bm_depth=50
rendering.bm_strength=50

Set scale precision to "float" and deselect "autocorrect glitches"

Animated version:
(http://orig08.deviantart.net/8aef/f/2016/081/f/f/x_fun_with_glitches___fixed_medium_by_stardust4ever-d9w48hb.gif)
http://sta.sh/01xwujdi80tx

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: PieMan597 on March 22, 2016, 10:21:01 AM

Maybe unchecked "ignore small addends?"

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 22, 2016, 11:53:08 AM

Quote from: PieMan597 on March 22, 2016, 10:21:01 AM

Maybe unchecked "ignore small addends?"

Where is this option? One could have fun deliberately breaking stuff for LOLz... :evil1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: PieMan597 on March 22, 2016, 12:33:05 PM

It shows up in the first image in http://www.fractalforums.com/mandel-machine/mandel-machine/ (http://www.fractalforums.com/mandel-machine/mandel-machine/).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 22, 2016, 01:12:20 PM

Quote from: stardust4ever on March 22, 2016, 01:33:44 AM

@Kalles Fraktaler: Kalles Fraktaler is failing to find the centroid again. I am using latest version.

You should use claude's excellent Newton-Raphson function to locate the minibrot :)

I agree that perturbation is solid and reliable - for bailout>2.
Because I have found locations that cause glitches even though no approximation is used, for bailout=2 (attached location)

The bigger problem is instead with Series Approximation.
My implementation checks the corners and the frame center of the view, i.e. 8 points.
More points could be added, perhaps also inside the view and not only at the borders.

But MM's glitches are very different from KF's, so I don't know how Botond implemented this...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 23, 2016, 05:29:58 AM

Quote from: Kalles Fraktaler on March 22, 2016, 01:12:20 PM

You should use claude's excellent Newton-Raphson function to locate the minibrot :)

Ah, so they call it something else then. I'll remember that next time... :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 23, 2016, 09:34:53 AM

Quote from: Kalles Fraktaler on March 22, 2016, 01:12:20 PM

But MM's glitches are very different from KF's, so I don't know how Botond implemented this...

I can't provoke these artifacts either so far. Neither with overskipping nor artificially bit starving the calculations.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on March 23, 2016, 10:49:54 AM

Quote from: stardust4ever on March 23, 2016, 05:29:58 AM

Ah, so they call it something else then. I'll remember that next time... :dink:

Menu Sepcial->Newton-Raphson zooming, or ctrl+D :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on March 23, 2016, 02:52:19 PM

Hi,
In principle, one could adress the accuracy problem by using interval/affine arithmetics methods. one of these metods can be defined as:

[z] = z + dz*t + 1/2 ddz*t² + ... + R*|tⁿ⁺¹|*E

Where dz is the first derivative of z, ddz the second derivative ...etc.
R*|tⁿ⁺¹| is a positive real number giving the error in the O(tⁿ⁺¹) term.
E is the unit disc centered at 0. E = [0,1]*exp(i*]-infinity, +infinity[

In the case of the series approximation we have:

Z_n = z_n + a_1,n*t + a_2,n*t² + ... + a_m,n*t^m

One can verify that the a_i,n are equal to d⁽ⁱ⁾z_n/i! for all i<m . for i==m it is slightly different.

Let's write Z_n in interval form (for m=3 for simplicity):

[Z_n] = z_n + a_1,n*t + a_2,n*t² + a_3,n*t³ + R_n*|t⁴|*E

Or using the notation in the original superfractalting paper:

[Z_n] = z_n + A_n*t + B_n*t² + C_n*t³ + R_n*|t⁴|*E

We have

[Z_n+1] = [Z_n]² + [Z₀]
(... some algebra manipulation ...)
[Z_n+1] = z_n+1 + A_n+1*t + B_n+1*t² + C_n+1*t³ + R_n+1*|t⁴|*E

Where (hopefully):
A_n+1 = 2*z_n*A_n + 1
B_n+1 = 2*z_n*B_n + A_n²
C_n+1 = 2*( z_n*C_n + A_n*B_n)

And:
R_n+1 = B_n² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

Where |tmax| is the maximal distance between the reference point and the corner points.
I use "reduction" operations to obtain R_n+1. The rules are:
- Replace any complex number by it's absolute value.
- Replace |t^k| by |t^m+1|*|tmax^k-m-1| whenever k>m+1. (in our case m=3)
- Remove any occurence of E in the computation of R_n+1. It is added afterward.

(Remark: Obviously, $\Delta_n$ is obtained by removing the z_n and error terms from [Z_n])

Ok! the formula for R_n+1 is lengthy: it requires m+2 terms. Moreover, it also requires absolute values => square roots... but:
- Some of the terms are very small and could be skipped safely.
- Using disk interval (which requires the absolute value) prevents excessive (actually catastrophic) growth of it's size. For example multiplying a disk interval by $\sqrt{2}/2 (1 + i)$ doesn't change it's size but a sqare interval's size will be multiplied by $\sqrt{2}$ .
- The computations are done once for each reference point. Moreover they can be done in parallel with the computations in full accuracy of z_n.
Another drawback of (all?) interval arithmetic methods is that it is very conservative: at some point the error term grows extremly fast.

We are not finished yet :evil1:! The question is how to use it?

Say, we have a function y(x). For some small enougth $\Delta x$ we have:

$\Delta y$ = y' * $\Delta x$

Let us call $\Delta x$ and $\Delta y$ absolute ~~errors~~ variations. Their absolute values will be called the errors.

The question that we are asking is: What is the maximal allowed error on y that corresponds to some allowed error on x?
In other words :
| $\Delta y$ | <= |y'|* | $\Delta x$ |

Here | $\Delta x$ | will be some fraction of the size of the area corresponding to a pixel. It depends on the resolution and the zoom factor.
y will correspond to $\Delta_n$ and y' to the derivative of $\Delta_n$ (Wich is: A_n + 2*B_n*t + 3*C_n*t²)
| $\Delta y$ | is simply given by R_n
Therefore, the accuracy of the series approximation is sufficient if the following condition is met:
R_n <= $\Delta_n$ '* | $\Delta t$ |
___________________________________________________________________________________

For the detection of the glitches caused by the numerical inaccuraces, a similar approach can be used: The question is:
What is the maximal allowed relative error on y that corresponds to some allowed absolute error on x?
That is, if:

| $\Delta y / y$ | > |y'/y|* | $\Delta x$ |

is true then the accuracy is insufficient and a glitch occures.
y is replaced by : $\delta_{n+1} = (2 z_{n} + \delta_{n}) \delta_{n} + \delta_{0}$
y' is replaced by : $\delta_{n+1}' = 2 (z_{n} + \delta_{n}) \delta_{n}' + 1$
| $\Delta x$ | will be some fraction of the size of the area corresponding to a pixel. It depends on the resolution and the zoom factor (replaced by $\Delta\delta_{0}$ ).
| $\Delta y / y$ | is replaced by the relative accuracy in the computation of $\delta_{n+1}$ . Ignoring the accumulation of rounding errors and taking into account only the cancellation that may occure in the computation of $2 z_{n} + \delta_{n}$ , I get:
| $\Delta y / y$ | = max(2|z_n|,| $\delta_{n}$ |)/| $2 z_{n} + \delta_{n}$ | * 2^-pmax
pmax is the number of bits in the mantissa.

So the glitch condition becomes:
$2^{-pmax} max(2 |z_n|, |\delta_n|) |\delta_{n+1}|> |2 z_n + \delta_n| |\delta_{n+1}'| |\Delta \delta_{0}|$

I was hoping to obtain something as simple and effective as Pauldelbrot's formula :embarrass: . Nevertheless, it's in fact quite close... Why?
The formula above tells us that a glitch may occure if: the floating point type used is not accurate enougth, the derivative of $\delta_{n+1}$ is too small and/or if | $2 z_{n} + \delta_{n}$ | is also too small w.r.t. |z_n| or $|\delta_{n}|$ . It also says there will likely be more glitches at higher resolutions.

For deep enough a zoom, adding $\delta_{0}$ is irrelevant (as Pauldelbrot noticed) and corresponds to a null operation. In this case, the derivative of $\delta_{n+1}$ shouldn't include the +1 and becomes $\delta_{n+1}' = 2 (z_{n} + \delta_{n}) \delta_{n}'$

Ok! This post is becoming too long. I doubt all the above formulas have any practical use at least because they require a lot of computations. In case I didn't do too big mistakes it shows that it is possible to quatify the approximation and accuracy errors.
___________________________________________________________________________________
PS:
The relation between the relative variations $\Delta x / x$ and $\Delta y / y$ is :
$\Delta y / y$ = x*y'/y * $\Delta x / x$
Here $\sigma = x y' / y$ is the condition "number" (https://en.wikipedia.org/wiki/Condition_number#One_variable) of y.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 23, 2016, 04:37:23 PM

I suspect the results would be too conservative and too costly to compute compared to brute force testing on the image itself.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 23, 2016, 11:07:27 PM

Quote

I doubt all the above formulas have any practical use at least because they require a lot of computations.

somebody needs to go ahead and try it out and see what the cost actually is, and if it does what it needs to do. what are we talking about in terms of cost? a couple minutes? hours days weeks? if it is anything even remotely reasonable, if it in fact can be used to guarantee correctness, it is huge! one could (would) always include an option in their program to toggle between a fast mode and a safe mode that does this stuff.

not being a math professor like some of you guys, one thing i have wondered about with regard to the handling of this series approximation, is in regard to checking against "the farthest point / corner point" or whatever, and then using the result of that for all points. is this approach guaranteed to produce correct results for all points? it always seemed kinda half-assed / janky to me.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 24, 2016, 01:46:48 AM

Quote from: quaz0r on March 23, 2016, 11:07:27 PM

not being a math professor like some of you guys, one thing i have wondered about with regard to the handling of this series approximation, is in regard to checking against "the farthest point / corner point" or whatever, and then using the result of that for all points. is this approach guaranteed to produce correct results for all points? it always seemed kinda half-assed / janky to me.

No. Distance in the image is not relevant. How much you can skip is a function of the number of coefficients and the extent to which the reference and the other points are "in snyc". So a good coverage of points in the image is of advantage. On the other hand it makes no sense to skip less to minimize errors with points that are wrong even with skip zero and need another reference anyway.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 24, 2016, 07:43:11 AM

Quote from: quaz0r on March 23, 2016, 11:07:27 PM

I have a pretty solid understanding of even complex math at this point (and by changing the rules regarding what defines "X^N" you change the fractal type, and as some of you may already know, between 2012-2013 I catalogued numerous known and previously unknown 2nd and 3rd order fractal formulae by doing little more than inserting abs and sign change in strategic places) although certain advanced calculus concepts and infinite series go beyond my understanding (though I totally get how derivatives, and to an extent intergals work).

Mandelbrot renders using arbitrary precision require a bit depth just beyond the zoom depth in order to calculate properly. My understanding in layman's terms, is that perturbation relies on the fact that the orbits of nearby pixels diverge rather slowly, with deltas only becoming large as they approach the escape trajectory.

Thus, a floating point value of fixed length far below the arbitrary precision required, can calculate these deltas with reasonable accuracy, except when it doesn't. Holes in the image created by higher bailout than the reference pixel, or areas with different periodicity, can be filled in by subsequent references.

Yet glitch patterns can and do occur, especially at deep zoom depths, typically references contained within iteration bands immediately preceding highly ornate julia structures (Mandel Machine), or errors within zoom frames typically resulting from a zoom path that forks away from the centroid (Kalles Fraktaler). The vast majority of time, these "scaled floats" (as implemented by software) work flawlessly, except for the afformentioned edge cases.

Could these "hard" cases simply be solved by throwing higher precision "arbitrary floats" at them? For instance say a 64-bit float value has 56 bits of precision, a sign, and 7 bits of exponent. Can we not simply create 128-bit, 192-bit or even 256-bit floats? I understand that CPUs may not natively work with high precision floats, but niether do they work with arbitrary bignum integers. By creating an "arbitrary float" library, one could set the number of bits available. When the delta is computed, one could eliminate the zeros at the start value, store that figure in a register, then use arbitrary precision to compute what's left, and scale the resulting value accordingly. The precision of the arbitrary scaled "floats" could still be significantly less than the reference pixel, albeit slower and with more computational overhead than using native CPU floats.

I would even postulate that calculating the deltas to full arbitrary precision, sans the preceding zeros, would yield identical results to full arbitrary precision, but calculations would slow down dramatically once the orbit begins to escape. So the question remains, between the extremes of pure fast float and pure slow arbitrary, how many bits of "arbitrary float" precision are safe to discard for a given location? Half? Three quarters? 99 percent? :tongue1:

Another thought: since most fractal users are burning at least four logical CPU cores, and it is difficult to multithread reference calculations, perhaps additional reference pixels can be calculated in tandem, utilizing idle CPU time. The reference with the highest bailout is given precidence. Test pixels will then be rendered using perturbation against the arbitrary references. If the corresponding orbit from one of the test pixel differs significantly from the arbitrary full precision reference orbit of the same pixel, then a "glitch" pixel is detected by the software and the precision of the "arbitrary float" library is increased incrementally until the escape orbits agree. This new "enhanced precision" level is used to calculate the remainder of the image. So only minor computational overhead by utilizing idle CPU cycles during the reference orbit to calculate multiple "extra reference" pixels is needed to detect the presence of glitches. An optional "failsafe rendering" checkbox option could detect and autocorrect glitch formations with only minor performance penalty. Of course it is possible a glitch area could squeeze through the cracks, but unlikely.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 24, 2016, 09:48:26 AM

Quote from: stardust4ever on March 24, 2016, 07:43:11 AM

Could these "hard" cases simply be solved by throwing higher precision "arbitrary floats" at them? For instance say a 64-bit float value has 56 bits of precision, a sign, and 7 bits of exponent. Can we not simply create 128-bit, 192-bit or even 256-bit floats? I understand that CPUs may not natively work with high precision floats, but niether do they work with arbitrary bignum integers. By creating an "arbitrary float" library, one could set the number of bits available.

I already posted that one can compute the deltas with more bits and avoid glitches this way while still using far less bits than with full arbitrary precision calculations. There are libraries for this and it's straightforward.

Quote

I would even postulate that calculating the deltas to full arbitrary precision, sans the preceding zeros, would yield identical results to full arbitrary precision, but calculations would slow down dramatically once the orbit begins to escape. So the question remains, between the extremes of pure fast float and pure slow arbitrary, how many bits of "arbitrary float" precision are safe to discard for a given location? Half? Three quarters? 99 percent? :tongue1:

The perturbation method does "remove the zeros" as you put it and I don't think you can do better than this with as few bits as possible for the deltas and an optimal skip. Concerning references if one uses minibrots they never run out of iterations and only glitches are of concern. They cost more than iterating some point but by chosing them well one can minimise the required references.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 24, 2016, 09:51:07 AM

there are indeed soft floats of these sizes readily available as such, you dont even need to implement it yourself. gcc has https://gcc.gnu.org/onlinedocs/libquadmath.pdf for instance. it is significantly slower than hardware floating point though, so it is not really useful in this particular application. it is overall faster to use hardware fp, correcting the glitches, than to use a slow soft float just to incur some degree less glitches. at least that is the general case. also, useful arbitrary precision ("bignum") implementations utilize things like simd to maximize performance on different architectures, and would likely be more performant than some cheesy soft float implementation anyhow.

Quote

I would even postulate that calculating the deltas to full arbitrary precision, sans the preceding zeros, would yield identical results to full arbitrary precision

this is already how arbitrary precision libraries are implemented. it is essentially the same sort of arrangement as the "extended" floats we are using with an integer exponent, except that you can continue adding to the size of the mantissa (and you get the performance benefits of utilizing simd to manipulate these larger mantissas).

Quote

perhaps additional reference pixels can be calculated in tandem

i thought about doing this just for the hell of it, but decided it would be at best of minimal value. something that might be of greater value would be to utilize remaining resources to calculate a greater number of series coefficients in parallel. in my brief experiments with this, the cost of parallel synchronization made it a performance win only with a rather large number of coefficients, but potentially useful nonetheless.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 24, 2016, 11:00:09 AM

Quote from: quaz0r on March 24, 2016, 09:51:07 AM

I tested this and on my system it depends also on bits required for the reference orbit (can be computed in parallel with coefficients). The worst case was about 43 coefficients needed for parallel to be faster and the best 13.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on March 24, 2016, 05:07:59 PM

Quote from: hapf on March 23, 2016, 04:37:23 PM

I suspect the results would be too conservative and too costly to compute compared to brute force testing on the image itself.

Yes, interval arithmetics are usually too conservative. That depends also on the number of coefficients of the series approximation: IA's error term grows exponentially. The more coefficients the more the error grows rapdily. That also means that it remains very small for most iterations and then blows up at some point. According to my experiments -while writing the mandelbrot polynomial roots finder- the more coefficients there are the better. For that particular case an IA of the form [z]== z + dz*t + R E t² was sufficient.
The cost is dominated by square roots evaluation's overhead, maybe one order of magnitude slower, depending on the number of coefficients. Compared to brute force, it depends obviously on the number of samples :). Moreover, with brute force, one can not be sure at 100% that there won't be significant errors. That said, IA method would be useful for testing and when in doubt.

Quote from: quaz0r on March 23, 2016, 11:07:27 PM

I agree 100% :)
By "practical use" I was meaning "practically for the end user". For testing purposes I believe it would be useful.

I'm not a math prof either. I took (a lot of) shortcuts while deriving the formulas. The main point was to show that it is possible to get garanteed correct results without user intervention or comparison with full accuracy results. A better analysis is still needed. Maybe a good execise (subject?) for a numerical analysis cours student. :angel1:

I've just tested my glitch detection formula in 3dickulus's SFTC and it seems to work well thought it doesn't have more benefits than Pauldelbrot's method (+ much more costly).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 24, 2016, 10:50:27 PM

well, if paul's method is faster and doesn't fall down ever, then great. :D has anyone looked at / commented on that? can we reasonably assume it will always work? i think the one criticism ive seen leveled at his method is that it might be overly aggressive, though if a more complicated condition is much more costly, it is probably a wash at worst in terms of overall performance.

the big win still would be to have a remotely reasonably performant criteria for guaranteeing the series approximation doesnt blow up. of course the holy grail would be to also be able to run the series approximation right up to the event horizon of what still produces correct results. ;D are there any thoughts on that? in the mean time, lets get to trying out this condition youve come up with already and see what we've got :angel1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on March 25, 2016, 03:10:46 AM

Quote from: quaz0r on March 24, 2016, 10:50:27 PM

The edge of the Mandelbrot set is the event horizon. Problem is it goes on forever. Get crackin' :devil:
:banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli: :banana: :chilli:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 25, 2016, 03:45:42 AM

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 25, 2016, 10:00:40 AM

Quote from: quaz0r on March 24, 2016, 10:50:27 PM

The method works but gives no indication what the threshold should be. Set it (too) high and you can miss pixels that will go bad. Set it (too) low and it will make you use many new references for pixels that don't need any. What is too high or low is not clear and depends on the location.

Quote

the big win still would be to have a remotely reasonably performant criteria for guaranteeing the series approximation doesnt blow up. of course the holy grail would be to also be able to run the series approximation right up to the event horizon of what still produces correct results. ;D are there any thoughts on that? in the mean time, lets get to trying out this condition youve come up with already and see what we've got :angel1:

I regularly go within a few hundred iterations of the minimal iteration in the image. One can not do (much) better than this, but it depends on the location and image size if this is reasonable to do or not concerning running time.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on March 25, 2016, 12:28:12 PM

Quote from: hapf

I regularly go within a few hundred iterations of the minimal iteration in the image.

hmm, if your stuff is set to go that close dont you start overskipping eventually?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 25, 2016, 01:01:31 PM

Quote from: quaz0r on March 25, 2016, 12:28:12 PM

hmm, if your stuff is set to go that close dont you start overskipping eventually?

I don't think so because I explicitly test on a subset of pixels. There are 2 kinds of pixels. The ones that get corrupted
even without skipping and the others. The others are well behaved and testing works. I can't get at every location close to
the minimal iteration (at least while keeping running time minimal) but outside of the close neighbourhood of a minibrot (where the
minibrot is filling part of the image's pixels) it's often possible. Basically the period rule applies.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on March 25, 2016, 01:14:55 PM

I looked into using more bits for the deltas to avoid corruption. It did not work at all. :banginghead:
Obviously the bottleneck was not only there. Since the deltas also use the stored period orbit I raised the
bits there too to the same level. And :music:
Corruption melted away. But of course the price is that it's much slower. 128 bits were not enough in my test location.
256 did the trick. So far this is (much) slower than using multiple references. But what about skipping? I skipped as usual and
it worked also. :chilli:
That makes it more useful. In a scenario deep down with say 10000 bits it might be faster than juggling multiple references if
the needed bits are << 10000. How many bits are needed is once more surely depending on the location. Sigh...
Test location:
-1.324946828038601241293961246879978904162330880564523955917980064508754721165208885756024060536291169198361119054E+00
7.768222882426871368840044492237613902669720359727706283751229230331360432497599476608069550430820219257632354995E-02
5.219637916E-100

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on April 21, 2016, 01:53:05 AM

I implemented the polygon lowest period algorithm and using it and the minibrot size formula automatic juncture generation from a given location. So with little time and repeated application one can find deep intricate locations this way.
Enjoy:
-1.7675000269946161555400404107513534984031838161046534008067079931746621994907021528310021771904046972122325984333820759918911541748093202587616220833948959262744839266688861011738405421525993935683884311431659750645764070085831810422250322106707635723018021057749909755207707876239767192745602684117839146510497553844002919264100766187025810863163240144493269812736505219498039222692680009320333631305921177918576545776386784975880496490158971993265736728436353362021101156691248619415027367938615767911601378377760940355754578644959893893731632820166069938893264537141422288174957652233866210019552478092523886703878080498323200338735277735938165822595931659639242964991419086703224232396866467485083448188731105608939603910774538850967766198940065022762637853916091695632866923588481742176382996137364408639504815139531488541796290471445788974400386732900157044908142932128670931078713973937965060261111619223445116028422808487944875125399257246372785088028042336026905064032994492007305764521252400116530336771787473381316604161258265492710331359130335438870241859899960858795348290730728316841140262271856931072729587598547260736859816335392240813360918274037158474329806395969648603651448637538715248437785542511723280132999056713174166965959203361646680597598415865131971843096219122593776804231724542730119628151206097510523946496632421183513770964224522410356666449448703054643270894166794337655247317043163490584095103146414884242489465886483001436542106132518931831620069674677463895650491322232595878220032850654986503268564820542091088013746999217355701392202621199659261905320189963942652496170016138883077121669252908989695106036077057270690132444712670628007101279212553446445988459697263783339748041919146666274261716789210062305429396554762947455638070860811320269744929826136941148465373971935887435633955517963143821753134450469609540260958552805455471927312471131990927737870826687085264141588051892413343050885183E+00
4.761597192897338679439963044150459634816291810029324011527637005873645234179655153727373922777615699641964116940961423 46090127916148875787873335806901518127315276837779067003603266755437072443468485253798649507068375376872526809235482689 25954472530726209222303147736291566105916777486960627058965299724062772794585270771799128769801054234002145442310909139 57542317703856357324763889460115739873735233341855321498949812177985621487880260429802953165257094742162588472829167198 92913815916830623178770499852505920635733900071191935337276080672212983206819267076370414341539639305579904907011993043 03299318769766368041025187471954273424908665334063983469067024039976728296588966887700948665952746968450952539643021094 08721057666835139608809331277143702001347101368224169240098592548623803863969559788408718891413497382433022049926974019 36048454003190186383330641558035346782580766713112014361181659993219954058171762344353285866479457290246005839068956816 08495677206630702948620557132517494983569945774146508920852048505470909979751374681193390002468928565292631553670702139 70287687320561156609570212003788606218335181478285941860460533559497833179122027371870473466553993552073742101075138320 23915871237310254298741656146212027285439681319361593545950718971036008670716052241241777001634279500933646049327914857 92164877377979353121809380037609889187473673026660449962999408077312478035944509469453983838832208369999204263272160984 37467263086222841608191445902787399180573043184622723962506028796739250853938269437077969656239486102674170536958841079 45523678417161826684638630886832198311459430222427413071275391083379117788805259763933686832935868334706466121409752863 95810227943064083049354771009673575603845218160821777949087334235483170724960033879364538169855784966183455858658079433 19677151650157108758362917976262812496357044046341753081833777023233483416840627190421587374712963563342284846976886645 9515196111956770615773407782317E-02
5.0E-1924

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on April 21, 2016, 03:22:17 AM

Quote from: hapf on April 21, 2016, 01:53:05 AM

I rendered the area in Mandel Machine (1000,000 bailout). Why isn't glitch correction working?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on April 21, 2016, 09:22:01 AM

Quote from: stardust4ever on April 21, 2016, 03:22:17 AM

I rendered the area in Mandel Machine (1000,000 bailout). Why isn't glitch correction working?

I don't use Mandelmachine. But one possible reason could be that the corruption trigger is too low/high. Try 1/500 (500) instead of 1/10000 (10000).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on April 21, 2016, 09:34:12 PM

Juncture hopping is extreme fun. It DOES matter big time where one goes in a juncture to get to the next juncture. One can shape the results very differently by going here or there. Discovering the laws that govern this is amazing. Complex stuff (pun intended). ;D
Unfortunately the number of hoppings is limited as bits go up and iterations go up and eventually it becomes very slow even with all the tricks of the trade thrown at it.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on April 22, 2016, 04:08:10 AM

I dunno but it appears that Mandel Machine quits correcting glitches above some threshold, 6-8k zoom levels or so. It hasn't been updated in a while which sucks because it's much faster than Kalles Fraktaler for doing Plain Jane Mandelbrot zooms.

Unrelated, but I tried getting the superfractalthing plugin working a few weeks back. Sadly it no longer functions anymore with browsers using Java 7 or later. Only signed apps allowed to execute code... :'(

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on May 01, 2016, 08:15:01 PM

i was having a gander at some info about double-double arithmetic

Quote from: wikipedia

Note that double-double arithmetic has the following special characteristics:

- The actual number of bits of precision can vary. In general, the magnitude of the low-order part of the number is no greater than half ULP of the high-order part. If the low-order part is less than half ULP of the high-order part, significant bits (either all 0's or all 1's) are implied between the significant of the high-order and low-order numbers.

- Because of the reason above, it is possible to represent values like 1 + 2^-1074, which is the smallest representable number greater than 1.

and it reminded me of a comment made in the perturbation discussions here that glitches occur when a value becomes, i cant find the post and dont recall how exactly it was said, but i think the idea was for instance if the string of digits were to become something like 1473333333333333333333333333333333345627, so that the part of the value that would differentiate different points would get lopped off, resulting in the blobs of points that incorrectly arrive at the same destination... so i wonder if utilizing such double-double arithmetic as described here could potentially be a performant way of dealing with this scenario?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on May 01, 2016, 08:39:07 PM

Quote from: quaz0r on May 01, 2016, 08:15:01 PM

i was having a gander at some info about double-double arithmetic

and it reminded me of a comment made in the perturbation discussions here that glitches occur when a value becomes, i cant find the post and dont recall how exactly it was said, but i think the idea was for instance if the string of digits were to become something like 1473333333333333333333333333333333345627, so that the part of the value that would differentiate different points would get lopped off, resulting in the blobs of points that incorrectly arrive at the same destination... so i wonder if utilizing such double-double arithmetic as described here could potentially be a performant way of dealing with this scenario?

Good question. Sometimes special cases greater precision is required than provided by default in software. I briefly remember doing some deep zoom Julias in Fractal Extreme before giving up the endeavor. I would find a zoom path somewhere in the Mandelbrot set that terminated at a deep zoom mini, and paste the coordinates as seed values for Julia mode and then zoom into coordinate 0 + 0i. This area for some reason requires double precision compared to a "normal" zoom path, and the maximum 100 bits extra precision allowed by Fractal Extreme quickly became exhausted.

The fact that rarely when rendering fractals, a specific location requires precision greater than the actual zoom depth, yet here we are doing perturbation renders estimating orbits with low precision, it is expected at some point that we find some errors. Another issue with perturbation that I recently learned thanks to Kalles Fraktaler explaining how he implemented my formulas, is that the polynomial expansion necessary for higher order equations in perturbation can develop an excessive number of terms, thus creating diminishing returns regarding speed increase at higher and higher power fractals.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on May 02, 2016, 10:40:16 PM

Quote from: stardust4ever on April 21, 2016, 03:22:17 AM

I rendered the area in Mandel Machine (1000,000 bailout). Why isn't glitch correction working?

Have you tried this location in MM with "ignore small add-ends" switched off?
Have you tried it with less terms for approximation?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on May 02, 2016, 10:50:36 PM

Quote from: Kalles Fraktaler on May 02, 2016, 10:40:16 PM

Have you tried this location in MM with "ignore small add-ends" switched off?
Have you tried it with less terms for approximation?

Well no, but the fractal itself isn't glitched up persay, it just isn't calculating the unsolved areas. Normally, these areas get fixed with second, third, and so on passes. For some reason Mandel Machine doesn't seem to do this past around 6000 or so zooms. But to answer your question, no, I did not attempt to use this mode.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on May 02, 2016, 11:33:45 PM

Quote from: stardust4ever on May 02, 2016, 10:50:36 PM

I think these are not the ordinary glitches but comes from ignore small add-ends. I think I had the same kind of issues and eventually I gave up that track of optimization. When to include or not to include add-ends is hard to generalize, the deeper and closer to minibrot you get the more sensitive it gets.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on May 03, 2016, 12:00:06 AM

Quote from: Kalles Fraktaler on May 02, 2016, 11:33:45 PM

It is unfortunate too. The "small addends" start to get nasty with the 4th and 5th order equations as you demonstrated in another thread. Maybe if the squares were included in calculations but not the 3rd and 4th power terms? One could check the magnitude of the addends and only calculate them if they are larger than the current precision level. However estimating their magnitude prior to calculation may not save much time when dealing in floats or doubles. :tongue1:

I get that as the orbits slowly escape, the delta values become larger with time so that these "small addends" may not be so insignificant as the orbit approaches it's escape trajectory. You can only get away with skipping so many computations before the integrity of the render is compromised. And zoom movies full of glitches are no fun to fix. Sometimes I simply leave them in when it rarely happens. :hurt:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on May 03, 2016, 09:44:14 AM

its not that fantastic of an optimization anyhow :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on May 05, 2016, 07:29:28 PM

Quote from: lycium on March 20, 2016, 05:49:22 AM

UltraFractal is promised to have perturbation in it's next release.
When is Chaotica going to have perturbation?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on May 05, 2016, 08:02:52 PM

Quote from: Kalles Fraktaler on May 05, 2016, 07:29:28 PM

UltraFractal is promised to have perturbation in it's next release.
When is Chaotica going to have perturbation?

That is news. I'll even buy an "upgrade" if they pull this off in UF6.

Better yet is they can implement perturbation with some of the public databases without reworking them. A lot of the equations are "junk" though. Interest in some equations like the Lambda and others is mostly academic however since any amount of deep zooming will reveal it's just the period two bulb of the Mandelbrot set mirrored.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 11, 2016, 03:51:52 PM

as far as i can tell with what everyone has been doing with series approximation thus far, it all seems like one big exercise in taking a wild stab in the dark and just hoping for the best: checking against arbitrary points to determine how many iterations to skip for all points and just hoping it all works out in the end, and not even having a proper check to begin with for when to bail on the series approximation. checking whether terms outgrow other terms by some arbitrary amount, wtf is that exactly? can that be proven to be a correct and comprehensive methodology? as far as i can tell it is basically just something one guy pulled out of thin air one day and it seems to kind of work and nobody has really given it much thought beyond that. noting also that this guy's program, as much good as can be said for it, has always been buggy and glitchy, and is now abandonware.

i was just looking again at knighty's post for calculating the error in the series approximation, and it actually doesnt look all that costly. though it seems you still are left with the problem of checking against arbitrary points and hoping for the best. could there be any way to improve that aspect?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 11, 2016, 05:05:16 PM

Quote from: quaz0r on August 11, 2016, 03:51:52 PM

i was just looking again at knighty's formula for calculating the error in the series approximation, and it actually doesnt look that costly. if i read the post correctly there is no testing against points, so if it indeed works then it should be solid. that would be fantastic. as far as i can tell with what everyone has been doing with series approximation thus far, it all seems like one big exercise in taking a wild stab in the dark and just hoping for the best: checking against arbitrary points to determine how many iterations to skip for all points and just hoping it all works out in the end, and not even having a proper check to begin with for when to bail on the series approximation. checking whether terms outgrow other terms by some arbitrary amount, wtf is that exactly? can that be proven to be a correct and comprehensive methodology? as far as i can tell it is basically just something one guy pulled out of thin air one day and it seems to kind of work and nobody has really given it much thought beyond that. noting also that this guy's program, as much good as can be said for it, has always been buggy and glitchy, and is now abandonware.

Do you mean that K.I.Martin's Superfractalthing is "abandonware"?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 11, 2016, 05:45:59 PM

i was referring to botond and his mandelmachine. did martin ever talk about the specifics of his implementation of the series stuff? i havent used SFT much, though i seem to recall people reporting that it was rather glitchy and incomplete, and i think he stopped working on it before the advent of glitch detection and any other advances that have been made here on the forums. from the looks of his sourceforge page, it doesnt look like there has been any real development on it since he first introduced it.

since nobody else seems interested, i guess i'll try implementing knighty's wall of math and report back with any success stories, though i dont know if i will be able to decipher it. it would be neat if you guys could dumb it down once in a while for us non-math folk. :dink: for instance, i dont know what R₀ should be. i dont know what E is. i dont know what this means: "E = [0,1]*exp(i*]-infinity, +infinity[". and im not sure how all this is supposed to be used either. is this intended for the checking against arbitrary points to determine the number of iterations to then skip for all points in the image, like how people have been doing? or is this R thing supposed to be used during the initialization of each point, where if an error tolerance is exceeded you just try that point again later with another reference point?

in any case, it seems to me that the only really proper way of doing things would be to check every point for what iteration to start on, but that would take too long so nobody is ever going to do it that way. can anyone prove / even just say with some legitimate degree of confidence that arbitrarily picking a starting point for all points can always produce correct results, and will never result in any points starting too late? keeping in mind that going too far with series approximation can result in incorrect results that will not get caught by the perturbation-glitch detection.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 12, 2016, 06:58:12 AM

Mandel Machine may be abandonware (hasn't been updated since 2014 I believe) but it is fast and I have been able to render some amazing images with it. Both my contest winners were Mandel Machine renders.

However, if Botond is still around, it would do a lot of goodwill to the community to release the source under GPL if he doesn't want to maintain it any more.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Pauldelbrot on August 12, 2016, 08:20:42 AM

Quote from: stardust4ever on August 12, 2016, 06:58:12 AM

Concur.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 12, 2016, 09:20:17 AM

Quote from: stardust4ever on August 12, 2016, 06:58:12 AM

I believe the source is available on his site.
(tons of assembler... :evil1:)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 12, 2016, 10:09:38 AM

Quote from: Kalles Fraktaler on August 12, 2016, 09:20:17 AM

I believe the source is available on his site.
(tons of assembler... :evil1:)

Assembly would explain why it's so fast. If Mandel Machine were a car and we were caught driving it, they'd have given us all speeding tickets... :siren:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 12, 2016, 10:21:48 AM

Quote from: stardust4ever on August 12, 2016, 10:09:38 AM

Assembly would explain why it's so fast. If Mandel Machine were a car and we were caught driving it, they'd have given us all speeding tickets... :siren:

With this methaphore, we would be able to turn in almost all curves, except a few... :scared: :laugh:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 12, 2016, 10:32:22 AM

Quote from: Kalles Fraktaler on August 12, 2016, 10:21:48 AM

With this methaphore, we would be able to turn in almost all curves, except a few... :scared: :laugh:

Automatic glitch correction is analogous to tracktion control. Occasionally you still glitch, er crash... :death:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 12, 2016, 02:12:49 PM

the code is available, and yes most of it is written in assembly to try to achieve as much performance as possible. though some drawbacks to that are being buggy, unmaintainable, and nonportable.
in any case, i only mentioned it to point out that some of these algorithms may not be as perfect as they maybe could be, and to encourage any intelligent and honest conversation that might be had here with regard to our understanding of them and what further progress might be made.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 12, 2016, 11:38:03 PM

Quote from: quaz0r on August 11, 2016, 05:45:59 PM

since nobody else seems interested, i guess i'll try implementing knighty's wall of math and report back with any success stories, though i dont know if i will be able to decipher it. it would be neat if you guys could dumb it down once in a while for us non-math folk. :dink: for instance, i dont know what R₀ should be. i dont know what E is. i dont know what this means: "E = [0,1]*exp(i*]-infinity, +infinity[". and im not sure how all this is supposed to be used either. is this intended for the checking against arbitrary points to determine the number of iterations to then skip for all points in the image, like how people have been doing? or is this R thing supposed to be used during the initialization of each point, where if an error tolerance is exceeded you just try that point again later with another reference point?

That would be great!

E is an error symbol. "E = [0,1]*exp(i*]-infinity, +infinity[" is just a way to say "E is the unit disc centered at 0". One doesn't need to worry about it when writing the code. The only formula needed is:

R_n+1 = |B_n|² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

R_n+1*|tmax|⁴ is the radius of the disc interval. It is the maximal error that we do by neglecting the higher order terms of the series approximation (truncation error (https://en.wikipedia.org/wiki/Truncation_error)).
R₀ = 0. Simply because there is no truncation error. It remaines equal to zero until the third iteration (or so ;))

Quote from: knighty on March 23, 2016, 02:52:19 PM

The question that we are asking is: What is the maximal allowed error on y that corresponds to some allowed error on x?
In other words :
|Delta_y| <= |y'|* |Delta_x|

Here |Delta_x| will be some fraction of the size of the area corresponding to a pixel. It depends on the resolution and the zoom factor.
y will correspond to Delta_n and y' to the derivative of Delta_n (Wich is: A_n + 2*B_n*t + 3*C_n*t²)
|Delta_y| is simply given by R_n
Therefore, the accuracy of the series approximation is sufficient if the following condition is met:
R_n <= Delta_n'* |Delta_t|

I did some mistakes here. Good news: It should be:
R_n*|tmax|⁴ <= | $\Delta_n$ '|* | $\Delta t$ |
Because the trucation error is R_n*|tmax|⁴ not R_n.
As it is that formula have to be computed for each pixel because
$\Delta_n$ '=A_n + 2*B_n*t + 3*C_n*t²
is function of t.
But we are interested in its minimal absolute value among all the values of t spanning the zoomed area. A lower bound can be computed using interval arthmetics. I'll come back tomorrow after doing the compuations and checking them. :D

PS: For deep enought zooms, the bottelneck is mainly in the computation of the references. It is possible to avoid unnecessary computations by reusing the reference until glitches occure. For example, if the reference is centered on the root of a minibrot, one can still use that same reference when zooming near that minibrot. It is also possible to refine a refrence using perturbation (+ Newton).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 13, 2016, 10:37:12 PM

Ok!
The last formula for cheking if the series appriximation is good at iteration n should be:

R_n*|tmax|⁴ <= (|A_n| - 2*|B_n|*|tmax| - 3*|C_n|*|tmax|²)* | $\Delta t$ |

Where:

R_n*|tmax|⁴ is an upper bound on the truncation error.

(|A_n| - 2*|B_n|*|tmax| - 3*|C_n|*|tmax|²) is a lower bound on the absolute value of the derivative. As it is, it can be negative which means that the derivative could be 0 somewhere so the approximation's quality is likely to be too low.

| $\Delta t$ | is related to the "radius" that corresponds to a pixel.

|tmax| is the maximal distance between the reference point and any point of the rendered area.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 14, 2016, 12:25:20 AM

cool, thanks for your work on this! i'll [try to] check it out ;D

for extrapolating your formulas to an arbitrary number of terms, i see the pattern here:

R_n*|tmax|⁴ <= (|A_n| - 2*|B_n|*|tmax| - 3*|C_n|*|tmax|²)* | $\Delta t$ |

but this one im not sure:

R_n+1 = |B_n|² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

maybe i just need to look at it longer

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 14, 2016, 10:50:31 AM

A, B and C are 3 terms, but KF, and MM are using arbitrary many terms.
And therefore we can render magnum opus thousands or ten-thousands times faster than FX...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 14, 2016, 11:02:59 AM

Quote from: Kalles Fraktaler on August 14, 2016, 10:50:31 AM

A, B and C are 3 terms, but KF, and MM are using arbitrary many terms.
And therefore we can render magnum opus thousands or ten-thousands times faster than FX...

hehe... :evil1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 14, 2016, 03:01:12 PM

One can get the formula of R for any number of terms in the series approximation.
The formula is given for a 3-terms only for simplicity and in order to test the idea.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 16, 2016, 03:46:01 AM

:D :D :D

it works, and it works WELL! it is taking me farther than the old method of checking when the last term grows larger than the others by a certain amount yada yada, and is even skipping a few more than my experiment with using series acceleration error as the check (which itself was better than the other thing)! and everything rendering fine as far as i can tell so far. awesome! :banana: :chilli:

noting though that my program is currently setup to use a minimum of 8 terms, so hopefully it still bails soon enough when using the same number of terms.

also i wasnt sure what $\Delta t$ is supposed to be, so i made it the distance between adjacent points.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Pauldelbrot on August 16, 2016, 04:20:36 AM

Quote from: quaz0r on August 16, 2016, 03:46:01 AM

:D :D :D

it works, and it works WELL! it is taking me farther than the old method of checking when the last term grows larger than the others by a certain amount yada yada, and is even skipping a few more than my experiment with using series acceleration error as the check (which itself was better than the other thing)! and everything rendering fine as far as i can tell so far. awesome! :banana: :chilli:

noting though that my program is currently setup to use a minimum of 8 terms, so hopefully it still bails soon enough when using the same number of terms.

also i wasnt sure what <Quoted Image Removed> is supposed to be, so i made it the distance between adjacent points.

Do you have (pseudo) code?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 16, 2016, 05:11:26 AM

Quote from: quaz0r on August 14, 2016, 12:25:20 AM

m = 1
R_n+1 = |A_n|² + 2*|z_n|*R_n + 2*|tmax|*|A_n|*R_n + |tmax²| * R_n²

m = 2
R_n+1 = 2*|z_n|*R_n +2*|A_n|*|B_n| + |tmax|*(2*|A_n|*|R_n|+|B_n|²) + |tmax²|*2*|B_n|*R_n + |tmax³|*R_n²

m = 3 (from above quote)
R_n+1 = |B_n|² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

Quote

maybe i just need to look at it longer

trying the same here :D mostly on paper doing boring algebra to get a feel for how it works (results above for m=1,2)

writing with indices helps, addition of letters is awkward - something like $z_n \to a_0 ; A_n \to a_1 ; B_n \to a_2 ; C_n \to a_3 ; R_n -> a_{m+1} ; \ldots$
(omitting the n that occurs everywhere seems to make sense too for this part of the algebra scribbling on paper)

cool stuff knighty!

UPDATE
Using the notation from my blog post, https://mathr.co.uk/blog/2016-03-06_simpler_series_approximation.html
Recall the coefficients are
$a_{1,n+1} = 2 z_n a_{1,n} + 1$
$a_{k,n+1} = 2 z_n a_{k,n} + \sum_{j=1}^{k-1} a_{j,n} a_{k-j,n}$
Use $m$ " $a$ " terms, so the coefficient of the truncated part starting $\left<\left<c\right>\right>^{m+1}$ is $R_n \hat{1}$ (using hat for disc interval), and writing T for tmax, and aliasing $z_n = a_0$ and $R_n = a_{m+1}$ , I think it boils down to this:

$R_{n+1} = \sum_{j=0}^{m+1} \left( \sum_{k=j}^{m+1} |a_k| |a_{m+1 + j - k}| \right) |T|^{j}$

note this includes some terms twice multiplied in opposite orders, could be implemented by multiplying by 2 instead of repeated calculations

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 16, 2016, 05:43:28 AM

Quote

Do you have (pseudo) code?

truncError = 0;
series approx loop {
   calculate_series_coefficients(A, B, C);
   truncError = |B|² + 2*(|z|*truncError + |A|*|C|) + 2*|tmax|*(|A|*truncError + |B|*|C|) + |tmax²|*(|C|² + 2*|B|*truncError) + 2*|tmax³|*|C|*truncError + |tmax⁴|*truncError²;
   if ((truncError * |tmax|⁴) > ((|A| - 2*|B|*|tmax| - 3*|C|*|tmax|²) * | $\Delta t$ |)) {
   // this is the iteration i'll initialize all other points at
   anything_else_you_do_when_you_bail_on_series_approx();
   }
}

i just kinda copy pasted what was already here, maybe that doesnt help much ;D

z is the reference Z_n
tmax i just set to the sidelength of the image for simplicity
$\Delta t$ i set to the distance between points

im not sure if thats all right but thats what i did just now and it seems to work.

update: continued testing the last hour or two with no problems. manual zooming for a while and also tested an ultradeep location.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Pauldelbrot on August 16, 2016, 07:18:09 AM

Quote from: quaz0r on August 16, 2016, 05:43:28 AM

truncError = 0;
series approx loop {
   calculate_series_coefficients(A, B, C);
   truncError = |B|² + 2*(|z|*truncError + |A|*|C|) + 2*|tmax|*(|A|*truncError + |B|*|C|) + |tmax²|*(|C|² + 2*|B|*truncError) + 2*|tmax³|*|C|*truncError + |tmax⁴|*truncError²;
   if ((truncError * |tmax|⁴) > ((|A| - 2*|B|*|tmax| - 3*|C|*|tmax|²) * |<Quoted Image Removed>|)) {
   // this is the iteration i'll initialize all other points at
   anything_else_you_do_when_you_bail_on_series_approx();
   }
}

i just kinda copy pasted what was already here, maybe that doesnt help much ;D

z is the reference Z_n
tmax i just set to the sidelength of the image for simplicity
<Quoted Image Removed> i set to the distance between points

im not sure if thats all right but thats what i did just now and it seems to work.

update: continued testing the last hour or two with no problems. manual zooming for a while and also tested an ultradeep location.

Thanks.

This looks like it's for just three terms though...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 16, 2016, 07:34:33 AM

Quote

This looks like it's for just three terms though

indeed, you guys are the mathematicians, i await your brilliance to shed further light on the matter.. :)
it looks like claude may have posted a formula for arbitrary number of terms there, though i have a hard time decoding that math stuff

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 16, 2016, 11:52:08 AM

Quote from: knighty on August 12, 2016, 11:38:03 PM

R_n+1 = |B_n|² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

R_n+1*|tmax|⁴ is the radius of the disc interval. It is the maximal error that we do by neglecting the higher order terms of the series approximation

Hm, with R_n depending on |tmax| like that, it makes it harder to cache the series approximation coefficients when zooming around a still-good primary reference...

Running some tests with order m=16 now, seems ~~promising so far~~ it skips at most 1 period of the reference? while other skipping methods allow skipping beyond that. (I got rid of the off-by-one bugs elsewhere in the code). Demonstration-quality C++ code attached, note that it detects glitches but doesn't correct them, and location is hard-coded with a zoom sequence.

I plan on updating it with glitch correction and exterior distance estimation once I get the truncation error stuff for the derivative's series approximation sorted. Equation scribbling ahoy...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 16, 2016, 02:07:31 PM

Quote from: quaz0r on August 16, 2016, 05:43:28 AM

truncError = 0;
series approx loop {
   calculate_series_coefficients(A, B, C);
   truncError = |B|² + 2*(|z|*truncError + |A|*|C|) + 2*|tmax|*(|A|*truncError + |B|*|C|) + |tmax²|*(|C|² + 2*|B|*truncError) + 2*|tmax³|*|C|*truncError + |tmax⁴|*truncError²;
   if ((truncError * |tmax|⁴) > ((|A| - 2*|B|*|tmax| - 3*|C|*|tmax|²) * |<Quoted Image Removed>|)) {
   // this is the iteration i'll initialize all other points at
   anything_else_you_do_when_you_bail_on_series_approx();
   }
}

i just kinda copy pasted what was already here, maybe that doesnt help much ;D

z is the reference Z_n
tmax i just set to the sidelength of the image for simplicity
<Quoted Image Removed> i set to the distance between points

im not sure if thats all right but thats what i did just now and it seems to work.

update: continued testing the last hour or two with no problems. manual zooming for a while and also tested an ultradeep location.

Seems tmax and $\Delta t$ are limited to double precision, unless you are using some other datatype?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 16, 2016, 03:38:47 PM

Quote from: knighty on August 13, 2016, 10:37:12 PM

Ok!
The last formula for cheking if the series appriximation is good at iteration n should be:

R_n*|tmax|⁴ <= (|A_n| - 2*|B_n|*|tmax| - 3*|C_n|*|tmax|²)* |<Quoted Image Removed>|

Where:

R_n*|tmax|⁴ is an upper bound on the truncation error.

(|A_n| - 2*|B_n|*|tmax| - 3*|C_n|*|tmax|²) is a lower bound on the absolute value of the derivative. As it is, it can be negative which means that the derivative could be 0 somewhere so the approximation's quality is likely to be too low.

|<Quoted Image Removed>| is related to the "radius" that corresponds to a pixel.

|tmax| is the maximal distance between the reference point and any point of the rendered area.

I don't understand why the derivative being small is a problem.

I switched to this alternative which allows much more to be skipped (beyond one period) without affecting appearance adversely in my tests:

R_n*|tmax|^m+1 <= | $\Delta t$ |

The rationale is that if the truncation error in the Z plane is less than the size of a pixel in the C plane, should be fine (because Z values will spread out from the original C values, except in interior regions). If it looks fuzzy when I add distance estimation then I'll see what adding a 1e-3 factor does to it.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 16, 2016, 04:26:10 PM

@Quazor:
Glad it worked. Thank you very much.

The formulas were derived 5 months ago (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/msg91505/#msg91505). I'll have to re check the formula for arbitrary m before posting it.

@claude:
Thank you for looking at it. :)
I think Rn can still be used when zooming towards a good reference point because the tmax in the test can be different from the one used for the computation of Rn. It would be much smaller as one zooms in.

I realize now that the test have to be changed: The derivative necessarily becomes 0 at some point inside the minibrot. Therefore, the lower bound of the absolute value of the derivative -as computed- will necessarily be negative after 1 period or so. What we actually need is a lower bound of the magnitude of the derivative outside the set... not easy if ever possible. For test purposes on can still do the test per pixel to see where the series approximation error becomes too big.

How many iterations doest it skip if stopping at when R*|tmax|==|a_m|? (that is the truncation error equals last term of the series approximation)

Quote from: Kalles Fraktaler on August 16, 2016, 02:07:31 PM

Seems tmax and <Quoted Image Removed> are limited to double precision, unless you are using some other datatype?

$\Delta t$ is very small so one can't use double precision.

PS: I was still writing when claude posted the previous message.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 16, 2016, 04:38:37 PM

Quote from: claude on August 16, 2016, 03:38:47 PM

I don't understand why the derivative being small is a problem.

I switched to this alternative which allows much more to be skipped (beyond one period) without affecting appearance adversely in my tests:

R_n*|tmax|^m+1 <= |<Quoted Image Removed>|

The rationale is that if the truncation error in the Z plane is less than the size of a pixel in the C plane, should be fine (because Z values will spread out from the original C values, except in interior regions). If it looks fuzzy when I add distance estimation then I'll see what adding a 1e-3 factor does to it.

Great!

The derivative is there because (to be accurate in the error estimation) the image of the area of a pixel by the series approximation should be always bigger than the area of the truncation error at that pixel. Unfortunately, the derivative vanishes inside minibrots after 1 perod or so.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 16, 2016, 04:59:28 PM

Quote from: kalles

Seems limited to double precision, unless you are using some other datatype

im using extended doubles for all these, i assumed you guys are too?

Quote from: claude

once I get the truncation error stuff for the derivative's series approximation sorted

you are talking about for distance estimation? im using your DE method (without checking the error on it specifically) and it seems fine so far.

Quote from: claude

seems it skips at most 1 period of the reference

all i know is im skipping more than i ever have :hmh:
skipping most iters at most locations, except when getting close to a minibrot where the number of skipped iters levels off, which is the behavior i am used to anyway

edit: actually i just remembered i had optimized my greater than less than operators on my extended double type to not bother checking the sign, since i was only ever checking positive magnitudes and such.. maybe that was affecting things :embarrass:

ok after fixing that i can see what you are talking about now, how it gets stuck at the same iter. :sad1:

Quote from: claude

I switched to this alternative which allows much more to be skipped (beyond one period)

better, but still very conservative

so i went ahead and changed both sides of knighty's original comparison to the absolute values to mimic what i was accidentally doing.. i guess its not a proper thing but like i was saying its getting me further than ive been getting with other methods, without causing improper results... might that indicate some potential more proper alteration that will work at least as good?

edit: looks like it is still getting stuck on the same iter after zooming in to deep enough minibrots. maybe with this it is getting stuck after a couple periods worth instead of 1 or whatever..
though im remembering you guys have said that increasing the number of terms gets you more periods' worth to skip, so maybe im just exhausting what 3 terms can do and this would still be pretty good with more terms. i need to decipher claude's math blob so i can try more than 3 terms.. claude, maybe you can throw an abs() around your implementation and see if it does good things?

oh, looks like claude's example code implements arbitrary terms. i'll have better luck deciphering that

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 16, 2016, 11:27:00 PM

Ok!
I see now what is hapenning. :)

Just don't give up the first time the test fails. Only if it fails two times in a row. This is because when the derivative vanishes a some iteration N, it will recover at iteration N+1 unless there are other minibrots that show up nearby. in that case use the coefficients computed just before the first fail (that is at N-1).

That also may explain why sometimes the series approximation doesn't work correctly while it could be done with much higher skipped iterations number: at the first fail of the test, because the magnitude of the derivative is low (over some rendered area in fact), the quality (conditionning) of the series approximation is bad.

If I'm not mistaken, the skipped number of iterations will be roughly a multiple of the period of the minibrot that's near or that contains the reference point. Also, the number of skippable iterations can't be less than the minimal iteration. The more coefficients in the series approximation the closer we get to that limit. The series approximation will tend to approximate the shape of MB shape. I gess the closer we get to the limit (minimal iterations) the less effective the series approximation will be. IIRC, These behaviors are already known. I believe that now we have a good mean to be sure about when to stop skipping.

And thank you very much quazor and claude.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 17, 2016, 02:15:55 AM

Quote from: knighty

This is because when the derivative vanishes at some iteration N, it will recover at iteration N+1

could one use this as a cheap way to infer the period?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 17, 2016, 03:03:32 AM

Quote from: claude on August 16, 2016, 03:38:47 PM

Especially in the higher order Mandelbrot equations, as Kalles Fraktaler alluded to, there can be like 20 terms in the 4th and 5th order equations when you factor in the deltas and expand the expression.

Suppose I'm rendering an image at a zoom depth of e1000. Those delta values are going to be approximately 1e-1000 or smaller in size. The arbitrary precision necessary to calculate a depth of e1000 only needs to be marginally smaller. Maybe the software is using say 1e-1100 for the least significant bit.

Well the full expanded perturbation equation for higher orders is going to have a bunch of terms with deltaX or deltaY squared or even cubed or higher. This means the relative magnitude of these terms is like 1e-2000 or 1e-3000 when you only need 1e-1100 precision to avoid precision errors. So why calculate these sums in the equation when they will just be discarded anyway? Seems like a waste of computational resources.

So unless it somehow causes glitch issues, I would be in favor of discarding any terms with squared or cubed or higher order deltas, unless it specifically causes artifacts or glitching.

EDIT: Just wanted to thank all you programming gurus out there making lightning fast Mandelbrot and related formula deep fractal zoomers. Keep at it! O0

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 17, 2016, 11:34:26 AM

Quote from: stardust4ever on August 17, 2016, 03:03:32 AM

The things you describe above is what MM is doing and is why it is often 10 times faster than KF instead of just 4 which comes from SIMD.
However it probably also explains the unsolvable glitches MM suffers from. I've tried that path but eventually gave it up

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 17, 2016, 10:28:38 PM

:embarrass:
Forget about my previous post. I was wrong about the "Just don't give up the first time the test fails"... at least. :hurt:

I've managed to compile claud's code (awesome BTW) and tried the double check, aaaand... it doesn't work! :hurt: :hurt:

Now I'm confused. Even when setting the derivative norm to 1 in the test, The skipped number of iterations Grows very slowly with zoom factor (beginning at around 1e-30). The only explanation I have is that the error estimation becomes really too conservative at some point.

More investigation is needed... :D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 18, 2016, 03:01:28 AM

Quote from: knighty

Forget about my previous post. I was wrong

dont give up! there just has to be a way to make this or something similar to this do the right thing :'(

Quote from: claude

note this includes some terms twice multiplied in opposite orders, could be implemented by multiplying by 2 instead of repeated calculations

this is one reason i like to see a thing written all the way out, so i can try to visualize the patterns and skip right to implementing some optimized code. speaking of which, i dont suppose one of you could post another such example or two of the form

R_n+1 = |B_n|² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

perhaps at say m = 4 or 6 or something. trying to extrapolate from the math thing or the example code of the math thing makes my brain hurt and my eyes glaze over :banginghead:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on August 18, 2016, 11:27:56 AM

Quote from: knighty on August 16, 2016, 11:27:00 PM

If I'm not mistaken, the skipped number of iterations will be roughly a multiple of the period of the minibrot that's near or that contains the reference point. Also, the number of skippable iterations can't be less than the minimal iteration.

Quote

The more coefficients in the series approximation the closer we get to that limit. The series approximation will tend to approximate the shape of MB shape. I gess the closer we get to the limit (minimal iterations) the less effective the series approximation will be. IIRC, These behaviors are already known. I believe that now we have a good mean to be sure about when to stop skipping. And thank you very much quazor and claude.

Yes, the reference period rule is quite safe when excluding pixels that go corrupt due to rounding issues independent of skipping and when not in the direct neighbourhood of a/the minibrot.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 18, 2016, 02:08:31 PM

Quote from: quaz0r on August 18, 2016, 03:01:28 AM

dont give up! there just has to be a way to make this or something similar to this do the right thing :'(

this is one reason i like to see a thing written all the way out, so i can try to visualize the patterns and skip right to implementing some optimized code. speaking of which, i dont suppose one of you could post another such example or two of the form

R_n+1 = |B_n|² + 2*(|z_n|*R_n + |A_n|*|C_n|) + 2*|tmax|*(|A_n|*R_n + |B_n|*|C_n|) + |tmax²|*(|C_n|² + 2*|B_n|*R_n) + 2*|tmax³|*|C_n|*R_n + |tmax⁴|*R_n²

perhaps at say m = 4 or 6 or something. trying to extrapolate from the math thing or the example code of the math thing makes my brain hurt and my eyes glaze over :banginghead:

:)
I'm not giving up. This is a very interesting and challenging problem. There are a lot of things to learn.

For the formula, I haven't yet had time to check it. You can still use claude's formula for now.

Quote from: hapf on August 18, 2016, 11:27:56 AM

More, not less. If one uses the same skip for all pixels, yes. The question is if a variable skip could do better. I think so but I have not found an efficient and safe way to decide skip for every pixel separately.Yes, the reference period rule is quite safe when excluding pixels that go corrupt due to rounding issues independent of skipping and when not in the direct neighbourhood of a/the minibrot.

Thank you.
I was meaning "same skip for all pixels".

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 18, 2016, 04:44:36 PM

Quote from: hapf

The question is if a variable skip could do better.

when i was experimenting with different stuff a while back i had implemented a system of deciding on an initial iteration as usual, and then for each point going up or down in increments of say 50 iters or whatever, depending on whether the starting point tested good or bad. it seemed to work and performed okay, though it didnt actually solve other issues i was having at the time so i decided to go back to the simpler standard approach.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 20, 2016, 11:18:44 PM

There is still hope! ;D

Here are the formulas I get. Here, in a_iⁿ and Rⁿ, n is an index not an exponent. In tⁿ, n is indeed an exponent.

We have:
$[Z_{n}] = z_{n} + \sum_{i=1}^{m}{a_{i}^{n} t^{i}} + R^{n} t^{m+1} [E]$
and
$[Z_{n+1}] = z_{n+1} + \sum_{i=1}^{m}{a_{i}^{n+1} t^{i}} + R^{n+1} t^{m+1} [E]$

Then:

$a_{1}^{n+1} = 2 z_{n} a_{1}^{n} + 1$

$a_{k}^{n+1} = 2 \left \{ z_{n} a_{k}^{n} + \sum_{i=1}^{\left \lfloor \frac{k-1}{2} \right \rfloor} {a_{i}^{n} a_{k-i}^{n}}\right \} + \left \{ \left ( a_{\frac{k}{2}}^{n} \right )^{2} \: if\: k\: is\: even \right \}$

Where:

$2\leq k \leq m$

$\left \lfloor k \right \rfloor$ means floor(k)

Now for the truncation error:

$R^{n+1} = \Xi \left \{ \sum_{k=m+1}^{2 m} t^{k-m-1}\left [ \left ( 2 \sum_{i=k-m}^{\left \lfloor \frac{k-1}{2} \right \rfloor} a_i^n a_{k-i}^n \right ) +\left ( \left ( a_{\frac{k}{2}}^n \right )^2 \:if\:k\:even\right )\right ] + 2 R^n[E]\left [ z_n + \sum_{i=1}^{m} a_i^n t^i \right ] + (R^n)^2 t^{m+1}[E]\right \}$

Where $\Xi \left ( p\left ( z \right ) \right )$ is some function that gives the max value (upper bound) for $|p\left ( z \right )|$ over the interval {z | |z|<tmax}. It is computationally expensive to get a precise value of the upper bound. We need some estimation that is not too conservative. Previously, I did this:

$R^{n+1} = \sum_{k=m+1}^{2 m} |t_{max}|^{k-m-1}\left [ \left ( 2 \sum_{i=k-m}^{\left \lfloor \frac{k-1}{2} \right \rfloor} |a_i^n|| a_{k-i}^n| \right ) +\left ( |a_{\frac{k}{2}}^n|^2 \:if\:k\:even\right )\right ] + 2 R^n\left [ |z_n| + \sum_{i=1}^{m} |a_i^n| |t_{max}|^i \right ] + (R^n)^2 |t_{max}|^{m+1}$

By inspecting the values of R while doing experiments thanks to claude's programm, I noticed that it doesn't "blow up" prematurally and it is quite a good estimation of the trucation error. A better way to compute R which is slightly less conservative:

$R^{n+1} = \sum_{k=m+1}^{2 m} |t_{max}|^{k-m-1} \left | \left ( 2 \sum_{i=k-m}^{\left \lfloor \frac{k-1}{2} \right \rfloor} a_i^n a_{k-i}^n \right ) +\left ( (a_{\frac{k}{2}}^n)^2 \:if\:k\:even\right ) \right | + 2 R^n\left [ |z_n| + \sum_{i=1}^{m} |a_i^n| |t_{max}|^i \right ] + (R^n)^2 |t_{max}|^{m+1}$

Sorry... I couldn't make it simplier.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 20, 2016, 11:43:21 PM

Note about claud's code:
To compile it one needs QD library downloadable here: http://crd-legacy.lbl.gov/~dhbailey/mpdist/
On 32bit systems one have to add the code for fixing floating point precision:

Code:

int main(int argc, char **argv)
{
	//from qd_test.cpp
	unsigned int old_cw;
	fpu_fix_start(&old_cw);
	//end from qd_test.cpp

	.......

	//from qd_test.cpp
	fpu_fix_end(&old_cw);
	//End from qd_test.cpp
  return 0;
}

I had a lot of fun playing with it. ;D

It happens that the truncation error formula I suggeted gives very good results. The problem comes from the estimation of the lower bound of the absolute value of the derivative: It is toooo conservative! I believe such lower bound is necessary because using only the truncation error is not sufficient.

While varying the number of iterations of the series approximation, one can notice that it usually breaks down suddenly. For example the first picture ( zoom level: 1E-45, m=7, series approx iterations 2808) is correct. The second one ( zoom level: 1E-45, m=7, series approx iterations 2809) with just one more iteration, is very different. Moreover, if one inspects the pictues, the number of "rays" and blobs in the little "wheel" are different.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 21, 2016, 09:53:07 PM

I've tried the per pixel test AAAaaannnddd... It works! :worm:
Here, for each pixel we compute:
error(delta) = R*|delta|^m+1/(|SA'(delta)| * dt)
The error is given in 0.5 pixel units.

This is the location "Adventurous forest" at zoom factor 4E47 (in kalles units). I used m=8. The first picture shows the result with 7745 SA iterations. The second with 7746 SA iterations. The red shades encode the error in delta space pixel units. At the center, that is at the reference point, it is 0. The first full red color from the center means 0.5 pixel error then 1 then 1.5... as we go further.

(https://lh3.googleusercontent.com/fwhUlpBA8PkZ2crs1HXF47p27YMOPiAwzA9qMPyUA_y-WtP8-IvlcZgPVb1TRhvQKDdGhnM5mQyhRfd_tUGBm3Atq6NmpgH-Ddx2qbsrv2XB7UNHBEkEOeHaqzEC-vH8vSpTqpZie5Kin6Tg1biRvXyQrPEjJXCNsDXcKR8fcEDnDFKAa4cL0mOA0pNQj3E8Oep2ylQ9QPxpBRainsOapon5w-UQ01hZdOpjXxhEj2YDC262xJJyMOBzdgX14dZtUF-cAQPhpYkc4AQqacO-QMeOmqFq_VWaw3DIWSaagc-QUWW5ex-s1PpkCbEtNkJqAfiDyPBnfGYb3Ecsy0ZhykD64mOLjmhcsdAXlYGLJHT9p0VBRlraGXOujBCSdTaqYNoJie3qU02zwQMrQdr8TdBYt85_7nvt3rJQuX8ie3CJZDlhIOFM0TjQy49ydqt8qhF_Dk86PFt7uWzA3bYMAi0B466YSCkzqrAl7V86TKah6lxpbQcuYANFRow132aAxVeGpJnrSriMlZ7pr5jAvHNmrz94B7oaZMmQG1m2goyBnQWyOXSvcRAY1ts5H87lnHS3a4h7kROYUH23GytKNpWVI3m6DDM=w640-h360-no)
link (https://goo.gl/photos/2A1imLRhFLXCPdQA8) In case there is no picture shown.
Notice the red shades at the upper left and lower right corners... and around the red blobs.

(https://lh3.googleusercontent.com/Gfl_Q89D7VBWVD10tuFQX4QTFkHQ5MissX047sYEsQ_D5jxrOvFoFYftCHIW45wfNh11JfYVjVDSZWtJEOAtYfZ9fUMOtpPbe8SewMUOzvKYCsHAZ4YLRLGjdrpbYcs6PuHxw1jPQjFAde2b8MTl9IEvXiA9uDt9ibVHyOhMcr50TRPujfqqNUguJr_HOEUy7NLW9YsNQIwApLjTGflsKpV-QIZC2moehOjQYWRUNrhPlqyuAVJbNdg_3sOrpnGlKa7IFF3v6ZJR-N1rWw4WZgDV1zmjW9IvjKfZsIwTiTd6zDLxk_jx3qtlMXL4JYxhm_FMZyt6uZzhfdGnWYRR8LETGNa1Pg8Jk7iuq8WDb9mLIZFVHgfuLx1zRmOqsEJzne1T1ec-L03_OE0CIAIMOIvG8ECS8MkHjiR5xeRXCW9WXk2DpgzEURXNse_E_V6T9TKpLfoiJd-cE602Y_C5KSBQn5Y36Eqc7JzrglHPbj4eEWiBs0MXcDVnA0_yIWSrL83Gb_cBifJ5Fumz-sjDxBE0AjLGFVDPSRiHZfE8a9JRmZ6nNQuf_3JYyhQrxt-xUXiU0eO-CJ6yzxbNx-bCukJYOHu1YiY=w640-h360-no)
link (https://goo.gl/photos/AGxYsC8Xw2bar4Jd8)
Notice that:
   - the error jumps while we added only one iteration.
   - the error is maximal where there was a blob.
   - because the estimation of the truncation error is conservative. The fractal is not deformed too much (but it is).

Here is a little gif animation shoing what happens between 7100 and 8000 SA iteration. In the last picture of the sequence there are no red shades, not because the errors were not detected but because the estimation of the truncation error overflowed.
(https://lh3.googleusercontent.com/3I6Cdta3ERLFNaj_KFR91xR-_uoA5MHk-AvyYgIp44E-YKandFUdcIL-zr8NWE2Z7CrIgkuzi1t4caViThYz4zvsRS2sdkNjBk7_cRPcejIrS8msu4N_RNL8mjn0CQQmaRR6_i3OosWqVtIWRJhtD9hRYA7P2w0_VWSvfziRz9EvxUCE4LwzQQyia9OTlkOyUZ2Mepk6LtJEQDu0t3dAehV5aIv2QhQNunF4zLyisSKfPdyunGaYQtAFTGgLHSDI_aCG957mlNQyDSFsqclznFuE_C94PR2d6mti5ZHePkv0vOJsHhxKY50WnO0ub4NET35Gqpm_Ux1jb-_BQnDrfrOL_MEtZe3chs1pRaWemd5Cmp7ch_VIJcIGhEaNozzyx5lr_sH3D8mVAwT-yMlU1UP6gQUO9cwU4Fl2aMv-HdX3JYtyziUpnEjC6vxbmKI4LS2ibm7i8rd8z-IjtgQ6giAaPMz2Ev3UcYpkNTgzKCcH_mxeBGnUXd6Ovilus6Z7es80i5ekHC62L7oI5cnzN0l3QIuFnf-NKaZvsXpNxefFFhZd72MOzVLnkerdX4NxfJwx8DznZBL4-Z0TloUB9opEVJIGzfw=w640-h360-no)
[urlhttps://goo.gl/photos/QkXCjVoBaMEYhocT9]link[/url]

Finally, sequence for the same location at 8E40 (kalles zoom factor) with SA iteration going from 5630 to 6470.

(https://lh3.googleusercontent.com/D_xHOXstcWjXmNZYlzDLp4JXtBChGOy973BR6DfEgoxjre2isQv7PUdI24mq-MJktvdP4MxyoAK2iJt9L1SzLbrrCVOxi5Fop_kvRgeyK61S6hXjnLEAJdUSaJBdKdPxj3FvP_FktBF6xQ4TP4tiBa2Krvk8uvrF86sfDLm5CY5dW29SxQebYDMvbrw7FyWEcT1KpIUFeVZAUNrBjB9C7ozSyxaIUdfO4lt91tFB2Jyg6lzAF8clQacZVc_zWW5fqtt7qJhvJihbVB-QpTpS3urtQLuJkE-BPa37HfxHxyD8kVtMwrDZCRLTGNp6kJcFH4ET4sg0-W7V9gEz3eRtD4KpjFSC5IgSWtWP_JQHkwPS3Qe3KxAlpfjiNbtVrXCoquqPkEbjJ13yRKICVQoqVeH9ZvbpmnnITfuK-RYlkjFjWnZL_nm2mbFR7idkOJ3NDWISyIMFxxwMRb5BZk0h4X1hwfZmYlufNb88fcCsc9q7M13OqcElxds1g_kgxfkHao70qv7icQ89TbF93XPRAu8h5gdLvIoRSxmyXtQhaRlGBM7AtQwFOiAZ4NQ-yOecuGECmiXg05dKsumwIgKhZ596gkvp9VA=w640-h360-no)
link (https://goo.gl/photos/F77U4k7i1V78bUjb8)

And finally the source code attached.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 22, 2016, 09:57:56 AM

Seems that you are on to something :)

Here is a little test I made on KF for this location at 4E47 (640x360 pixels):

Terms	Skipped	Time
0	0	5.928
3	6756	1.802
5	7156	1.309
10	7551	1.079
30	7764	0.942
50	7891	1.889
100	7943	2.713
1000	7950	2:41.400

So, for this location it is possible to skip 7950 iterations and still get an identical image as if no iterations are skipped.
No deformation occurs on KF...

Addition
For the second location, at 8E40, KF is not able to skip more than 6451 iterations even if 1000 terms are used. So that is about the limit of how much that can be skipped. And again, no deformation occurs

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 22, 2016, 03:00:15 PM

Quote from: Kalles Fraktaler on August 22, 2016, 09:57:56 AM

Seems that you are on to something :)

Here is a little test I made on KF for this location at 4E47 (640x360 pixels):

Terms	Skipped	Time
0	0	5.928
3	6756	1.802
5	7156	1.309
10	7551	1.079
30	7764	0.942
50	7891	1.889
100	7943	2.713
1000	7950	2:41.400

:)
I couldn't go beyond 50 terms because of overflows in the computation of R. It occurs when R reaches 1e2466 . Then when computing the absolute value there is a squaring which causes the overflow. R*tmax^(m+1) is still very small though.

The first picture attached is with 7940 skipped iteration and the second with 7950. Both use 50 terms. The one with 7950 terms is extremely deformed at the edges. Maybe round off errors?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 22, 2016, 06:53:19 PM

Quote from: knighty on August 21, 2016, 09:53:07 PM

I've tried the per pixel test AAAaaannnddd... It works! :worm:
Here, for each pixel we compute:
error(delta) = R*|delta|/(|SA'(delta)| * dt)
The error is given in 0.5 pixel units.

Interesting. But as far as I can tell this doesn't help. We want a cheap way of determining for a whole region whether the series approximation is still valid, as the per-pixel test above is more expensive than simply doing a perturbed iteration.

The interval arithmetic SA' lower bound estimate is messed up because of the zero at the minibrot reference after one period, maybe it would be possible to do some maths to cancel out that zero? Or minimize over an annulus instead of a disc? Something like tmin = max(dt, minibrot size) and consider the annulus with radius tmin<=r<=tmax - I don't know enough interval voodoo to figure out if it's possible...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 22, 2016, 09:27:33 PM

Quote from: claude on August 22, 2016, 06:53:19 PM

It a WIP, many things still have to be done. :)

From the beginning, this test was meant for testing and debugging purposes. But it shows so far, that kalles fractaler's method, by checking at some points (mainly on the border), is good. It is even possible to take it further by using the proposed formula:

error(delta) = R*|delta^(m+1)|/(|SA'(delta)| * dt), I did a mistake in the previous post

R*|delta^(m+1)| can be estimated as the the absolute value of the difference between test and SA computed points.
SA'(delta) being the derivative of the SA polynomial is easy to compute
For dt and by security ;D , just take a small fraction of the pixels' width... say 0.01 pixel_width
... Then just take the max.

It is not bullet proof though.

Quote from: claude on August 22, 2016, 06:53:19 PM

The interval arithmetic SA' lower bound estimate is messed up because of the zero at the minibrot reference after one period, maybe it would be possible to do some maths to cancel out that zero? Or minimize over an annulus instead of a disc? Something like tmin = max(dt, minibrot size) and consider the annulus with radius tmin<=r<=tmax - I don't know enough interval voodoo to figure out if it's possible...

I doubt an annulus IA would be effective because of the addition... It is more or less a minkowski addition (https://en.wikipedia.org/wiki/Minkowski_addition). But who knows! Thank you for the idea.
There is another way that involves subdivision. The advantage is that it may give the regions where the SA is safe. The disadvantage is that it is maybe costly.

Anyway, the test doesn't have to be done each iteration. At 10000 max possible skipped iterations we can do it each 100 iterations. If we stop at 9900 we won't loose a lot of speed. There must be a good compromise.

I forget each time to mention that the estimation of R is related to interval taylor forms. See for example link (http://na.math.kit.edu/neher/preprnts/neher_2005_taylor_models_IMACS05.pdf).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 23, 2016, 10:55:38 AM

Very fascinating, watching the images break down. I guess one can assume then at any level, skipping iterations result in slight perturbations of pixels laying outside the centroid. Below some threshold, however, these perturbations are infinitesimally small and do not affect pixel accuracy of the image. Above some threshold, the image becomes visibly distorted and completely trashed.

Also on occasion it is possible to create fun images with glitches, such as this two frame animation I made with MM by limiting the precision of the perturbation float terms.
http://stardust4ever.deviantart.com/art/XX-Fun-with-Glitches-Animated-598140911

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 23, 2016, 11:19:19 AM

KF is comparing the result from SA with 8 pixels around the edge of the view.
From the begining the threashold was 1e-3.
However I found one location where this threashold was too high.
Even though I have only found location one so far, after playing with this for a couple of years, I changed the default threashold to 1e-5 (so that is mabye why I don't find them anymore)

This location is the location:

Code:

Re: -1.74974151205442298522942858901997753983231934503
Im: 0.000000724622003515946711698189333384986416781569
Zoom: 7.5E22

I know that more iterations can be skipped closer to the reference point than on the edge of a view.
So I had an idea of making more SA start values as you closer to the reference point you get.
However, this particular location contradicts my assumptions, since it reveals than less iterations can be skipped in an area inside the view.
So one would need to be able to go up and down in the number of skipp-able iterations as you go closer to the reference point...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 23, 2016, 01:07:24 PM

KF, I am curious what the difference in render time between your two images was? It also seems similar to MM where selecting a point of origin not in the centroid causes the glitch to occur.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 24, 2016, 09:26:57 AM

Quote from: stardust4ever on August 23, 2016, 01:07:24 PM

KF, I am curious what the difference in render time between your two images was? It also seems similar to MM where selecting a point of origin not in the centroid causes the glitch to occur.

Low tolerance and correct render with 702 skipped iterations (for the first reference) in 640x360 is 0.698 seconds.
High tolerance and incorrect render with 705 skipped iterations is 0.687 seconds, so it is about the same.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on August 24, 2016, 09:57:49 AM

I have found that especially with my 16k renders in kf that they sometimes have these kind of glitches. Do I simply have to decrease the number of terms to render a correct image? (This seems to work but takes more time due to the increase of iterations that needs to be calculated.)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 24, 2016, 05:04:37 PM

Quote from: TheRedshiftRider on August 24, 2016, 09:57:49 AM

Can you provide an example, because with "Low tolerance" active I haven't encountered any locations with glitches due to SA...?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on August 24, 2016, 06:29:09 PM

Quote from: Kalles Fraktaler on August 24, 2016, 05:04:37 PM

Can you provide an example, because with "Low tolerance" active I haven't encountered any locations with glitches due to SA...?

http://www.fractalforums.com/ultra-deep-mandelbrot/lightyears-away/
I have tried to render one of my contest images in 16000x9000. I had low tolerance active. I do not have an image of the glitch.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on August 24, 2016, 07:50:02 PM

I spent quite some time with this "how much can I skip" problem and in the end actual testing turned out to be the safest and reasonably efficient way (testing = compare skipped and not skipped values at a number of pixels). Analysing the behaviour of the series itself did not work out in the end because as the terms go up (and we usually want them to go up a lot due to the reference period rule) the contributions are spread around more and more in waves and it was unclear when to stop safely looking at contributions. The abrupt changes from ok to corrupted occur around period boundaries. They depend on pixel location and the reference used. And here is some probably new insight: Relevant period boundaries are not just the multiples of the period of the current reference, it's also all the other periods a pixel location is affected by, e.g. the partials. As far as I could see the boundaries from good to bad are always at a sum of multiples of the partials of the pixel. As one flies by a local minibrot the periods there become relevant and possible skipping goes down (when using a deeper down minibrot as reference). As one zooms further the local minibrot becomes less relevant again and only what one inherits from it in the partials can be relevant further down. Embedded Julia sets can further complicate this by adding corruption due to rounding errors independent of overskipping.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 24, 2016, 11:02:58 PM

Quote from: hapf

in the end actual testing turned out to be the safest and reasonably efficient way (testing = compare skipped and not skipped values at a number of pixels). Analysing the behaviour of the series itself did not work out in the end because as the terms go up the contributions are spread around more and more in waves and it was unclear when to stop safely looking at contributions.

this reiterates that the stop conditions which have been experimented with thus far are not truly proper methodologies, which is further evidenced by the fact that MM and KF can still be shown to produce glitches, the fact that KF even supplies a means to manually adjust the sensitivity of the stop condition, and the fact that this guy resorted to brute-force comparison of SA versus no SA to try to safely divine the right stop point. if we can really nail down something akin to what knighty has proposed, it would be absolutely huge and would elevate this whole endeavor out of the muck of perpetual experimental status. (and even if hapf's current approach is relatively better than other current approaches, it is still brute-force testing a handful of points in order to divine a course of action for the whole image.)

(https://i1.someimage.com/Mis0RTI.jpg)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 25, 2016, 08:54:24 AM

Quote from: hapf on August 24, 2016, 07:50:02 PM

Your description reminds me of my "Simply Awesome II" rework of my first deep Mandelbrot Zoom. Kalles Fractaller produced glitch frames precisely in two locations where the render path deviated from the centroid. I imagine the periodicity of the alternate render paths was very different from that of the central minibrot.
(http://orig14.deviantart.net/1da3/f/2014/301/2/a/simply_awesome_glitch_1_by_stardust4ever-d84guf2.png)
http://sta.sh/01aqqf7kg83r

(http://orig00.deviantart.net/6370/f/2014/301/e/7/simply_awesome_glitch_2_by_stardust4ever-d84guki.png)
http://sta.sh/017skb4ouloa

Ultimately I left the glitch frames in the video because I did not know how to fix them without potentially corrupting the iteration data. Here is the final result:
https://www.youtube.com/watch?v=vnUjXAIIcq0

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on August 25, 2016, 09:02:18 AM

http://www.gigapan.com/gigapans/177160
I found another example, when I rendered it I did not know but now I notice it has the bug as well.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 25, 2016, 04:07:52 PM

Quote from: TheRedshiftRider on August 24, 2016, 06:29:09 PM

http://www.fractalforums.com/ultra-deep-mandelbrot/lightyears-away/
I have tried to render one of my contest images in 16000x9000. I had low tolerance active. I do not have an image of the glitch.

OK, I found the glitch.
When rendering in 16000x9000 the number of terms is 252, which is exaggerating a lot but I haven't tried to render this big images.
I made some small 1280x760 renders with different number of terms.
The minimum iteration pixel on this location is 313467.
With 50 terms 305825 iterations are skipped, and the render is correctly, as the top cut-out shows.
With 100 terms 313088 iterations are skipped, and the left-pointing tip of the structure becomes fuzzy, as the second cut-out.
With 252 terms 313197 iterations are skipped, and the left-pointing tip becomes distorted.

Maybe KF should have a maximum of terms somewhere between 50 and 100...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 25, 2016, 07:40:38 PM

Quote from: kalles

Maybe KF should have a maximum of terms somewhere between 50 and 100

Quote from: hapf

Analysing the behaviour of the series itself did not work out in the end because as the terms go up the contributions are spread around more and more in waves and it was unclear when to stop safely looking at contributions.

kalles it sounds like this is probably what is causing your woes? since you are testing against points in your program, maybe if you try knighty's formula for testing against points it will work.

i think his formula for only analyzing the series coefficients to determine the skip amount is what there is still a question about, and his formula for testing against points is good to go?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 25, 2016, 09:22:28 PM

We can play dice roll with the numbers all we want; ultimately it is a game of risk (glitch) versus reward (speed).

It also happens that some of the most visually interesting extremely deep zoom locations are often worst case scenarios for guessing algorithms. :evil1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on August 25, 2016, 09:39:41 PM

Quote from: Kalles Fraktaler on August 25, 2016, 04:07:52 PM

Thank you for having a look at it. Yes I know 16k is large. I even had to decrease the terms to below ten to make it work. But I have not had time to do the complete render.

Quote from: stardust4ever on August 25, 2016, 09:22:28 PM

True :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 25, 2016, 09:42:47 PM

Sorry for the late reply. Busy @ work. :)
And still haven't done any thing for the test.

Quote from: quaz0r on August 25, 2016, 07:40:38 PM

(...) maybe if you try knighty's formula for testing against points it will work.

i think his formula for only analyzing the series coefficients to determine the skip amount is what there is still a question about, and his formula for testing against points is good to go?

Maybe not. I think It would work better for small number of coefficient. When it is large, the error may stay very small on most of the rendered area and quite big elswhere. The variation of the error goes faster as the number of SA terms is raised. In those cases, cheking on some points may not be sufficient.

The proposed formula (without interval arithmetic) is still useful because the derivative of the SA is important. When the absolute value of that derivative is small, a little error on the SA value may become very large w.r.t. pixel size. I mean if there if an error epsilon in the computation of a function f(x), the error Omega on x will be epsilon/f'(x).

For a bullet proof test, the interval arithmetic test is reliable. There is still some work to do in order to finish it even if for now we can use what we have for debugging purposes (it is far less costly than checking the difference between SA and perturbation at each pixel)... Anyway, so far it is promising: I was surprised to see that the estimation of the error is not too big, that is because IA methods are known to be too conservative. Also, even if it is expensive, in general one can skip more iterations with it.

Quote from: Kalles Fraktaler on August 25, 2016, 04:07:52 PM

OK, I found the glitch...

;D
I think those case (except maybe the last one) could be easily avoided by not systematically using the pixel at the center as the reference. A lazy approach may be more effective and faster: use the already found references (usually used in glitch correction) as much as possible. Even more lazy: Compute new references only when there are glitches. It is also possible to find (and/or refine) good refence points by using interval arithmetics (again ;D) and/or Newton root finding and it is not that slow.

Quote from: TheRedshiftRider on August 25, 2016, 09:39:41 PM

Quote from: stardust4ever on August 25, 2016, 09:22:28 PM

True :)

Yep!

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 25, 2016, 11:36:06 PM

Quote from: knighty

Maybe not. I think It would work better for small number of coefficient. The proposed formula (without interval arithmetic) is still useful because the derivative of the SA is important.

indeed, i simply meant within the scope of the "check against a point or handful of points in order to divine how much to skip for all points" approach, your formula should give more of a proper error estimate and ultimately fare better than the stop condition that people have discussed in the past, of simply checking the relative size of the terms. does that sound right?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 26, 2016, 02:01:53 AM

Quote from: quaz0r on August 25, 2016, 11:36:06 PM

"check against a point or handful of points in order to divine how much to skip for all points"

Fractals are divine creatures... :angel1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 26, 2016, 04:33:03 PM

Quote from: quaz0r on August 25, 2016, 11:36:06 PM

Yes I agree that even though lowering the maximum terms to 50 would solve TheRedShifter's location, there will most probably be other locations that requires even lower number of terms.
And unfortunately I don't think there is a way to validate the correctness of a pixel after the SA-terms is applied to it?
I hope you follow what I meant?
- First, calculate the SA coefficients and the skippable iteration number by checking against a handful of points
- Second, each pixel starts by applying the coefficients and start from the skippable iteration number - is there any validation possible here?
If it is, one could mark these pixels as glitches and redo them with a closer reference, in the same way as Pauldelbrot's glitchdetection... :pray2:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 29, 2016, 10:10:27 AM

Ok!

After trying a lot of alternatives, I came back to the simplest one, the one I was thinking would not work well but... It worked!
In the test:

R * |t_max|^m+1 <= |SA'(t_max)| * |dt|

The formula proposed for the lower bound of |SA'(t_max)|:

$\left |a_1 \right | - \sum_{i=2}^{m} i \left |a_i \right | \left |t_max \right |^{i-1}$

works only for one period of the reference point. That is because a₁ becomes very small.

The formula:

$max_{k}(k \left |a_{k} \right | \left |t_{max} \right |^{k-1}) - \sum_{i=1 | i\neq k}^{m} i \left |a_{i} \right | \left |t_{max} \right |^{i-1}$

(that is, we subtract from the max term the remaining ones.)

Solves the problem.

It is still a crude estimation. It shouldn't fail but it is somewhat conservative. Some times it gives almost optimal result, some other times... less optimal. Nothing dramatic though. For example, the location given by claude in m.cpp, is really difficult: at 1E-47, the test (even the per pixel test) fails way before the errors become visible.

Of course, when the test fails, it is possible to repeat it on smaller areas. The simplest is to redo the test with smaller values of t_max to get the area (around the reference point) where the SA is still accurate.

This is not the end of the story. Using the derivative of the SA is actually just an approximation. The full test formula is:

$\left | K t^{m+1} \right | \leq \left | SA(t+dt) - SA(t)\right |$

where dt corresponds to the circle of radius |dt|.

So far, the test uses a Taylor expansion of (SA(t+dt) - SA(t)) of the first order. Higher orders are also possible. It is maybe even possible to use the above formula as it is. Anyway, that would be too complicated and with little benefit IMHO.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 29, 2016, 08:26:30 PM

Quote from: knighty on August 29, 2016, 10:10:27 AM

After trying a lot of alternatives, I came back to the simplest one, the one I was thinking would not work well but... It worked!
...
(that is, we subtract from the max term the remaining ones.)

Awesome!

I did a quick test, your refined method described in this post skips 3544 iterations with no apparent ill effects. The period here at this location is 927. So significantly more than one period, nice.

Code:

./a.out --width 1920 --height 1080 --maxiters 65536  --precision 100 --output out.ppm \
--re -1.94021202906904108793666462798106635116194041886835880862863e+00 \
--im 1.47021750196972546090052860958643781234133289155702935853549e-04 \
--radius 1.4349296274686127e-42

Code attached, changed to use Boost Multiprecision (based on MPFR) for high precision (shouldn't be too hard to revert it back to using QD if necessary), with rudimentary command line argument parsing. Also renders with exterior distance estimation - no check on the validity of the series approximation for the derivative is performed, just fingers crossed at this point... I guess I should add my glitch correction method to the example code to make it almost complete (the final step would be interior distance estimation).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 29, 2016, 11:20:15 PM

added my own method of recursive glitch solving to the code, hopefully it is useful to see a simple implementation without multithreading optimisations getting in the way of understanding.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 30, 2016, 02:16:20 AM

Quote from: knighty

The formula proposed for the lower bound of |SA'(t_max)| works only for one period of the reference point. That is because a₁ becomes very small.
Subtracting from the max term the remaining ones solves the problem. Some times it gives almost optimal result, some other times... less optimal.

good work! a few thoughts:

are we in fact saying that if the value for the lower bound of |SA'(t_max)| becomes negative, this Always represents an inadequate analysis of the series? If yes, might we take your idea of subtracting from the largest term the remaining terms one step further and say, subtract from the sum of one or more of the largest terms the remaining terms, such that the result is a positive value?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 30, 2016, 05:48:36 PM

Quote from: quaz0r on August 30, 2016, 02:16:20 AM

are we in fact saying that if the value for the lower bound of |SA'(t_max)| becomes negative, this Always represents an inadequate analysis of the series? If yes, might we take your idea of subtracting from the largest term the remaining terms one step further and say, subtract from the sum of one or more of the largest terms the remaining terms, such that the result is a positive value?

No, not always. The lower bound formula is crude, very conservative. If you take a polynomial p(z) and set the magnitude of z to a constant value, you get something like a spirograph curve. Getting the smallest distance from this curve to the origin requires solving a polynomial equation. That is why the lower bound is useful: it is much cheaper. It works very well in general but unfortunately in the case of the location given by claude, it is too conservative and makes the test stop around 3544 while one can go to 4800 or 5000 (depending on m). IMHO, the lower bound and/or using the 1st derivative only, is inadequate in that case. A "higher order test" is needed. Which means more work/ideas needed. :)

Quote from: claude on August 29, 2016, 11:20:15 PM

added my own method of recursive glitch solving to the code, hopefully it is useful to see a simple implementation without multithreading optimisations getting in the way of understanding.

Indeed! It wouldn't have been possible to me to do any test without your code. Thank you very much!

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 31, 2016, 01:11:58 AM

$R^{n+1} = \sum_{k=m+1}^{2 m} |t_{max}|^{k-m-1} \left | \left ( 2 \sum_{i=k-m}^{2 m} a_i^n a_{k-i}^n \right ) +\left ( (a_{\frac{k}{2}}^n)^2 \:if\:k\:even\right ) \right | + 2 R^n\left [ |z_n| + \sum_{i=1}^{m} |a_i^n| |t_{max}|^i \right ] + (R^n)^2 |t_{max}|^{m+1}$

just curious, earlier it was written as |tmaxⁿ|, but according to this it seems to be |tmax|ⁿ. should these be equivalent or should it be one or the other?

also,

$2 \sum_{i=k-m}^{2 m} a_i^n a_{k-i}^n$

this seems weird to me... for instance at m=3 and k=4, this seems to give 2(a₁a₃ + a₂a₂ + a₃a₁ + a₄a₀ + a₅a_-1 + a₆a_-2). should that 2m instead be m ?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on August 31, 2016, 03:50:24 AM

Quote from: quaz0r on August 31, 2016, 01:11:58 AM

(http://www.fractalforums.com/cgi-bin/mimetex.cgi?R^{n+1}%20=%20\sum_{k=m+1}^{2%20m}%20|t_{max}|^{k-m-1}%20\left%20|%20\left%20(%202%20\sum_{i=k-m}^{2%20m}%20a_i^n%20a_{k-i}^n%20\right%20)%20+\left%20(%20(a_{\frac{k}{2}}^n)^2%20\:if\:k\:even\right%20)%20\right%20|%20+%202%20R^n\left%20[%20|z_n|%20+%20\sum_{i=1}^{m}%20|a_i^n|%20|t_{max}|^i%20\right%20]%20+%20(R^n)^2%20|t_{max}|^{m+1})

While I have a very advanced knowledge of complex math, infinite series and such are beyond me. This is why I flunked advanced Calculus! Carry on... :tongue1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 31, 2016, 11:04:47 AM

Quote from: quaz0r on August 31, 2016, 01:11:58 AM

<Quoted Image Removed>

just curious, earlier it was written as |tmaxⁿ|, but according to this it seems to be |tmax|ⁿ. should these be equivalent or should it be one or the other?

also,

<Quoted Image Removed>

this seems weird to me... for instance at m=3 and k=4, this seems to give 2(a₁a₃ + a₂a₂ + a₃a₁ + a₄a₀ + a₅a_-1 + a₆a_-2). should that 2m instead be m ?

Oops! it is a copy past mistake! :D :embarrass:
It should be : $2 \sum_{i=k-m}^{\left \lfloor \frac{k-1}{2} \right \rfloor} a_i^n a_{k-i}^n$
I'll make the corrections to the previous post.

In the other hand we always have : |zⁿ| = |z|ⁿ

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 31, 2016, 12:28:46 PM

Quote from: claude on August 29, 2016, 11:20:15 PM

added my own method of recursive glitch solving to the code, hopefully it is useful to see a simple implementation without multithreading optimisations getting in the way of understanding.

claude, I think your render is not correct.
You may have encountered the distortions near the edges as was showed by knighty.
I attached about the same location rendered in KF that is able to skip 3407 iterations with 126 terms.
Even with 1000 terms KF is not able to skip more than 3509 terms.
Sorry to spoil your progress... :(

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 31, 2016, 12:43:22 PM

indeed, i get the same render as kalles

Quote from: claude

skips 3544 iterations

this would certainly be the right number of iters to skip though if possible, as the min iter i get for this image is 3554. ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 31, 2016, 12:59:53 PM

Quote from: quaz0r on August 31, 2016, 12:43:22 PM

indeed, i get the same render as kalles

this would certainly be the right number of iters to skip though if possible, as the min iter i get for this image is 3554. ;D

I think 3544 is too much near the edges.
I assume this is because of limited precision.
I guess it would be possible to skip all the 3554 only if the SA is calculated with the same precision as the reference of e42.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on August 31, 2016, 01:13:38 PM

Quote from: quaz0r

if possible

Quote from: kalles

I assume this is because of limited precision. I guess it would be possible to skip all the 3554 only if the SA is calculated with the same precision as the reference of e42.

since the series approximates the delta instead of the whole value, i think the number of terms in the series is the only limiting factor? with infinite terms i suppose you could get right up to within the min iter... though maybe as you get close the delta would indeed require more precision. could that theoretically be a limitation on analyzing the coefficients only versus the old way of actually testing points? i think the coefficient analysis should give a theoretically proper stopping point, though perhaps precision loss could potentially occur prior to this point? ie this is what the automatic perturbation glitch detection does, detects catastrophic loss of precision, but i have never heard of anyone implementing such a check for the series approximation. would it go on to be detected by the perturbation glitch detection? or possibly get through undetected, which would result in went-too-far-with-SA style incorrectness.

another thought: if SA precision loss was indeed an issue to be accounted for, and you added a check for it, perhaps this information could then also be used to provide feedback about how many series terms were actually useful up to the point where you had to bail due to precision loss?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on August 31, 2016, 02:29:54 PM

Quote from: Kalles Fraktaler on August 31, 2016, 12:28:46 PM

claude, I think your render is not correct.
...
Sorry to spoil your progress... :(

Well spotted! Oh dear :(

EDIT: I found the problem - my code was using a too-small tmax value (half the imaginary diameter of the image). Increasing the tmax by a factor of 4 gives a correct render it seems! This skips 3294 iterations with 16 terms, using knighty's first version of the R calculation (will see how the updated R iteration affects things next).

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 31, 2016, 04:05:41 PM

Quote from: quaz0r on August 31, 2016, 01:13:38 PM

:)

since the series approximates the delta instead of the whole value, i think the number of terms in the series is the only limiting factor? with infinite terms i suppose you could get right up to within the min iter... though maybe as you get close the delta would indeed require more precision. could that theoretically be a limitation on analyzing the coefficients only versus the old way of actually testing points? i think the coefficient analysis should give a theoretically proper stopping point, though perhaps precision loss could potentially occur prior to this point? ie this is what the automatic perturbation glitch detection does, detects catastrophic loss of precision, but i have never heard of anyone implementing such a check for the series approximation. would it go on to be detected by the perturbation glitch detection? or possibly get through undetected, which would result in went-too-far-with-SA style incorrectness.

another thought: if SA precision loss was indeed an issue to be accounted for, and you added a check for it, perhaps this information could then also be used to provide feedback about how many series terms were actually useful up to the point where you had to bail due to precision loss?

I tried with 10,000 terms, which took more than an hour to calculate and resulted in 3530 skipped iterations :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on August 31, 2016, 06:51:39 PM

The value of tmax is critical. It must be the distance from the reference to the farthest corner of the rendered area. If less, it will go too far in skipping.
In the other side the value of dt is much less critical.
In this particular location, with 16 terms, the test gives exactly the maximum iteration skip possible: 3298. With 32 terms, the max possible skip is 3380 while the test still gives 3298... strange! maybe it is the lower bound of the derivative that is preventing it to go further.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on August 31, 2016, 11:53:34 PM

Even though you are able to achieve a theoretically accurate way to find the highest amount of skippable iterations in a radius of the most farther point from the reference, which is a good improvement, can you be sure that you will capture totally entrapped areas within this radius where only a lower amount of skippable iterations is possible?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on September 01, 2016, 09:50:20 AM

Quote from: Kalles Fraktaler on August 31, 2016, 11:53:34 PM

I guess not because we are talking about fractals. ^-^

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 01, 2016, 04:24:54 PM

Quote from: Kalles Fraktaler on August 31, 2016, 11:53:34 PM

I'm not sure I understand your question. The whole thing is about having a guaranteed number of skipped iterations as to not have any deformation and that, over the whole rendered area. This guaranteed number will be always less or equal to the max skippable iteration number that is possible -without getting any deformation-.

That said, there is still some work to do in order to finish the test part.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 02, 2016, 03:43:30 AM

Quote from: kalles

can you be sure that you will capture totally entrapped areas within this radius where only a lower amount of skippable iterations is possible?

i believe this is exactly the point of interval arithmetic, to compute bounds that you can be sure will hold true over the given interval.

Quote from: knighty

I'm not sure I understand your question.

i imagine those of us who are not math professors are likely unfamiliar with interval arithmetic. also i think the experience thus far of testing against points and hoping for the best is tainting future optimism that there could actually be a better way :-X

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 02, 2016, 09:34:00 AM

$2 \sum_{i=k-m}^{\left \lfloor \frac{k-1}{2} \right \rfloor} a_i a_{k-i}$

im still not sure about this part.. when k=2m, for instance say m=3 and k=6, we get k-m=3 and $\lfloor \frac{k-1}{2} \rfloor$ =2. ive never seen $\sum$ start higher and go lower. was that your intention?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on September 02, 2016, 09:39:14 AM

Quote from: quaz0r on September 02, 2016, 03:43:30 AM

i imagine those of us who are not math professors are likely unfamiliar with interval arithmetic. :-X

This! :tongue1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: Kalles Fraktaler on September 02, 2016, 11:12:55 AM

Quote from: knighty on September 01, 2016, 04:24:54 PM

What I meant is what I described here http://www.fractalforums.com/index.php?topic=23279.msg95636#msg95636
If your method guarantees the number of skippable iterations at radius of the distance from the reference, it may be distortions closer to the reference.
But if your method guarantees the whole area, then that is awesome :)

I have attached TheRedShifter's "light years away" location if you want to test it

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: mclarekin on September 02, 2016, 12:26:53 PM

@ quaz0r

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 02, 2016, 09:39:37 PM

Quote from: Kalles Fraktaler on September 02, 2016, 11:12:55 AM

We are not there yet. Almost... There are still some problems with the test. Even if it works I still have some doubts. Not that easy math and not that easy to guarantee. Last 100m to the finish are the most difficult. :)

Quote from: Kalles Fraktaler on September 02, 2016, 11:12:55 AM

I have attached TheRedShifter's "light years away" location if you want to test it

Thank you for the location I'll try it ASAP (that is in two or three days).

Quote from: quaz0r on September 02, 2016, 09:34:00 AM

<Quoted Image Removed>

im still not sure about this part.. when k=2m, for instance say m=3 and k=6, we get k-m=3 and <Quoted Image Removed>=2. ive never seen <Quoted Image Removed> start higher and go lower. was that your intention?

If it starts higher than the end value, don't do anything. It is just like:

Code:

for ( int i=10; i<=9; i++) printf("some thing");

This will not write anything.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on September 03, 2016, 09:24:50 AM

Quote from: mclarekin on September 02, 2016, 12:26:53 PM

@ quaz0r

(http://www.fractalforums.com/index.php?action=dlattach;topic=23279.0;attach=13255;image)A cartoon. Now that is something I can relate to! O0

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 03, 2016, 10:39:45 AM

just as a personal exercise to help myself visualize how i might want to write the code for this, i rewrote knighty's formula sans the $n$ superscripting and with zero-based indexing (let M=m-1 and K=M+k):

$R = \sum_{k=0}^M |t_{max}|^k \left | \left ( 2 \sum_{i=k}^{\left \lfloor \frac{K-1}{2} \right \rfloor} a_i a_{K-i} \right ) +\left ( (a_{\frac{K}{2}})^2 \:if\:K\:even\right ) \right | + 2 R\left [ |z| + \sum_{i=0}^M |a_i| |t_{max}|^{i+1} \right ] + R^2 |t_{max}|^{m+1}$

Quote from: stardust4ever

A cartoon. Now that is something I can relate to!

hear, hear :) this stuff makes my eyes glaze over for real :snore:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 04, 2016, 11:04:30 AM

ive implemented the latest formulas for arbitrary number of terms and have been playing around with it. as it is it goes too far very often. ive played around with increasing tmax by an arbitrary factor like claude, but it doesnt seem to be a proper solution. increasing by a factor of 4 like he mentioned gets his test location to render properly, but still fails in further testing. one thing ive noticed is that renders are less correct with a smaller number of terms and get more correct as i increase the number of terms. for instance, 8 terms is usually not very good, 16 is pretty close, and more than 16 seems pretty good. (even though more terms is indeed skipping more and getting pretty close to the min iter)

i still wonder if the max minus the rest part needs a more complex solution.

since this part was described as the derivative of the series approximation, i wondered if maybe utilizing the series approximation of the derivative here would make any sense (from claude's DE stuff)? im of course just blindly tinkering around, but some of my tinkering kinda works, gets pretty far without overskipping but probably not far enough...

...after more tinkering, it looks like using the SA of the derivative with

$max_{k}(\left |a_{k} \right | \left |t_{max} \right |^{k}) - \sum_{i=1 | i\neq k}^{m} \left |a_{i} \right | \left |t_{max} \right |^{i}$

yields the exact same results as using the main SA with knighty's original formula of

$max_{k}(k \left |a_{k} \right | \left |t_{max} \right |^{k-1}) - \sum_{i=1 | i\neq k}^{m} i \left |a_{i} \right | \left |t_{max} \right |^{i-1}$

...after yet more tinkering, it seems that adjusting deltaT is yielding more consistent results than adjusting tmax. leaving tmax alone and multiplying deltaT by 1e-16 seems to make things behave a lot more sanely at the test locations ive been using including claudes, rendering them all correctly regardless of number of terms, so that is a good improvement, though im trying another location now at another deep minibrot which is only rendering correctly if i shrink deltaT by an even larger amount... since deltaT is used solely with the SA derivative stuff, maybe this just brings me full circle again back to indicating that the SA derivative stuff with the max minus the rest condition is ultimately what needs a better solution?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 04, 2016, 12:51:08 PM

Attached code should fix the tmax issue of my previous uploads. There remains to do the implementation of optimal primary reference point location, currently the center of the image is used.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 05, 2016, 12:09:14 PM

after experimenting with various combinations of things for the test condition and testing them on an assortment of test locations, i have what feels like a winner: instead of max minus the rest, max divided by the second max, times the third max, divided by the fourth max, etc. if you do just max divided by second max, you skip a reasonable amount, then the further you go multiplying and dividing more terms the value is further refined and you skip a little more. the amount skipped seems fairly conservative, but it gets fairly close and most of all it appears to be very consistent. no matter what i adjusted or tinkered with, i could not get consistently error-free behavior from max minus the rest, across a wider range of test locations.

noting that i am currently not applying any adjustments to tmax or deltaT. perhaps these could very well stand to be adjusted still, though you would be adjusting to make it skip more instead of less.

also of note with regard to my last post, ive reverted back to knighty's original SA derivative thing. my experiment with using claude's derivative SA there seems to not be exactly the same after all :angel1: or i just wasnt using it right..

update: running some tests on adjusting deltaT reaffirms my thoughts on the approach of adjusting things by some constant factor: it just cant be a proper solution. sometimes adjusting by a certain amount helps without going too far, and sometimes it is too much.

update 2: using tmax instead of deltaT appears to get closer without being too much.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 05, 2016, 12:57:10 PM

Quote from: quaz0r on September 05, 2016, 12:09:14 PM

also of note with regard to my last post, ive reverted back to knighty's original SA derivative thing. my experiment with using claude's derivative SA there seems to not be exactly the same after all :angel1: or i just wasnt using it right..

I think I posted the series approximation recurrence for the derivative dz/dc, while knighty's method uses the derivative of the series approximation dSA/ddeltac - these aren't the same thing! Sorry if I confused things.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 05, 2016, 12:59:24 PM

oh, no confusion from any of your information. i just like to tinker and try random crap and see what happens even if i dont know what im doing. a while back i implemented DE for SA/perturbation using your information, good work! :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 05, 2016, 03:18:01 PM

after more tinkering :angel1: ive arrived at using max divided by min. works better than anything else ive tried so far and much simpler. i keep trying to think of different ways of incorporating all the terms but it keeps either not making a difference or making too big of a difference.

the product of the largest two divided by the product of the smallest two seems to get really far. though trying the product of the larger half of terms divided by the product of the smaller half of terms goes too far.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 05, 2016, 06:04:10 PM

Hi,

@Kalles fraktaler:
In that location I'm getting, at 64 SA terms, 282752 skipped iterations. This is quite low and the rendering was slow. The picture using DE colouring is too dark. I'll try to do another picture with "classic" colouring in order to do a fair comparison. But with 282752 skipped iterations there is no chance to get errors.
I also had to do some modifications to claude's program, a scaled SA coefficients, in order to go that deep and use more terms without getting overflows.

@quazor:
I haven't yet tried to implement my version of residual estimation formula. It's on my todo list. :embarrass:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 05, 2016, 06:07:15 PM

Forgot the code.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on September 05, 2016, 10:38:00 PM

Quote from: knighty on September 05, 2016, 06:04:10 PM

How are you guys doing the distance estimation screenshots? They are quite stunning and beautiful! :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 06, 2016, 08:52:41 AM

Quote from: knighty

In that location I'm getting, at 64 SA terms, 282752 skipped iterations.

just to verify i am on the same page as you guys, testing this location with your previously suggested stop condition of max minus the rest, i too stop at 282752 with 64 terms. using the stop condition i mentioned of max times second max divided by min times second min, 64 terms stops at 296459. the min iter is in the neighborhood of 313000.

one thing to keep in mind with all of this is i think KF and MM (and whatever else) users have been spoiled with overskipping. also i think the errors introduced by overskipping are subtle at first, noticeable some times more than others, and overall we would be wise to not let the behaviors of the old janky stop conditions influence us too much. it would be easy to say "if i skip a few more at this location, i dont notice any difference!" while there may in fact be some degree of error, and using the stop condition that gets you that far will likely cause more noticeable errors somewhere else down the line. it would be easy to say "oh look, these old janky stop conditions skip N amount, but im not skipping that many, I need to recalibrate something!" NOT necessarily i say :dink:

Quote from: knighty

I haven't yet tried to implement my version of residual estimation formula. It's on my todo list.

max minus the rest seems to overskip on some locations (for example, claude's location) and underskip on others (for example, this redshifter location). my experiments with multiplying and dividing seem to be yielding better more consistent results so far..

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on September 06, 2016, 09:25:34 PM

I'm getting 312900 iterations to skip allowing an error <= 0.1% for escape velocity and distance. The region is not 100% identical (no rotation, not exact size). Minit is 313253. That is with 64 coefficients which is chosen as optimal. For 32 I get 300300, for 128 I get also 312900, for 256 312900, and for 1024 312900 as well. Skips are limited to deltas of 100 so this is expected. 64 is optimal since more brings nothing and costs a lot more to compute. And there is corruption in the non reference centers by the way.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 06, 2016, 11:18:01 PM

i have noticed a more empirical way to determine when overskipping is occurring: less reference points get used. i have also observed that readily discernible visual differences in the final image do not tend to present immediately after having crossed the threshold into overskip territory.

assuming here for test purposes of course that your system of glitch tolerance is disabled and things are allowed to run their full course down to every last point. for instance, at claude's test location from this thread, at 1280x720, a correct render for me uses 44 reference points. once i pass into overskip territory, this number steadily goes down, though as i recall visually obvious deformations do not present until this number gets down into the low 20s or so.

logically this makes sense: when visually obvious overskipping occurs, in complex julia sorts of areas that would normally require a relatively higher number of references to accurately complete, you instead see simple non-julia sorts of formations take their place.

this is just a free sort of metric here; if one wanted to perform a more perfectly concrete, more expensive comparison, you could of course compare the escape times and/or distance estimates of each point among different renders of a location.

it would be quite useful to compile a collection of test locations together with empirically-determined skip boundaries for an array of SA term counts.

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=19582 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=19582)

Quote

a test render of TheRedshiftRider's "Light Years Away" location, inspired by the discussion on series approximation.

1920x1080 @ 6x supersampling for an effective resolution of 11520 x 6480.
min iteration was 313765, with 32 SA terms skipping 290484 iterations.
glitch tolerance disabled for a total of 1438 reference points :-X

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 08, 2016, 11:40:03 AM

i noticed again claude's post about trying just | $\Delta{t}$ | for the test, which indeed is a pretty good starting point just on its own. still rather conservative, but at least is consistent in its behavior. which i think shows that overall these formulas are good to go, except what to use with | $\Delta{t}$ |.

Quote from: knighty

I haven't yet tried to implement my version of residual estimation formula. It's on my todo list.

your mention of some mathy thing ive never heard of inspired me to poke around and do some reading.. i got to reading about things like standard deviation, and decided to give that a try. using the standard deviation of the values from the SA' thing with | $\Delta{t}$ | seemed potentially promising, but went a little too far. adjusting | $\Delta{t}$ | by some constant to make it smaller helps but is still imperfect. maybe there is some formula which utilizes something like the standard deviation which would be good?

it still seems like there should be a definitive answer as to what formula to use here, instead of just trying random stuff and seeing what happens :hmh:

and im still falling back to (max1*max2)/(min1*min2) until someone thinks of something more legitimate. i dont know why it works as well as it seems to, but its still the best for me so far.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 08, 2016, 05:04:33 PM

Quazor:
Until now, I haven't had any problem with the locations provided by claude. In some cases the skipped iterations number is optimal. It is sub optimal when there are those substructures that cause blobs and need their own reference.

The test as proposed is not perfect and doesn't give an absolute guarantee on the number of iterations to skip. So far it works well (even if it is sub optimal) and I need to understand first the how and why. There are better and more reliable (and a little bit complicated) ways to do the test but I haven't yet had time to implement them...

The "light years away" location is somehow problematic. When using 100 terms, I get the same glitches as kalles fraktaler at 313'088 skipped iterations. Even the per pixel test doesn't detect correctly the glitches. at 128 terms, nothing is detected (at 64 terms everything is detected). Note that in those cases R is bigger than the last few terms of the SA. These glitches appear when skipping 313'084. At 313'083 skipped iterations there are no SA glitches at all. When using 64 terms, skipping 313'083 iters gives no deformations or SA glitches. At 313'084, there are a lot of deformations that are hopefully detected by the per pixel test. (See pictures below -4x antialiasing-)

With 100 or 128 terms, those glitches don't look like a deformation but as a random noise. They seem to be caused by rounding errors. This is not surprising because there are a lot of terms to add in the computation of the coefficients and the SA itself: the more terms, the more rounding errors. It is possible to account for the rounding errors in the computation of the SA coefficients by adding them to the residual estimation (and using the suitable rounding rule) but that would be too slow. Maybe using Horner method would reduce somehow those rounding errors.

I've also tried the glitch detection formula that was proposed here (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/msg91505/#msg91505) (I use pmax=32). It works very well but doesn't seem to do better than PauldelBrot's in practice (beside detecting some more glitches in "light years away" location.

Something interesting that happens in the computations of the SA, especially with lots of coefficient: It is very slow at the beginning then accelerate dramatically after the first period of the reference is attained. It is probably because of the underflows and subnormals which are 10's of times slower to compute.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 08, 2016, 07:49:01 PM

hmm, perhaps i didnt understand what the per pixel test was supposed to be. i thought it was just something you were using for your own tests. is it something we are actually supposed to use? like a sort of overskip detection you can perform when initializing each point with the series? in that case, i guess you would treat these areas like the perturbation glitch areas, and do new reference points inside them? what is the best way to choose a new reference then, the point with the highest error value?

and so are we saying then that this is the best we can do, more glitch detecting and more reference points? or there is still hope to figure out a totally proper way to get one golden skip value for the whole image?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 08, 2016, 10:06:03 PM

I'm using the per pixel test for testing purposes. :) . In my previous post, the (global) test used for light years away location gives 282752 skipped iterations Wich is far below the max possible: 313083.

The per pixel test is not very expensive so it can be used as a checking option. Having such error metric is already better than nothing.

You are right. It is possible to use the per pixel test to mark the areas detected as overskipped and do a glich like correction. Then the next reference point is around the max error points. But the goal is still to find a good way to get the near optimal skip value over all the rendered area.

The current test works, and goes beyond one period of the reference, because it ignores the zeroes of the derivative of the SA that are inside some area around the reference. When we reach one period P, at P+1 there is always a point inside the minibrot where the derivative vanishes. That point remains until the next period. At 2P+1, we will get 3 point where the derivative is 0. Then 7 at 3P+1 ... so we have 2ⁿ-1 zero derivative points inside the minibrot between n*P+1 and (n+1)*P iterations. This means that the test should not be:
  max abs term - every thing else
but (more conservative but guaranteed assuming the reference dominanat and is inside a minibrot):
  max abs term corresponding to a power of two - every thing else
Or maybe (not sure!):
  sum of abs terms corresponding to a power of two - every thing else.

The obvious disadvantage is that using a reference that is not inside the dominant minibrot will "underskip" a lot. Also the number of skipped iterations will be less than log2(m)*P (where m is the number of coefficients of the SA and P the period of the reference). In order to go further, finer and more expensive methods have to be used. This is not so dramatic because the expensive test doesn't have to be performed at every iteration.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on September 09, 2016, 07:23:02 AM

Looking at the green areas in the image two posts up, I see a lot of distortion. What should be circular formations have literally become crescent moons. Is the whole green area significantly perturbed?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 09, 2016, 08:28:45 AM

indeed, the green area is the "this is your brain on drugs" area. the goal is to keep our mandelbrots drug-free.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on September 09, 2016, 09:24:04 PM

Quote from: quaz0r on September 09, 2016, 08:28:45 AM

indeed, the green area is the "this is your brain on drugs" area. the goal is to keep our mandelbrots drug-free.

LOL! I've had people from video gaming forums (retro gaming is my other hobby) watch some of my YT fractal vids, and they said watching 15 minutes of continuous colorful zoom action was like taking an acid trip!
:spiral:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on September 09, 2016, 09:38:51 PM

Quote from: quaz0r on September 09, 2016, 08:28:45 AM

indeed, the green area is the "this is your brain on drugs" area. the goal is to keep our mandelbrots drug-free.

Quote from: stardust4ever on September 09, 2016, 09:24:04 PM

Same here, I showed one of my videos to my classmates. They asked which drugs I was using. :/

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 09, 2016, 10:27:31 PM

yes if you like fractals you should definitely give psychedelic drugs a try sometime :alien:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on September 09, 2016, 10:41:23 PM

Quote from: quaz0r on September 09, 2016, 10:27:31 PM

yes if you like fractals you should definitely give psychedelic drugs a try sometime :alien:

I would imagine it could nice but I suppose opinions differ greatly. I am not sure what to think about it. :)
Alright, let's return to the original topic.

I really like the way my location is used here. The different palettes look nice on this location.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 09, 2016, 11:00:11 PM

yes, i need to look at your zooming technique again sometime. its really great how you can get that much going on at such a shallow depth!

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: TheRedshiftRider on September 09, 2016, 11:21:23 PM

Quote from: quaz0r on September 09, 2016, 11:00:11 PM

yes, i need to look at your zooming technique again sometime. its really great how you can get that much going on at such a shallow depth!

Thank you. I actually have not figured out the math behind it so I still do not know how it works. :) Help and interest are always appreciated. ;)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: stardust4ever on September 10, 2016, 07:36:33 AM

Quote from: quaz0r on September 09, 2016, 10:27:31 PM

yes if you like fractals you should definitely give psychedelic drugs a try sometime :alien:

If they legalize mushrooms (not the culinary type) or THC in my state, I'll give it a try!

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 18, 2016, 06:57:53 PM

ok, on a different note for a minute, i was thinking: could one apply perturbation (or whatever) to the series approximation? instead of using the series to compute the $\Delta{z}$ for each point, which gets progressively more costly at higher term counts and resolutions, could you instead do that for one or maybe two points, and then use some simpler formula to compute a difference in the deltas or something to more cheaply get the rest? or something to that effect...

since the only thing changing the output of the series approximation is the $\Delta{c}$ , and if those differ by some increment of a constant distance between points, it just seems like maybe there might be some shortcut to perturbing these values of $\Delta{z}$ ... or is it not possible?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 20, 2016, 08:21:44 AM

after more tinkering with the truncation error test condition, i have an apparent solution. the previous suggestion was (max term minus the rest) of the derivative of the series:

$max_{k}(k \left |a_{k} \right | \left |t_{max} \right |^{k-1}) - \sum_{i=1 | i\neq k}^{m} i \left |a_{i} \right | \left |t_{max} \right |^{i-1}$

this seemed close to a solution at first, but in fact is not, sometimes resulting in overskipping and sometimes resulting in underskipping. i found that if we instead use the following test condition:

$|z+SA(t_{max})||SA'(t_{max})||\Delta{t}|$

we skip exactly as much as we can without overskipping. in fact, in testing at various locations, it seems the old test was often overskipping by 1 iteration, but now we always stop exactly at the iteration before overskipping would occur. and no bogus fudging of $|t_{max}|$ or $|\Delta{t}|$ needed to try to correct for bad results. i set my $|t_{max}|$ to the size of the image and $|\Delta{t}|$ to the size of a point.

also with this as before, the subtracting of some SA' terms from others still produces incorrect behavior. in testing this new condition, simply adding all terms results in the correct behavior, as would seem more typical and intuitive. i suspect perhaps the subtracting of terms and such was an experimental attempt to counter overskipping.

a few results from testing some of the locations used in this thread, @1280x720:

claude's location

min iter: 3554

old test, 8 terms: 3216, Incorrect render
new test, 8 terms: 3215, correct render

old test, 16 terms: 3298, Incorrect render
new test, 16 terms: 3297, correct render

old test, 32 terms: 3368, correct render
new test, 32 terms: 3375, correct render

old test, 64 terms: 3380, ?
new test, 64 terms: 3379, correct render

redshifter's light years away location

min iter: 313767

old test, 8 terms: 282752, Incorrect render
new test, 8 terms: 282751, correct render

old test, 16 terms: 282752, correct render
new test, 16 terms: 300358, correct render

old test, 32 terms: 282752, correct render
new test, 32 terms: 313030, correct render

old test, 64 terms: 282752, correct render
new test, 64 terms: 313083, correct render

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 20, 2016, 03:05:41 PM

Quote from: quaz0r on September 20, 2016, 08:21:44 AM

it seems the old test was often overskipping by 1 iteration

Are you sure that this isn't an off-by-one error in your code? If the test fails, I roll back to the previous iteration (the last one that succeeded), instead of using the failing values.

Pseudo-code:

Code:

old values <- initialize
loop
  next values <- series approximation step (old values)
  ok <- check validity (next values)
  if ok
    old values <- next values
  else
    break
final values to use <- old values

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 20, 2016, 04:38:17 PM

Quote from: claude

Are you sure that this isn't an off-by-one error in your code? If the test fails, I roll back to the previous iteration

its certainly always possible :embarrass:

though i dont really follow your meaning either. why would you suspect my code of being off if you are the one rolling back by one, and my new results are skipping the full amount possible without overskipping? as ive previously stated it seems pretty obvious after more testing that the old test is no good, both overskipping and drastically underskipping, and this seems to have been the case for all of us whether we've realized it immediately or not. recall at your test location you were overskipping by quite a bit, resulting in an incorrect render you didnt notice at first, and then you fudged your tmax by quite a bit until you got that particular location to seemingly render properly, even though it seems this was not actually the right solution to the right problem.

as my new test results show, there is more than a difference of 1 :) youll notice how the old test gets stuck at 282752 at the light years away location. i believe when knighty was testing that location he indicated getting stuck there also. i believe he has also indicated noticing in testing different skip amounts at various locations that his test was often overskipping by 1? i now seem to be skipping the full amount possible in addition to not encountering any overskipping yet which would require rolling back or whatever.

that being said, i still wish the test condition could be arrived at through some sort of well-understood, well-defined process that yields a specific and proper answer to what exactly should go in that part of the formula, instead of having to play around by trial and error. im not sure what the malfunction has been in that respect. i guess knighty did say "the math is not easy." fair enough :) that means we need to keep testing, experimenting with new things, and verifying results. it also means we should be careful not to blindly get married to the first thing he posts, considering he has shown a tendency to mistype things and mis-copypaste things in addition to possibly misconceiving of things. perhaps the first question should be, is He off by 1? or more ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 20, 2016, 05:47:04 PM

Quote from: quaz0r on September 20, 2016, 04:38:17 PM

though i dont really follow your meaning either. why would you suspect my code of being off if you are the one rolling back by one, and my new results are skipping the full amount without overskipping? as ive previously stated it seems pretty obvious after more testing that the old test is no good, both overskipping and drastically underskipping, and this seems to have been the case for all of us whether we've realized it immediately or not. recall at your test location you were overskipping by quite a bit, resulting in an incorrect render you didnt notice at first, and then you fudged your tmax by quite a bit until you got that particular location to seemingly render properly, even though it seems this was not actually the right solution to the right problem.

Rolling back to the last "ok" set of coefficients is the right thing to do, I'm pretty sure.

My old code was buggy, and had tmax set to a too-small value, so it's not surprising the output was buggy too, though I should have spotted it. But that wasn't so much fudging as bug fixing (though the initial fix was a bit quick and dirty). The latest code I posted in this thread should be correct, with tmax set to the maximum distance from the corners to the reference.

Quote

as my new tests show, there is more than a difference of 1 :) youll notice how the old test gets stuck at 282752 at the light years away location. i believe when knighty was testing that location he indicated getting stuck there also. i believe he also indicated noticing in testing different skip amounts that his test was often overskipping by 1. i now seem to be skipping the full amount in addition to not encountering any overskipping yet which would require rolling back or whatever.

that being said, i still wish the test condition could be arrived at through some sort of well-understood, well-defined process that yields a specific and proper answer to what exactly should go in that part of the formula, instead of having to play around by trial and error. im not sure what the malfunction has been in that respect. i guess knighty did say "the math is not easy." fair enough :) that means we need to keep testing, experimenting with new things, and verifying results.

Indeed, thanks for your experiments, but as you say without theoretical grounding it's hard to know whether it's just luck that it works or really true everywhere...
(But even if the hardmaths gives a result that is valid for infinitely precise series approximation coefficients, there's the whole nother can of worms from reducing the precision to manageable levels...)

How are you calculating |z+SA(tmax)| and |SA'(tmax)|? As the sum of the absolute values of the terms? (EDIT I implemented it like that, seems to work in a couple of small tests)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 20, 2016, 06:07:10 PM

Quote from: claude

Rolling back to the last "ok" set of coefficients is the right thing to do

sure, if you find that your stop condition often stops 1 too late, rolling back by 1 is certainly what should happen if nothing else.

Quote from: claude

as you say without theoretical grounding it's hard to know whether it's just luck that it works or really true everywhere

indeed, though given that knighty's guesses at possible things to try for the test condition are exactly that, it seems like maybe we are still suffering from wanting to be married to his initial guesses. in any case, im not trying to convince you of anything here, im simply reporting some results from some of my experiments, and trying to keep the dialog going. these new results seem very promising to me. if they do not interest you that is ok.

Quote from: claude

How are you calculating |z+SA(tmax)| and |SA'(tmax)|? As the sum of the absolute values of the terms?

maybe i didnt write it right, i think i saw knighty write it like that ;D i was simply replicating pieces of the formula that he already came up with, this being |z+SA(tmax)|:

$|z| + \sum_{i=1}^{m} |a_i| |t_{max}|^i$

and this being |SA'(tmax)|:

$\sum_{i=1}^{m}i|a_i| |t_{max}|^{i-1}$

Quote from: claude

(But even if the hardmaths gives a result that is valid for infinitely precise series approximation coefficients, there's the whole nother can of worms from reducing the precision to manageable levels...)

indeed :sad1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 20, 2016, 06:17:01 PM

Cool, thanks! I do find it interesting, will investigate further later today. The implementation is as I suspected (I guess you miss a ^i in the first expression?), thanks for confirmation!

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 20, 2016, 06:22:32 PM

yes, fixed :angel1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 21, 2016, 06:56:09 PM

Updated my example code with a runtime choice of stopping condition (either knighty or quaz0r), and automatic primary reference point finding with Newton's method (instead of simply using image center).

Example:

Code:

./a.out --width 1920 --height 1080 --maxiters 65536 --re -1.7490930547842157115735991351312021280767302886600874275176041515873173828 --im -0.000175618967275210134352664990246036215136914278796260509941399986977798 --radius 1e-47 --precision 100 --order 32 --stopping quaz0r --output out.ppm

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 21, 2016, 07:31:15 PM

neat. i havent tried the root finding stuff yet. i thought you had to have some starting information to work with like a derivative or such? but you are using it to pick a good reference point before any other information is known? i'll take a peek at your code here, thanks.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 21, 2016, 08:07:33 PM

The main thing you need is the period. You can use the center of the image as an intial guess. My example code has two ways of finding period, the first is better (works when zoomed out further from a nucleus) but can sometimes fail - usually this is when zooming off-center but not far enough in to detect the new reference, the fallback method can find the previous nucleus that has been zoomed far away (but not too far to be useful). The second method always succeeds but in the unlikely worst case might give 0+0i or some other similarly unsuitable as reference - not sure what to do about this, interactive programs could re-use the reference from the previous view...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 21, 2016, 08:38:52 PM

"but sometimes can fail" this is exactly what i have envisioned regarding anything having to do with the period, which is why all things period-related have been at the very bottom of my todo list. you cant rely on direct comparison of floating-point values, especially after thousands or millions of iterations of computation, and similarly i dont see how you can rely on a fuzzy comparison either. what do you do after a million iterations, use a fuzz factor of a million times epsilon? and of course i think properly analyzing the propagation of floating-point error would not be that simple either. in any case, no matter what you might do it seems doomed to always be unreliable.

with regard to your example code, im not clear on the meaning of its console output. i was going to try the light years away location with it, and doing a small test render it looks like im entering the right location information.

Code:

$ ./msa-v6 --width 320 --height 200 --maxiters 360000 --re -1.76904090125288168240284276810365472222460651367280300612031519864776551390840630119504817227707689276670981344397551593371805167279428144061799517560299280824 --im -0.00316054002725585687597452686360873344443505151775719080569769837935155069602621497041147081901473680485729761920491032720741888487688356001952853460889810026385 --radius 6e-140 --precision 156 --order 32 --output out.ppm

it says "series approximation iteration 12564." is that supposed to be the skip amount?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 21, 2016, 08:55:13 PM

The period detection is based on properties of the Mandelbrot set, not comparison of floating point values - so there's no fuzz factor involved. See http://www.mrob.com/pub/muency/period.html

Quote from: quaz0r on September 21, 2016, 08:38:52 PM

it says "series approximation iteration 12564." is that supposed to be the skip amount?

Yes, it counts up and the last value displayed (when the next line is output) is the skip count. But 43113 iterations skipped is what I get with both --stopping methods at this location...

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 21, 2016, 09:07:10 PM

ah, i guess you are using fp exception stuff. i had compiled with -Ofast, it works now with -O3, and says 43113 at that location. 43113 is still way too low for the light years away location. maybe im not entering the location right. is it reporting the skip amount as an amount past a multiple of the period or something? it reports a period of 126210, (126210*2)+43113 is 295533, that would be more in the expected range for this location.

the period detection scheme you linked to is very intriguing! can it be said to be perfectly reliable?

after another day of testing my stop condition, it still seems to be skipping the maximum, with no fails yet. hopefully knighty has some additional insight for us :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 21, 2016, 09:35:23 PM

That's because R overflows! One need to balance the exponents of the coefficients and Delta_t in the SA polynomial... or use a floatExp type like in kallesfraktaler.
(Edit: see the code attached here (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/msg95890/#msg95890). It runs slowly at the beggining of SA computation because of denormals. This issue is solved now, I'll post the updated code ASAP (meaning probably not today))

@quasor: I never said that I was overskipping by one. The fact is that in claude's code n is initialized to 1 so it outputs the skipped number of iterations +1. :)
So far, the test that I have proposed always gives a skipped number of iterations less or equal to the optimum. I also output in the picture the per pixel error. It is quite cheap and gives you the ability to see immediately if the method fails.

Your formula is very interesting: It gives a skip number very close to the optimum but here it usually overskip (by a little amount). I gess you use bigger Tmax value... The question is why it works? :dink:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 21, 2016, 09:52:45 PM

yeah, i use a floatexp for all this stuff. for me it has not overskipped yet. what are you guys using for tmax? i am using the longest side of my viewport, ie 1280 for 1280x720, times the size of a point. it is a simple value to calculate and seems like this would be maybe a little more than the minimum you could get away with, just for good measure. so i guess you are finding my stop condition to start overskipping with a somewhat smaller tmax than this? does this mean the stop condition formula is not exactly what it should be, or does this simply mean that in practice we need to say tmax should be a little larger than the absolute minimum it seems like it should be?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 21, 2016, 09:57:03 PM

Quote from: quaz0r on September 21, 2016, 09:07:10 PM

ah, i guess you are using fp exception stuff. i had compiled with -Ofast, it works now with -O3, and says 43113 at that location.

Don't know about fp exceptions, but there is possibly some parts that depend on associativity being in the right order (ie, (a + b) - b != a + (b - b) or similar). Generally I only use -ffast-math or similar for small parts of a code-base, when I've tested and it gives acceptable output.

Quote

43113 is still way too low for the light years away location. maybe im not entering the location right. is it reporting the skip amount as an amount past a multiple of the period or something? it reports a period of 126210, (126210*2)+43113 is 295533, that would be more in the expected range for this location.

Yes is is low, thanks to knighty for the probable explanation - will see about adding something floatexp to my example code. No multiple of periods are reported, just the plain value.

I count iteration 0 as z=0, iteration 1 as z=c - maybe this is where some confusion is coming from... (perturbation starts from iteration 1 in my terminology, as at iteration 0 everything is 0 so nothing to perturb)

Quote

the period detection scheme you linked to sounds very intriguing! can it be said to be perfectly reliable?

It can fail in a few situations: all initial corners are outside the mandelbrot set with no points of the mandelbrot set in the interior; also if all corners are interior to the same component and not surrounding that component's nucleus, it could iterate forever without finding a period or escaping. the most common failure case is as I described earlier.

For tmax I use the largest distance from the reference to the corners of the viewport.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 21, 2016, 10:01:00 PM

Quote from: quaz0r on September 21, 2016, 09:52:45 PM

Yes, you use a bigger Tmax so R grows (much) faster.

Quote from: quaz0r on September 21, 2016, 09:52:45 PM

does this mean the stop condition formula is not exactly what it should be, or does this simply mean that in practice we need to say tmax should be a little larger than the absolute minimum it seems like it should be?

Guess: Not exactly what it should be but it seem to be very close.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 21, 2016, 10:04:00 PM

For one, I use ffast-math. No difference so far... except it is faster. ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 21, 2016, 10:34:37 PM

actually i misspoke, looking at it again, i set tmax to the diagonal distance between opposite corners of the viewport, thinking this could be a simple catch-all value for a reference point at any location within the image. though right now i am simply using the center as my initial reference, and thus what gets used to determine the skip amount. so i guess ive been using twice what the minimum value could be. i will try setting tmax to the minimum and play around with that some.

results at these two locations again with min tmax:

claude's location

min iter: 3554

old test, 8 terms: 3216, Incorrect render
new test, 8 terms: 3215, correct render
new test, 8 terms, min tmax: 3215, correct render

old test, 16 terms: 3298, Incorrect render
new test, 16 terms: 3297, correct render
new test, 16 terms, min tmax: 3297, correct render

old test, 32 terms: 3368, correct render
new test, 32 terms: 3375, correct render
new test, 32 terms, min tmax: 3379, correct render

old test, 64 terms: 3380, correct render
new test, 64 terms: 3379, correct render
new test, 64 terms, min tmax: 3461, correct render

redshifter's light years away location

min iter: 313767

old test, 8 terms: 282752, Incorrect render
new test, 8 terms: 282751, correct render
new test, 8 terms, min tmax: 282751, correct render

old test, 16 terms: 282752, correct render
new test, 16 terms: 300358, correct render
new test, 16 terms, min tmax: 300358, correct render

old test, 32 terms: 282752, correct render
new test, 32 terms: 313030, correct render
new test, 32 terms, min tmax: 313083, correct render

old test, 64 terms: 282752, correct render
new test, 64 terms: 313083, correct render
new test, 64 terms, min tmax: 313192, Incorrect render

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 22, 2016, 05:46:57 PM

It seems that Quazor's test gives the maximum possible skip while neglecting the roots of SA'(t). In most situations, it gives the right amount of iterations to skip. It is even not necessary to multiply by $|z| + \sum_{i=1}^{m} |a_i| |t_{max}|^i$ .

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 22, 2016, 09:42:13 PM

multiplying that extra part was my suggested modification to your original test condition. it results in skipping a little less. also except that you were originally trying to subtract some of the terms in some way. testing things again with the right tmax this time :banginghead: simply $|SA'(t_{max})||\Delta{t}|$ does appear to give the maximum skippable amount most of the time (plus one) ... whereas your original idea of subtracting some of the terms sometimes results in the right skip amount (plus one) and other times results in (dramatic) underskipping. $|SA'(t_{max})||\Delta{t}|$ does still appear to sometimes break down and overskip by more than 1 for me however, for example with 64 terms at the light years away location, it skips 313249. in my last post, i wrote how $|z+SA(t_{max})||SA'(t_{max})||\Delta{t}|$ skips 313192, which itself was already resulting in an incorrect render. so simply SA' does seem very close, but it seems it does still need modification by something?

i wonder too at how many terms, at how many iterations, or under what other conditions error due to limited precision might start accumulating and affecting the outcome. it makes it extra difficult to know whether the test condition is theoretically correct when it starts to fail seemingly only at a higher number of terms and/or iterations.

still, the fact that this test condition always overskips by at least 1 does make it seem like it is indeed an incomplete test condition? albeit very close. maybe it does need some scheme of subtracting or otherwise modifying some terms after all ;D

testing the light years away location with 128 terms overskips (by more than 1) also.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 22, 2016, 11:10:34 PM

Quote from: quaz0r on September 22, 2016, 09:42:13 PM

Well, one have to do the reasoning beginning with the per pixel test. The error is greater when R*|t|^m+1 is big and/or the derivative of the SA is small. Now, assuming the reference point is inside the dominant minibrot, when the number of iterations goes beyond one period there is necessarily one point where the derivative is zero. That zero is inside the minibrot. between one period and two there are points where the derivative of the SA vanishes. They are located in the area around the minibrit that is between one and two map doubling. after we reach two periods, the new points where the derivative of the SA become 0 are inside the area between two and three map doubling (plus two more points inside the minibrot)... etc.
That means that after the first period, we get more and more points where the derivative becomes zero. All these zeros are located inside minibrots which are much smaller than a pixel. Their area of influence, that is the area where we get a lot of errors, are very small, therefore, they have to be discareded somehow. Now, the problem is that with the SA which is a low order polynomial (order m), we are trying to approximate a polynomial (let's call it mandelbrot's polynomial) which have a very high order (2^Iterations roots). so at some point it is impossible to the derivative of the SA to have the same number of roots as the Mandebrot polynomial inside the rendered area. Then we get a deformed glitch which is not necessarily because R is too big but because the SA's derivative can't reproduce all the points where the Mandelbrot polynomial's derivative vanishes. (see for example the 1st animated gif in this post (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/msg95558/#msg95558).)

The test that I have proposed is finally no more than an aparatus that counts the number of roots of SA'(t) that we can be sure are inside the radius tmax disk around the reference. The number of roots is given by the index of the "winning" coefficient (-1 of course). See Bounds on (complex) polynomial roots Based on the Rouché theorem (https://en.wikipedia.org/wiki/Properties_of_polynomial_roots#Based_on_the_Rouch.C3.A9_theorem). There are a lot of stuff to learn... :angry: :hurt:

The good new now is that we have a lower AND upper bounds on the number of iterations to skip. :D

Quote from: quaz0r on September 22, 2016, 09:42:13 PM

i wonder too at how many terms, at how many iterations, or under what other conditions error due to limited precision might start accumulating and affecting the outcome. it makes it extra difficult to know whether the test condition is theoretically correct when it starts to fail seemingly only at a higher number of terms and/or iterations.

Yes it's quite difficult, not impossible. One can use a class that computes the rounding errors and their propagation along with the calculations... but that would be too slow.
BTW! In "light years away" location, do you have the same glitches as kalles fractaler when skipping more than 313083 iterations. The circular one is probably due to rounding errors (I can detect it by using a crude estimation of the rounding error) but the random one is very difficult to explain. :banginghead:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: aleph0 on September 22, 2016, 11:36:30 PM

Quote from: stardust4ever on September 05, 2016, 10:38:00 PM

How are you guys doing the distance estimation screenshots? They are quite stunning and beautiful! :)

This question seems to have been overlooked...

Do you mean how is the distance estimate translated to grey-scale value in the rendered images?

If so, take a look at function "plot" in Claude's example C++ code v6 in reply #308. It's using hyperbolic tangent (tanh) as the translation function.

See these posts by Pauldelbrot for other translation functions (with inverted colouring, white is close):

http://www.fractalforums.com/images-showcase-(rate-my-fractal)/troubled-tree-ii/

http://www.fractalforums.com/images-showcase-(rate-my-fractal)/doily/

Where Paul talks of grey curve and distance estimator colouring, he is essentially referring to the translation function used; there can be scaling and inversion factors applied too.

DE renderings can be stunningly beautiful, no doubt, especially for deeply zoomed and dense images... symmetries revealed in all their glory.

Grey-scale DE can also be combined with full-colour rendering methods to great effect:

http://mrob.com/pub/muency/representationfunction.html

Or did you you mean from which program? If so, Claude's example program would be suitable if you can get it compiled; see source code comments (that's going to need a Linux distribution typically). Then run it from command line with something like this:

./a.out --width 1920 --height 1080 --maxiters 65536 --re -1.7490930547842157115735991351312021280767302886600874275176041515873173828 --im -0.000175618967275210134352664990246036215136914278796260509941399986977798 --radius 1e-47 --precision 100 --order 32 --stopping quaz0r --output out.ppm

Then something to convert ppm image output file to one of the more common image formats. I use Gimp.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 22, 2016, 11:57:58 PM

Quote from: knighty

at some point it is impossible for the derivative of the SA to have the same number of roots as the Mandebrot polynomial inside the rendered area. Then we get a deformed glitch which is not necessarily because R is too big but because the SA's derivative can't reproduce all the points where the Mandelbrot polynomial's derivative vanishes.

if i am understanding what you are saying, could we then say that $|SA'(t_{max})||\Delta{t}|$ is the right test condition, with the caveat that by its nature of having a limited number of terms it is inevitably going to fail? this failure due to limited terms, can we say what exactly this entails, such that we can add a check for when this happens? and with the added check, we should then have everything we need?

also if i understand what you are saying, i think this explains why i have observed the test starting to fail with a greater number of terms... even though there are more terms, it means we are going farther into more iterations, which is compounding this problem of doubling the roots? or whatever you are talking about that i dont really understand ;D

Quote from: knighty

BTW! In "light years away" location, do you have the same glitches as kalles fractaler when skipping more than 313083 iterations.

with 32 terms, i get a correct render when skipping 313083 iterations. at 313084 it falls apart, even at 64 terms:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 23, 2016, 02:52:43 AM

skipping 313084 iterations with both 128 and 256 terms results in the same render, with the fuzzy-looking sort of glitchiness at the ends:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 24, 2016, 01:54:20 AM

i screwed around a bit with reordering the summation of the terms and it does affect how the fuzzy bits turn out, so it does look to be a loss of significance sort of issue i guess. i was just reading about a few different things like kahan summation; as usual it looks like the solution is not necessarily a simple one. :angry:

ok, running a test using full precision just to add up the deltas for each point took forever, and it still didnt fix the glitchy areas.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 24, 2016, 01:42:55 PM

After thinking a little bit about it I finally realized that I am really stupid! Well... later better than never. ;D
The test should be:
$R \left | t_{max} \right |^{m+1} \leq 2^{-(p_{max} - s)} \sum_{i=1}^{m}\left | a_i \right | \left | t_{max} \right |^m$
Where:
  p_max is the number of bits in the mantissa (64 for long double)
  s is the (misterious) number of bits of accuracy that could be loosed without causing too much errors. This depends a lot on the location. it can go from 0 to
   something like 20 or 30. Better set it to 0.
This is because (in principle) the area of influence of the zeros of the derivative of the SA is about the size of the minibrot where the zero occures Which is usually very small. Even when the minibrot is visible, that area won't show up because it is inside.

It works perfectly so far for m<=64. The "Light years away" location is problematic. When m>90 or so, the rounding errors in the coefficients (+ sometimes cancellation) seem to dominate the truncation error.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 24, 2016, 01:49:36 PM

Quote from: quaz0r on September 24, 2016, 01:54:20 AM

Here, the fuzzy part changes even when nothing is modified in the code or the parameters.

Quote from: quaz0r on September 24, 2016, 01:54:20 AM

ok, running a test using full precision just to add up the deltas for each point took forever, and it still didnt fix the glitchy areas.

I have also tried that (among other things). It seems to show that the problem indeed comes from loosing accuracy in the coefficients.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 24, 2016, 03:11:36 PM

did you write the formula right? if we subtract an amount $s$ from pmax, the test bails sooner rather than later. also the test seems to bail rather early in general?

Quote from: knighty

It works perfectly so far for m<=64. The "Light years away" location is problematic. When m>90 or so, the rounding errors in the coefficients (+ sometimes cancellation) seem to dominate the truncation error.

is it a coincidence that the number of terms it appears we can safely use seems to also roughly correspond to the number of bits of mantissa precision? or could we use that as a general rule of thumb? i guess you are saying the truncation error computation can fall apart with more terms, but it seems the calculation of the coefficients themselves can also fall apart, ie, light years away location being fuzzy.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: knighty on September 24, 2016, 06:52:14 PM

Quote from: quaz0r on September 24, 2016, 03:11:36 PM

did you write the formula right? if we subtract an amount <Quoted Image Removed> from pmax, the test bails sooner rather than later. also the test seems to bail rather early in general?

No! I did a mistake again. :embarrass:
It must be : 2^-(pmax-s)
I'll correct the formula.

Quote from: quaz0r on September 24, 2016, 03:11:36 PM

I don't know if there is any coincidence.
The rounding errors in the computation of the tuncation are not important AFAIK. The right way to compute the truncation is by using a rounding to infinity. I've tried that and the difference is small. This is certainly because we are adding positive values which don't cause cancellation. In the other hand, the coefficients may suffer from cancellation, especially the last ones. The more terms to add/subtract, the more rounding and cancellation risks. the number of iterations also have a big impact on the rounding errors. (The rounding error at iteration n on the coefficient a_i is roughly O(i*n) or maybe more)
As you pointed out, maybe using kahan summation would reduce the problem. Anyway, in general higher order polynomials having bad conditionning, I think there is no benefit in using SA with m > 64.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 26, 2016, 07:58:37 PM

Quote from: knighty on September 24, 2016, 01:42:55 PM

The test should be:
(tex)R \left | t_{max} \right |^{m+1} \leq 2^{-(p_{max} - s)} \sum_{i=1}^{m}\left | a_i \right | \left | t_{max} \right |^m(/tex)
Where:
  p_max is the number of bits in the mantissa (64 for long double)
  s is the (misterious) number of bits of accuracy that could be loosed without causing too much errors. This depends a lot on the location. it can go from 0 to
   something like 20 or 30. Better set it to 0.

I implemented it (attached) as "--stopping knighty2" with "--accuracy 24" to have 2^-24 as multiplier on the right hand side (series approximation accurate to 24 bits, makes more sense to me then saying how many bits should be deducted from the precision of the type). Here are some data:

location 1:

order	knighty	quaz0r	knighty2 24	knighty2 8
16	3298	3297	3216	3298
32	3298	3379	3298	3380

location 2 "light years away":

order	knighty	quaz0r	knighty2 24	knighty2 8
32	300359	298493	300359	308258
64	300359	303375	305241	311275

With knighty2, even at --accuracy 8 only a few pixels are different from --accuracy 24 by a few grey-levels, imperceptible to the naked eye.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on September 26, 2016, 10:21:43 PM

claude i wonder if your test code is still underflowing or something? at 2^-8 at location 2 i get 313084 with 32 terms, and 313193 with 64 terms.

i have noted how at this location i cant skip any more (than 313083) with 64 terms than with 32. do you guys have the same experience? this seems maybe kind of weird, as the resulting glitchiness with 64 terms isnt the same as the noisy areas that appear with yet more terms, with the noisy areas seeming more like what you would expect from precision/cancellation errors. but if the weird render i get skipping more than 313083 with 64 terms is in fact also the result of precision errors then i guess it makes sense.

at 2^-16 at this location i get 313084 with 64 terms the same as i do with 32, which is what needs to happen to get a correct render (rolling back by 1). it would be nice if one could predict what the multiplier needs to be in examples like this, though i guess here if the problem is simply a precision/cancellation sort of problem, maybe there is no correlation to be made.

also i was a little disappointed that it seems using this multiplier still cant get us away from the overskipping by 1, requiring the additional rollback logic. testing at location 1 for instance with 8 terms, at 2^-17 i skip 3216 which requires rolling back by 1, and at 2^-18 i skip 2781, a lot less than the max possible. though the gap does seem to narrow quite a bit with more terms.

in fact it appears that when the multiplier is sufficient to change the stopping point by very much, the result seems close to a shifting down of the stopping point by 1 chunk/interval/whatever. ie, at 2^-17, 8 terms stops at 3216, 16 at 3294, 32 at 3356, and 64 at 3380. at 2^-18, 8 terms stops at 2781, 16 at 3216, 32 at 3298, and 64 at 3380.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on October 04, 2016, 01:13:34 AM

Quote from: quaz0r on September 26, 2016, 10:21:43 PM

claude i wonder if your test code is still underflowing or something? at 2^-8 at location 2 i get 313084 with 32 terms, and 313193 with 64 terms.

Pretty sure it isn't underflowing (now uses "edouble" which is a double with a separate long exponent, could be that there are bugs in that though).

Maybe I'm calculating R in a different way to you? I think knighty posted a couple of different versions of that part of the algorithm. Plus there was the cartoon, and your version of the equation. Here's the relevant snippet from my code, where a[0] is z and a[m + 1] is R:

Code:

    // calculate truncation error
    {
      // knighty's second estimate
      R_lo sum(0);
      R_lo tmaxn(1);
      for (N k = m + 1; k <= 2 * m; ++k)
      {
        C_lo sum2(0);
        for (N j = k - m; j <= (k - 1) / 2; ++j)
          sum2 += a[j] * a[k - j];
        sum2 *= R_lo(2);
        if (! (k & 1)) // if k is even
          sum2 += a[k / 2] * a[k / 2];
        sum += abs(sum2) * tmaxn;
        tmaxn *= tmax;
      }
      tmaxn = R_lo(1);
      R_lo sum2(0);
      for (N j = 0; j <= m; ++j)
      {
        sum2 += abs(a[j]) * tmaxn;
        tmaxn *= tmax;
      }
      sum += 2 * abs(a[m + 1]) * sum2;
      sum += 2 * abs(a[m + 1]) * abs(a[m + 1]) * tmaxn;
      a_next[m + 1] = C_lo(sum);
    }

UPDATE: I tried with your formulation from this post with identical results to the code above :hmh:
http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/msg95838/#msg95838 (http://www.fractalforums.com/announcements-and-news/*continued*-superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-ja/msg95838/#msg95838)

So still searching for the difference. Hard for me to tell without seeing your code where my code is different, you at least have both sets of code and can compare.

Quote

also i was a little disappointed that it seems using this multiplier still cant get us away from the overskipping by 1, requiring the additional rollback logic.

By the nature of the test ("is this set of coefficients good or bad?"), I think rolling back from the first "these are bad" to the last known "these are good" coefficients is the only way it can work. Or is there even more overskipping by 1 beyond that?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on October 04, 2016, 02:47:30 AM

eh, i dont know what was up with the cartoon really...also i think they used a version of knighty's equation to make the cartoon before he fixed some of his copy paste mistakes..

the way i had my series stuff written originally was to keep the last iteration of stuff in memory, do the next iteration, do the test condition, if it passes put the new stuff in memory and loop, if it fails stop and use the last good set of stuff in memory. i was in fact doing the obvious thing in other words. my experience of knighty's truncation error stuff is that when the test condition fails, the previous iteration is not good; it is in fact the iteration before that which is good, hence my complaining about overskipping by 1.

this is if it goes the full distance of course. with the addition of the pmax multiplier or whatever, this will cause it to stop sooner sometimes, so you wouldnt experience the overskipping in that case.

this is just my experience with my own code.. its always possible im doing something different or made a mistake somewhere or something.

Quote from: claude

Hard for me to tell without seeing your code where my code is different, you at least have both sets of code and can compare.

well, my endeavor is to make a relatively complete program, unto itself at least, and my personal preference is to reach a certain degree of completeness before posting it. i'll post my code eventually, not that i presume anyone to care what im doing, but i am a staunch user and advocate of open source :)

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: skychurch on January 20, 2017, 01:47:41 AM

A bit off current topic I know. But has anyone developed a heuristic to optimise SA bailout and number of terms to use in the SA approximation?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on January 20, 2017, 09:43:42 PM

Quote from: skychurch on January 20, 2017, 01:47:41 AM

A bit off current topic I know. But has anyone developed a heuristic to optimise SA bailout and number of terms to use in the SA approximation?

As a rule of thumb every doubling of coefficients is good for an additional x skips with x = period of reference upto getting close to the minimal iteration
in the image. If minimal iteration < period of reference... hm... ;D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on January 20, 2017, 09:52:09 PM

I don't know if this is old news but the perturbation approach and series approximation break down the more the closer one gets to the border of the main body or a minibrot copy. First numerically (as in objective errors compared to correct arbitrary precision numbers) and then visually. The reason is that references are good for fewer and fewer pixels till they support only themselves at which point we are back at full arbitrary precision for every pixel. And the reason for this is that orbiting behaviour from pixel to pixel gets different enough that the deltas quickly run out of hardware bits and rounding errors take over way too early for correct results. Fortunately there are enough other places where the method works very well and allows spectacular results otherwise not obtainable with "normal" hardware in a reasonable time.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: quaz0r on January 21, 2017, 08:30:17 AM

if only there were a formula with just multiplication and no addition :evil1:

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on January 21, 2017, 01:21:18 PM

Quote from: quaz0r on January 21, 2017, 08:30:17 AM

if only there were a formula with just multiplication and no addition :evil1:

Then it either goes to infinity or zero. Bye bye fractal structures.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: skychurch on January 21, 2017, 08:16:30 PM

Quote from: hapf on January 20, 2017, 09:52:09 PM

I don't know if this is old news but the perturbation approach and series approximation break down the more the closer one gets to the border of the main body or a minibrot copy.

Yes, that makes sense. Thanks for the insight. So it seems we can only tame the beast in it's less chaotic regions.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on January 27, 2017, 01:07:08 PM

Quote from: skychurch on January 21, 2017, 08:16:30 PM

Yes, that makes sense. Thanks for the insight. So it seems we can only tame the beast in it's less chaotic regions.

Well, there still are ways to speed up things even in dense regions. The perturbation and delta approach are not limited to
hardware bits... Of course the hardware bits offer the big speed up factors, but any speed up compared to full arbitrary precision
for each pixel is welcome.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: skychurch on January 28, 2017, 06:02:15 PM

Quote from: hapf on January 27, 2017, 01:07:08 PM

Do you think it's worth implementing a 128 bit mantissa for the SA calcs as well as a wide exponent?

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: hapf on January 29, 2017, 12:10:46 PM

Quote from: skychurch on January 28, 2017, 06:02:15 PM

Do you think it's worth implementing a 128 bit mantissa for the SA calcs as well as a wide exponent?

Depending on where you want to go, yes.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: skychurch on January 29, 2017, 09:03:46 PM

Quote from: hapf on January 29, 2017, 12:10:46 PM

Depending on where you want to go, yes.

Cheers. I'd better get to work. :D

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: therror on September 23, 2017, 09:10:09 AM

Hi! How to find coefficients A[k] for Multibrot arbitrary integer power? Does exist generalization of formula in http://mathr.co.uk/blog/2016-03-06_simpler_series_approximation.html ? Thanks )

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 24, 2017, 07:29:36 PM

Quote from: therror on September 23, 2017, 09:10:09 AM

Hi! How to find coefficients A[k] for Multibrot arbitrary integer power? Does exist generalization of formula in http://mathr.co.uk/blog/2016-03-06_simpler_series_approximation.html ? Thanks )

I asked on M.SE, which shows how to get the equations for the A[k], just not in an explicit recursion (you have to expand the power series and collect terms):
https://math.stackexchange.com/questions/2443377/closed-form-for-these-power-series-coefficients
The equations for the A[k] coefficients are defined implicitly, don't know an explicit closed form solution. The implicit form may be enough, depending what you need to do.

Title: Re: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.
Post by: claude on September 28, 2017, 10:20:19 PM

I answered my own M.SE question, with Maxima source code that can be used (with only a little extra manual work) to get the explicit recursion formula for a specific P.

The problem for arbitrary P is that (in code terms) you'd need nested loops to a depth of P-1, and most programming languages don't let you do that easily.