*Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.

[quaz0r]

well, if paul's method is faster and doesn't fall down ever, then great.    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.     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 

[stardust4ever]

well, if paul's method is faster and doesn't fall down ever, then great.    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.     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 

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

[quaz0r]

 

[hapf]

well, if paul's method is faster and doesn't fall down ever, then great.    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 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.

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.     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 

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.

[quaz0r]

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?

[hapf]

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.

[hapf]

I looked into using more bits for the deltas to avoid corruption. It did not work at all. 
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   
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. 
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

[hapf]

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

[stardust4ever]

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:
<snip>

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

[hapf]

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).

[hapf]

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). 
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.

[stardust4ever]

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...  

[quaz0r]

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

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?

[stardust4ever]

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.

[Kalles Fraktaler]

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?