Am I missing something? or Does anyone still have a build of 2.5.3?

[plynch27]

I don't know if there's a configuration setting I'm missing or what, but I've recently downloaded the latest versions ─ first 2.5.8, then 2.5.9 ─ and, now, the program is taking upwards to 3 hrs to finish rendering even the first frame from reference samples. I saw the post about the high bailout settings and dropped the bailout value to something just above the iteration counts that were actually being returned, I double-checked it's affinity and priority settings in the Windows task manager ─ it's even reading 99% CPU the vast majority of the time ─ but it's still taking 3 hrs to be able to start taking its second set of reference pixels, when 2.5.3 was taking 40-50 minutes. At the very least, could anyone throw me a copy of 2.5.3, because I unzipped the new version over it.

[Kalles Fraktaler]

Hi plynch

Did you only replace the exe file without updating the DLL?
The dll was updated between 2.5.3 and later versions.
If the version number doesn't match it is not used and KF  cannot use long double and used the much slower floatexp.
In other words - rendering between e600 and e4900 is much slower without the DLL.
(Because msvc doesn't support long double so the dll is compiled with another compiler)

But you should have received a warning that ldbl64.dll is old when the program is started (or ldbl.dll if you are running 32-bit)...?

Edit: I found the issue and uploaded a new version, 5.6.
Thanks plynch27 for finding and reporting it, since even though I test a lot of locations, there can always be one more that doesn't work.

I have since 2.5.4 lowered the tolerance for Series Approximation since I found an issue with it being to high.
However since long double has higher precision than both double and floatexp, I now found out that the skipped iterations may be much less when using long double, for some locations, than floatexp (and double if the depth is less than e600)
I have made the tolerance higher for long double.

The only test location I have for testing long double is attached to this post.
The minimum iterations is 55278.
In 2.5.3 and now in 2.6 it is possible to skip 54688 iterations.
In 2.5.4-2.5.9 only 203 iterations were skipped.
These numbers can be viewed in the Iterations dialog.

[plynch27]

Okay, sorry I went all brainfart on ya thinking it was a more fundamental algorithmic problem. Oops. I'm retrying my work file on it, now. I'll get back to ya again when it's had enough time for me to see what's goin' on. Thank you.

[plynch27]

Okay, things don't seem to have changed much. I've attached the .kfr file that I'm using as a workspace. I know the program's algorithm has undergone a good-sized restructuring, recently, so there could easily be something I'm missing. Hopefully, you don't mind making "house call" for this specific file and, just to warn, you may need to zoom out of it quite a bit to do any debugging that may be necessary in any practical way.

[Kalles Fraktaler]

Thanks for the location, I will have a look.
The reference seems to take more than an hour on my laptop

Here is the exe for 2.5.3
I have unfortunately not stored the dll, but since the location is deeper than e4900 it is not used anyway.

[ellarien]

I still have the 2.5.3 .dll if it's wanted Actually, I think I have most of the old versions back to 2.4.0.

[Kalles Fraktaler]

I have now found what was wrong, it is still the Series Approximation.
2.5.3 had a tolerance of 0.001 and 99.4% of the iterations could be skipped for this magnumopuscontinued location, which still takes 1h50m on my machine - and that was just the first reference.
In 2.5.4 and later I changed that value to 0.000001 since I found a location where the previous tolerance was too large and caused glitches. Only 16.2% of the iterations can be skipped for magnumopuscontinued, and therefore 134 times more iterations needed to be calculated!

The reason I lowered the tolerance was this location, which doesn't render the corner correctly:

Code:

Re: -1.7497415120544229852294434038347923546464860116975
Im: 0.00000072462200351594671836485600005157469714403056546967
Zoom: 7.5E22

I have made and uploaded a new version 2.6.1 which has the tolerance for Series approximation configurable in the Iteration dialog.
The tolerance is low per default, so you need to un-check the checkbox in the Iterations dialog to be able to render magnumopuscontinued in a reasonable time.
When I did a test I forgot to turn off the automatic glitch correction, and magnumopuscontinued was completed in 2 hours with 2 references. A lot of time is won since 2.5.3, because only half of the iterations in the reference is needed.

Also, I previously lowered the threshold for glitch detection from 0.000001 to 0.0000000000001. This was the lowest I could use and still render "flake" correctly. However my french cyber-friend found that it is too low for this location:

Code:

Re: -1.99909561667938083696480473441748071930243692353350310411488642163662716544725177
Im: 0
Zoom: 1.6E32

So now I have increased it to 0.0000001, which is able to render both the above and flake correctly and is still lower than the original, which makes flake need only 11 references in 1280x720 instead of some 30.

As this is still new land for us, there are some values that needs to be fine tuned. I hope the result of this is useful also for Mandel Machine and others who want to do perturbation/series approximation rendering programs

[plynch27]

Yes!! I am back in business, baby! On this last frame, it gave me enough information for me to be able to perform my next zoom within half an hour. Thank you!! :-)!

The coordinates I posted were one of those few-and-far-between frames where the first set of references just couldn't provide enough information to perform a practically appropriate zoom and, thus, I needed a second set of references, but, most often, I don't even need to wait for it to finish rendering the first set, so, now, yeah, it's bought me a lot of time from ver. 2.5.3. Thanks, again.

I still have the 2.5.3 .dll if it's wanted Actually, I think I have most of the old versions back to 2.4.0.

Actually, an old buddy of mine, Justin Case, would still love to have a package of those. If you can't fit them within the 256KB limit of this forum, would you mind making an off-site upload and passing me ─ "us", if there's anyone else on the forum who wants them ─ the URL?

[ellarien]

Quote from: ellarien on Today at 04:09:51 PM

I still have the 2.5.3 .dll if it's wanted smiley Actually, I think I have most of the old versions back to 2.4.0.

Actually, an old buddy of mine, Justin Case, would still love to have a package of those. If you can't fit them within the 256KB limit of this forum, would you mind making an off-site upload and passing me ─ "us", if there's anyone else on the forum who wants them ─ the URL?

I could easily do that, if Kalle doesn't object? I think one or two of those versions are more or less broken -- a check of the forums would show which ones.

[Kalles Fraktaler]

No I don't object

And I am sorry I should have the old versions available on the site. But I haven't stored the executables only the code

[ellarien]

OK, here they are -- zip archive containing the zip files for 232, 240, 241, 242, 243, 250, 251, 253, 254 and 255.
That's all I have handy -- I think I was busy with something else and skipped 252.

https://www.dropbox.com/s/2vyxd48q2ktmg6i/fraktal_sft64-old.zip?dl=0

Enjoy! 

[Kalles Fraktaler]

Thanks a lot ellarien

I have put them on the web page.
If I make new versions I will keep the old versions on this page, from now!

[plynch27]

Hey Kalle, the jump in render time came up again. I hope you don't mind continuing to help. If you do mind, I can't blame ya.

Also, it just hit me that the .kfr files are on text format, not binary, so I don't need to package it; just extend its filename. Though, I've got a feeling that it wouldn't take much to talk Christian into white-listing the .kfr extension.

[Kalles Fraktaler]

Hi plynch27

I am not sure that there is much I can do, unfortunately. Are you beginning to center the zoom?
I have started to render your location but it will take some time...
The more complex view, i.e. the bigger difference between lowest and highest iterations, the less iterations Series Approximation will be able to skip. Also, the number of iterations that can be skipped cannot be higher than the lowest iteration value, and the number of skipped iterations jumps up and down during a zoom.

I have been playing with arbitrary number of terms in the SA calculation, inspired from Botond and Mandel Machine (but KF is still much slower). However the time to calculate SA increase exponentially for more terms. The optimal, at least for Kalles Fraktaler, is 10 terms for resolution 640x360. The bigger image the more time can be saved with more terms.

I just uploaded a new version 2.6.2 and I hope it is ready.

Edit: Oh yes! It worked better than I expected!! With 10 terms (and "Approximation low tolerance" unchecked) 6568415 items are skipped, and minimum iterations is 6568659. The difference is only 244!