compiling Kalles Fraktaler with mingw

[claude]

Oh   No time to look into it today, sorry..

[Kalles Fraktaler]

Oh   No time to look into it today, sorry..

No problem, no hurry.

When you have time to look at this again, may I ask you for a small change?
In the file fraktal_sft.cpp can you replace the two occurencies of

Code:

iter=sqrt(iter)

with

Code:

iter=log(iter+1)

This is for the distance estimation coloring method, and makes the contributions from different layers (close passages of minibrots) be almost linear.

[claude]

No problem, no hurry.

I think I fixed it, was the exact same issue as the diffabs() preprocessing, but with the abs() function - a single character fix 

When you have time to look at this again, may I ask you for a small change?
In the file fraktal_sft.cpp can you replace the two occurencies of

Code:

iter=sqrt(iter)

with

Code:

iter=log(iter+1)

This is for the distance estimation coloring method, and makes the contributions from different layers (close passages of minibrots) be almost linear.

I found two occurences taking into account whitespace differences, but I only changed the second one (colouring method 6/7 or so), leaving the first as-is (colouring method 1).  I hope this is what you intended?  Otherwise I can change the first one too.  The colouring code one of the parts of the code I haven't looked at in much detail so far.

New build 20170822 at https://mathr.co.uk/kf/kf.html upgrading is recommended as versions 20170703​ through 20170820​ have broken formula implementations, and earlier versions are less optimized (especially for quadratic Mandelbrot).

Ideas for future development include:
* extending the formula preprocessor to reference calculations, potentially allowing lower-level GMP functions to be used in the inner loops so temporary variables aren't reallocated and freed every single iteration.  this should provide a healthy speedup to every formula
* fixing the OpenCL stuff so that it actually works
* adding Pauldelbrot's multiwave colouring algorithm (will need a lot of GUI work I suspect, something I don't find fun, as well as delving into the .kfr (de)serialisation code that I haven't touched so far)

[Kalles Fraktaler]

Excellent, it works now!

[Kalles Fraktaler]

Hi Claude

I am very impressed that KF is now able to find a minibrot at around <-2,0i> on arbitrary depths - the previous versions would either crash or give some unreasonable result!

However here is another thing to look at whenever you have time.
The Newton Raphson function fail in the center of this view.
It works on my old version (and takes minutes while your version would take seconds... )

[claude]

Worse, loading that "no newton.kfr" gives me a blank turquoise image
Zooming from it in either direction gives something more sensible.

Newton-Raphson zooming at that location in KF seems to give a bad period of 499 when it should be 18166 (checked with my standalone m-box-period code).  Don't know why yet...

[claude]

New build! 20170913 at the usual https://mathr.co.uk/kf/kf.html Not many changes, just documentation updates, limit number of approximation terms to 60 at most, and the color method 7 = distance (logarithm) detailed below:

In the file fraktal_sft.cpp can you replace the two occurencies of

Code:

iter=sqrt(iter)

with

Code:

iter=log(iter+1)

This is for the distance estimation coloring method, and makes the contributions from different layers (close passages of minibrots) be almost linear.

I reverted this change.  Instead I added a new colouring method ID 7 with this logarithmic scaling.  This is to preserve compatibility with square root scaling expected by earlier parameter files.

Kalles, you'll need to update the movie makers to match the implementation of the latest version (I consider the behaviour of the 20170822 build to be buggy in this respect).

[claude]

New build at the usual place, version number 2.12.1 since Karl confirmed he won't be making new versions of his own.  Main features are PDF manual and both 32bit and 64bit builds (all in one zip with the source too).  Bugfixes to Examine Zoom Sequence and Distance colouring backward compatibility.

[claude]

new version 2.12.2 at the usual place, lots of new features, please test to check I didn't break any of the more unusual formulas in the process of massaging formula XML so the preprocessor could work its magic.  Changes:

- PNG image saving support using libpng and zlib;
- JPEG default quality to 100 (was 99);
- colouring uses floating point internally to reduce quantisation steps;
- dithering at end of colouring to improve perceptual quality;
- formula.cpp included in source zip so GHC is not needed unless changing formula code;
- optimized diffabs() code: one test Burning Ship location is 7.5% faster;
- preprocessor optimizes reference calculations by floating temporary variable (re)allocations out of the inner loops: one test Burning Ship location is 30% faster;

[gerrit]

Thanks so much for doing this!

Could perhaps the need to oversample (typically factor 6-8 I find) to get the DE to look good be mitigated by using a higher order finite difference approximation for the derivatives?

Looking at the code it seems you use a first order FD.

[claude]

I don't think it would help.  The places where the DE colouring looks bad are close to the boundary, which is a discontinuity/singularity in the derivative.  But if you provide some example code or formulas I can try it out soon and report back.

[gerrit]

I don't think it would help.  The places where the DE colouring looks bad are close to the boundary, which is a discontinuity/singularity in the derivative.  But if you provide some example code or formulas I can try it out soon and report back.

Probably the first thing to try is the central difference, which is second order. See e.g. https://en.wikipedia.org/wiki/Finite_difference.

[gerrit]

Here's a quick hack in MATLAB trying central difference and 1st order method.
Plot is .
Central difference seems a bit better.

[gerrit]

Interestingly going to a 4th order stencil for the gradient does not improve further.

[gerrit]

One more result: using the average of normal and diagonal central differences does improve a bit over just central. See example.
So the squared length of the gradient of map m at point x,y is taken to be the mean:

with