Welcome to Fractal Forums

I would like to use KF to compare renderings with my SFT hacks to verify that I haven't made a mess of it, but...

I have some location with 2000+ digits, when I put these into KFs "Location"  requester the values are truncated to about 700+ digits and end up rendering the wrong location making a comparison at E2280 impossible.

When rendering the same location at about E50 with re&im truncated to the same length they look comparable.

Is this a limitation of the requester input widget? or am I the only one seeing this? kf-v2.5.3-64 on linux via wine.

RE:KF
-1.628525034382336188383826254854504541034866123658414160176944648059774261397865286688453414701543869586633032490835896
78966399541038911247108589834009305485135565610432065322034212454490261441840889724143509680838846674444199679053462961
22369829125808715959589508004033683543856979653688355703357362596797912790215729307519005701670693821446556437233617104
78988865179746415925444577996083120439879996353114415182615797948749865395234776209818146361578177184267620074208435764
66945869241303789441762327453111585403712108891625202499983591308412642062610561749281602956143514640379662188892624823
25314900811659507013764935080677766364077648061558048528248826421672925677934772942435112381237394313059764692573179982
63378769

RE:SFTC
-1.628525034382336188383826254854504541034866123658414160176944648059774261397865286688453414701543869586633032490835896
78966399541038911247108589834009305485135565610432065322034212454490261441840889724143509680838846674444199679053462961
22369829125808715959589508004033683543856979653688355703357362596797912790215729307519005701670693821446556437233617104
78988865179746415925444577996083120439879996353114415182615797948749865395234776209818146361578177184267620074208435764
66945869241303789441762327453111585403712108891625202499983591308412642062610561749281602956143514640379662188892624823
25314900811659507013764935080677766364077648061558048528248826421672925677934772942435112381237394313059764692573179982
63378769319816958015265774485675143369849269237733599474901955039753217655915825610865097716734842993621016545959138838
01323969389180163700871844758080786393937576034131904742929385523272933801335342850192984601738950379089556673216106792
27754301569789651633727819129250336167769271075928393119318923691654376785179080771552211515665905264906708962138726151
99414900144901946339747904518296188690121228361249133639477119632327513376110996457254269575538009626576476259137926259
94561062814399643393500722792913247325712605642371424205767752678073693495345663304124047557563364594659569510341511164
04848826730525105721586890037428787237038197776243211306811374870319466449517108214150449500776387260434364774337004520
49516516718581783192450056190846325465230619957817834590811547643729267855245950261457382135369395398869612795897432865
06729650150152287759299775870001287921387983274040588712409966022980082849502819430769388867342776440458365630390694942
01953870495063721543445809479277362458262713083729258720260307404027491495620550880838297507725696875313291575667252286
85359687435386778428102982188657669948751271273310360050793692188634974395369422951554971132643949261329123721560329816
91412591441528447707805126375239250736797878601094790342063024097540568983096488865377948898851491531795018041947502837
59903281141127251875739584248323872821969165486022504258101976367944187260084192016601951246606086454171702371240826323
62842559814453125E+00

edit:using kf 2.5.6 managed E1700 but have to paste coords into "Location" requester before new render

any chance on adding linux support to this program?

yeah i just tried it in wine it seems to work fine.  before trying the windows binary i downloaded the source just to take a peek i bet it would not be an overly ridiculous amount of work to change the windows stuff to gtk stuff or something?

@3dickulus
There may be a limitation in the transfer of text from the edit boxes.
You can also store a simple location and then edit the kfr file instead, which is simply a text file.

Another thing is that KF doesn't parse exponents from these location values. It just ignore anything that is not numbers and decimal dot is expected after the first value digit.

using wine on linux...

1. run KF
2. open "Location" requester
3. enter a very long RE: value
4. close requester (hit enter key)

open the location requester again and the value is truncated to 28 characters when zoom=1

it seems to be (zoom exponent) + 38 after zooming in some amount

when loading from a settings file the numbers are also truncated to  (zoom exponent) + 38, to test this I edited a deep zoom kfr file to contain re/im coords with 250 digits and a zoom of E55, this truncated to 92 ? in the requester.

Do you with 'requestor' mean dialog?
Yes the digits are indeed truncated. Because you don't need the possible 150.000 digits if you are zooming on for example e55. It saves a huge amount of calculation time to truncate like this.
92 may also seem unnecessary much for e55, but is needed when zooming along <-2,0i> because they way I have implemented full precision with a fixed decimal point and no exponents.

yes, mean "Dialog"

from a math stand point, yes, 150,000 digits are not needed until you get  to the level of zoom that requires them

this shows up because I am testing SFTC against KF and was checking render speed and glitch detection "along the route", so I have deep location around E2200 but want to check at E600, E1200, E1800 etc. as long as I check from deepest to shallowest and reload the deep location before moving on, why doing this? after adjusting some routine and recompiling I test a few problem spots or interesting features to see if I break anything.

the truncating does not present any real problem as I can save a zoom sequence and go back to examine frames  but when entering locations created outside of KF this little factoid is handy to know.

 :beer:

I have tried this several times but I can't get it to apply a different gradient.  :-\

I am doing a render, when it is complete I will try it again. :)

Here are some results of my tests, KF still has a nicer render and interface and is faster sometimes, but...
if there is something that I've stumbled upon that might make it better I would like to share...

Test 1 E1804 - E1870

          Comp-1        Comp-2        Comp-3        Comp-4        Comp-5        Comp-6
------------------------------------------------------------------------------------------------------------------------------
KF      05:02.014    00:52.587     06:31.486     04:43.667     02:15.123     06:07.371
SFTC  00:36.271    00:35.003     00:35.615     00:49.739     00:56.081     00:41.309


Test 2 At the Polished Emerald location

zoom @E355          SFTC falls down @E405
---------------------------------------------------------------------------------
KF :o 00:00.863      KF    00:26.193
SFTC 00:11.752      SFTC 00:50.658

Test 3 At Kalles Julia Morph location

zoom@e500        zoom@e604
---------------------------------------------------------------------------------
KF     00:29.960    KF     06:58.014
SFTC 00:18.878    SFTC 06:06.897


Here is the source as a QtCreator project (http://www.digilanti.org/cudabrot/), compiles on Linux and Windows.

You will find all of the test files and comparison images in the zip file, all tests are @ 640x360

This is still very beta so a few menu items are not hooked up, no animating, no palette dialog and the interface will undoubtedly change

And a BIG BIG thanks to knighty for helping with the windows debugging and static arprec lib  :beer:

EDIT: corrected times, tested with the same iteration limit.

That looks like really good render times, comparable with Mandel Machine!

Are you using SIMD?
Have you also implemented Pauldelbrot's glitch detection and automatic glitch solving?
 :beer:

my math skills are rudimentary, I'm a hacker at heart and just can't leave it alone :)
I'm pretty sure that I have not implemented Pauldebrot's glitch detection correctly, at best not the way intended.
The reference point is selected as per the original Java SFT code with an extra "hunt and peck" sort of method devised by me that doesn't catch them all by any stretch of the imagination.

SIMD? I'm just using standard gcc++ with no special asm coding or options other than what is presented by QtCreator when generating the project, seriously, nothing special here.

Using double and long double with arprec for the big stuff.

Would love to compile this to run on the Symbian S^3 Operating system (the one on my ancient Nokia N8 phone) but I haven't got the faintest idea how to accomplish this.

Any ideas?

If it is not simple I wonder if someone who knows could spare some time or give some great pointers on how to achieve this.

Many thanks.

Pauldelbrot's glitch detection method makes it possible to identify incorrect pixels and add additional references and recalculate the pixels that were previously incorrect.
So, if the calculation of the references takes a significant amount of the total time, additional references will make a big difference.
And if you are using a maximum iteration number that is several times higher than the highest pixel in a location, the time to render the image will be even much slower for each additional reference.
And also, this glitch detection method needs to be checked for every iteration, so some of the standard Mandelbrot optimizations are not possible.

But it is indeed possible to make a program faster than KF
1. SIMD!
2. Faster binary based ap (which I think is what you have?)
3. More terms in SA
But if your program doesn't take the glitches into account, you should compare it with Mandel machine instead because it is not doing the same things as KF does. :)

I was doing Symbian some years ago. But.... Nokia and Symbian are so outdated these days with iPhone and android...

the glitch detection goes like this...

stage 1 reference = 0,0, flagging pixels as fail with if( fabs((c+dx)/dx) > 1E6 ||  fabs((ci+dxi)/dxi) > 1E6 )
stage 2 hunt for a blob and estimate locus, set as second reference, recalculate flagged pixels
stage 3 try to find the highest iteration location from the pixels that are left, set as third reference, recalculate flagged pixels

each reference uses the last one to pick the next one ? something like that.

as for comparisons KF is a much better program.

Yes that is indeed Pauldelbrot's glitch detection!
Edit: That is similar to Pauldelbrot's glitch detection, but I cannot estimate what difference it makes by not squaring and adding the real and imaginary parts. Perhaps your method is faster and works, perhaps not.
KF is only repeating stage 2 until no more pixels are flagged as glitches :)

But you have showed one good and obvious point! One of the KFB files in your zip have maximum iterations on about 100,000 but the highest iteration in the result is some 10,000. So the reference calculation takes really unnecessary long time and I will make an update on that (+rotation!)

I also use (x-y)*(x+y) instead of (x*x)-(y*y) , only one mul

the max_iteration in at least one test is 25000 vs 2800000 but I think these were picked as upper limit by the programs themselves as the required max for that location. I will look at this and try to balance the counts for a better comparison,

over limit = bailout, so I think a few more than required is a normal thing?

I use KF for comparing because it's good and I trust that it renders correctly, I really don't like java so if a prog has a prerequisite of JRE and won't run without that monster then I'm not interested. Just a personal preference :)

just tested that and it makes a big difference, in both programs, I will definitely check all files for calculated vs preset and redo all tests with = iteration counts.

when zooming-in the iteration limit is increased but it is never decreased when zooming out (SFTC), I think KF does too? I will have to be careful not to muck about causing the program to calculate a new limit before a test render.

What I meant was that it probably doesn't make much sense to calculate the reference far beyond when it has reached bailout, because beyond that it just produce large useless numbers. But I need to test that carefully.
So you have made a very good tip for improvement! The reference iteration count should be slimmed. :)

What I do in mightymandel[1] is to compute the reference in parallel with the pixel iterations, interleaved in blocks - so I compute the next N reference values, then step all the pixels N iterations, and repeat.  This way I don't need to guess how many iterations of the reference might be needed in advance, and I don't have to store the whole reference orbit in memory at once.

[1] https://gitorious.org/maximus/mightymandel (specifically https://gitorious.org/maximus/mightymandel/source/HEAD:src/fpxx_step.c#L106 )
[1] http://code.mathr.co.uk/mightymandel (specifically http://code.mathr.co.uk/mightymandel/blob/HEAD:/src/fpxx_step.c#l108 )

Cool. Can we download the executable?

Sorry no, just source (I work on Linux).  I could switch out the gtkglext dependency and revert to GLUT to make it easier to compile on other platforms, if there is demand, but it's more a proof of concept / toy than a fully featured explorer at this stage.

is that as a result of the way GLSL works? or part of the plan by design?

I've been following some of your work (mighty mandel, mandelbrot-delta-cl), fascinating GLSL code.
Recursive/iterative stuff on the GPU using higher precision math has been slower than expected in my tinkering.

It sort of falls out naturally from the computation of pixels all at once in parallel, combined with having to iterate in blocks to avoid the GPU driver taking too long for a given operation and blocking the OS.

EDIT: oops misunderstood which re/im parts you were referring to, you meant in the glitch detect test, a little faster?

It works, gives the same answer, algebraically the same, saves one mul and reduces influence of cancelation when the numbers are very small (better accuracy)
when you are doing a few million loops it makes a noticeable difference.


I did one version of cudabrot that setup a screen sized array for each variable then applied the M formula in one go but it sucked up a LOT of ram and wasn't really any faster, but that was with no perturb or series approx, just straight iteration to max.
 

So, calculate reference until x*x+y*y > 4.0  and not all the way to iter_limit?

I note that in the SFTC reference calculation there are 3 break points in the "while (count < mIteration_limit-1)" loop, but they don't look like the escape test, more like precision/accuracy tests.

how might this be done? is it as simple as the x*x+y*y > 4.0 test ?

The results are in :)

                      Comp-1          Comp-2          Comp-3          Comp-4          Comp-5          Comp-6
                     ---------------------------------------------------------------------------------------------------------
KF-2.5.6        05:02.014       00:52.587       06:31.486       04:43.667       02:15.123       06:07.371
KF-2.5.7        02:54.307       00:46.515       05:44.356       05:13.242       01:34.398       08:24.681
SFTC60 (http://www.digilanti.org/cudabrot/)         00:36.271       00:35.003       00:35.615       00:49.739       00:56.081       00:41.309

At the Polished Emerald location

                 zoom @E355         SFTC falls down @E405 can't zoom any more at this location
                 ---------------------------------
KF-2.5.6   00:00.863  :o    00:26.193
KF-2.5.7   00:04.068  :sad1:   00:19.022
SFTC60 (http://www.digilanti.org/cudabrot/)    00:11.752  :'(   00:50.658

At Kalles Julia Morph location

                zoom@e500  zoom@e604
-----------------------------------------------
KF-2.5.6   00:29.960     06:58.014
KF-2.5.7   00:30.789     06:26.530
SFTC60 (http://www.digilanti.org/cudabrot/)    00:18.878     06:06.897

took a hit at the polished emerald location but over all performance is up :dink:

I hope your honeymoon was great!
I have also done that (twice... :))

The thing you are measuring is how clever the programs are to add additional references.
But does your program add more than 2 extra references? I don't think that sufficient to solve all glitches in all locations?

I realized that 2.5.6 did not add the references where it was intended. Sometimes that was a good thing and less references needed to be added, sometimes not and more references needed to be added. For example glitch blobs occurring after a close passage of a Minibrot's elephant wally have a spiral inside, and the center of that spiral is close to the edge of the blob and not the center.

Thanks very much :) Harrison Hot Springs Resort was really nice, soaking in the lap of luxury, oooo, ahhhh, but I only want to do that once  :dink:
...the honeymoon is over,  :'( back to fractals :D

just 3 refs, yes, some images need more and in many cases it looks great until you pan or zoom, my method is not very good and needs work, but the engine is running and pulling hard towards a GPU version. I will rethink my approach to glitch solving, a.t.m. no manual selection or turning detection off/on and no re-use ref option, it should be automatic though, because having to make/save solutions manually for 100s of frames in the 1000s that make up a movie is too laborious, when it has been demonstrated (kf) that the machine can do it.

should impliment this way ?
------------------------------------------------------------------
using Grid method first ref @0,0
scan X for largest width blob in at least 3 places, 1/4 Y 1/2 Y and 3/4 Y
scan Y between min blobX and max blobX for largest height
x1,y1,x2,y2 == blob bounding box opposing corners
if circular (x2-x1 == y2-y1) use center else if peanut (x2-x1 != y2-y1) estimate locus with golden ratio logic
if no blob is found then use the location encountered with highest iteration value

second ref @estX,estY
render image

if glitchPixels != 0 scan again using "attract to highest" method
render only pixels

if glitchPixels != 0 repeat with higher precision?
------------------------------------------------------------------
that's not the way it works in SFTC but heading that way, I would also like to try (again) handing glitch pixels off to an arbitrary precision routine when they are encountered at the approximation stage, so far it hasn't worked well, I think because by the time a glitch pixel is detected the precision has already been lost... hack hack hack :) like when a location is < re-11 or ie-11 SFTC falls down, needs your custom fixed point type or I need to figure out how to use ArPrec's fixed point features and when to enable them :)

perhaps this will illustrate my "hunt and peck" reference selection, a picture is worth a thousand words
the straight lines are from ref@0,0 estimating a ref point in the blob (not where they meet but a ratio of the h/w) corrects the blobs
the spiral path is route taken by the "attract to highest" routine selecting the third ref at the end of the path, corrects the antlers

coords...

edit: at the end of the spiral path you can see it kind of bunch up, that's where there is a tight group of the highest iter antlers so it catches all of them and not just one or two outer levels

Yes, it is interesting to compare how many references needed to make an accurate image!
The location you are using should be rendered correctly with 2 references.
The antlers are the result of a close passage of a Minibrot which is less than e13 deep, and therefore it's influence is within the precision of a double and can be rendered correctly from the center reference.
The spirals are the result from a second Minibrot which is deeper, around e23, so a second reference is needed.

Here is another location for you to test. The first Minibrot is some 1e20 deep and it is also passing a second Minibrot at some e40.
So you should need at least 3 references, but since you are using the second reference to find where to put the 3rd, I doubt you can render it correctly with 3 references.
And if you can, I can provide you new location that need 4 references and so on ;)

I mentioned earlier that SFTC has no special provision for locations close to 0.0 like this with i@nE-22 so... I'll give it a try anyways...

26.12 seconds  :D

edit:KF 12.5 seconds :dink: I'm surprised that SFTC rendered that location at all, a little rough, approaching limits.

I am sorry I don't understand your spirals. But if there is more clever way to select extra references that is very interesting.
The staight line is not through the center of the image?
I don't understand how these spiral are calculated?

Regarding my latest location, how can your program take as long time as 26 seconds?
KF would render it in 1 second if it weren't for all the 70+ extra references needed...
The threshold could be lowered and fewer pixels be marked as glitches.
However, if the threshold is lower it may work with some images but not others.
Finding them all takes forever....

I really don't know, maybe it's just 3 refs instead of 70 :hmh: not as much approximation data so more iterating?
and the math is only what was in the original SFT Java code, no extra approximation or additional terms.
ArPrec lib uses fft and a modified Taylor series internally to speed up operations

The straight lines represent the pixels tested when doing an initial search for a blob after generating the first reference @0,0 testing for a group of failed pixels larger than 20.
Plotted them only for illustrative purposes, they serve no function other than a visual aid so I can tell what's going on.
The spirals are the same thing but for the search after generating the second ref from a point in the blob.

On the second pass, after rendering an image from the first (blob) reference you can check in the rendered data instead of calculating the iterations for points when testing for more blobs, but SFTC currently is calculating iterations and looking for the highest location on the second pass when looking for the third ref.

edit: I find it rather amusing that we think of 26 seconds as a long time to render an M set image @E79 :laugh:

Hmm...

The first location actually need only one reference to be displayed decently without notable difference, if it is placed in the center of the deep spiral.
The glitch detection detects glitches on many pixels that looks OK without glitch detection.

If only one reference is used on the second location, the antlers get structured glitches. It is hard to see unless the image is very large.

So... until someone (most probably not me...) finds a clever way to know where to put the references, I think we have to live with that sometimes a unnecessary large number of extra references needs to be added. Especially for a general Mandelbrot explorer that can handle all locations.

if glitches are one pixel they will be very likely to get lost in jpeg or mpeg compression, this is why I am not getting too picky about single pixels and concentrating on the larger areas, it seems that when you nail the big ones a lot of the small ones get covered by the new reference.

in the stage 1,2,3 pics, (page 2) the antlers look messy, it's the palette, light bands next to dark bands in a tight pattern, looks better with an adjustment to color spread, the two clips are from the same iteration data.

Very interested to explore this, in SFTC I am having problems with the PolishedEmerald location that doesn't make sense to me, KF renders it perfectly and has no problem panning and zooming, SFTC can't pan or zoom on this location. At first I thought it was going wonky because the im coord is at E-11 and it seemed to be a precision problem with coordinates but SFTC renders DDs Flake location perfectly and it has an im coord at E-34 so that's not it.

Accessing the reference data in a skewed manner seems more likely but that would indicate a loss of precision somewhere else in the process,
eg: ref calculated at -2.22652,-0.00573 but accessed as though it was -2.227,-0.006 ??? from lost bits or rounding ??? it does make nice pics though, I found this hedgehog? at the PolishedEmerald location by manually moving the center a bit, but this tells me something is amiss, it should be round and symmetric.

It would be very cool to gain control over this for "sculpting" images.