Smooth iteration alternative - new ?

[David Makin]

Hi all, was just playing around with the smooth iteration method I use and noticed that when using the "auto-power" method, if the bailout constant is ignored then we can boil down the smooth iteration calculation to this UF code:

Code:

TestAlternativeSmoothIter {
init:
  complex zold = #z
loop:
  zold = #z
final:
  #index = #numiter - (0.5*log(|zold|))^(1.0/#e)
}

Problem is that as with all the smooth iteration methods it depends on the orbit approaching infinity - in this case much more than in others - but it works well on the standard z^2+c with a bailout of 1e50
The bailout needs reducing for higher powers, e.g. use 1e4 for z^10+c.
It's nice in a way as the colouring itself doesn't need to know either the divergence (power) or the bailout value.

[David Makin]

Hi all, was just playing around with the smooth iteration method I use and noticed that when using the "auto-power" method, if the bailout constant is ignored then we can boil down the smooth iteration calculation to this UF code:

Code:

TestAlternativeSmoothIter {
init:
  complex zold = #z
loop:
  zold = #z
final:
  #index = #numiter - (0.5*log(|zold|))^(1.0/#e)
}

Problem is that as with all the smooth iteration methods it depends on the orbit approaching infinity - in this case much more than in others - but it works well on the standard z^2+c with a bailout of 1e50
The bailout needs reducing for higher powers, e.g. use 1e4 for z^10+c.
It's nice in a way as the colouring itself doesn't need to know either the divergence (power) or the bailout value.

Correction - unfortunately it seems to be dependant on using the correct bailout, rather than just using the largest possible bailout though I suspect the correct value to use is somehow related to the formula divergence (I don't just mean avoiding overflow).

Because it's based on the auto-power method when using the right formula bailout it smooths exp(z)+c "properly" and smooths the Lambda Mandelbrot all over equally. However it plain doesn't work for conditional formulas such as Barnsley 1 or 2.
Haven't tried the convergent equivalent yet and it's time for bed....

[David Makin]

Hi all, was just playing around with the smooth iteration method I use and noticed that when using the "auto-power" method, if the bailout constant is ignored then we can boil down the smooth iteration calculation to this UF code:

Just played around a bit more and fixed it so it worked for any bailout and power provided you specify said bailout and power and discovered that it's actually not as good or as fast as the standard "old" method.

So in case anyone's wondering, here's my description of the "old" method - with the benefit of hindsight

Explained in Fractint and UF terms for complex values where |z| means x^2+y^2 (where z = x+i*y) and the value of x^2+y^2 is tested against the bailout value:

1. Taking log(0.5*log(|finalz|)) essentially gives us a linear value for the potential within each iteration band.
2. The minimum value of log(0.5*log(|finalz|)) is log(0.5*log(bailout)) so adjusting the log(0.5*log(|finalz|)) value by log(0.5*log(bailout)) gives us a zero at the low end of the bailout value.
3. The maximum value of log(0.5*log(|finalz|)) is log(0.5*power*log(bailout)) where power is the divergence of the fractal formula.
4. So we can get a unit fraction in each iteration band using:

  (log(0.5*log(|finalz|)) - log(0.5*log(bailout)))/(log(0.5*power*log(bailout)) - log(0.5*log*(bailout)))

5. With respect to iteration count this is actually reversed in magnitude i.e. we want the range -1 to 0 rather than 0 to 1 so use:

  smoothiter = iter +  (log(0.5*log(bailout)) - log(0.5*log(|finalz|)))/(log(0.5*power*log(bailout)) - log(0.5*log*(bailout)))

6. In both numerator and denominator we have the subtraction of two logs - which can be converted to the log of a division.
Doing this with the denominator gives the familiar formula:

   smoothiter = iter + (log(0.5*log(bailout)) - log(0.5*log(|finalz|)))/log(power)

7. In actual fact the "power" here is only an estimate usually based on what the divergence tends to as the bailout increases but we can actually correct the formula by using the actual divergence at bailout by substituting log(|finalz|)/log(|zold|) for the power (where zold is the prevous value of z).

8. I've realised (while writing this) that converting the numerator to the log of a division rather than the difference of two logs is also optimum since the division can be converted to a multiplication simply by changing the sign of the log:

   smoothiter = iter - log(log(|finalz|)/log(bailout))/ log(power)

Since bailout is a pre-runtime constant the division by log(bailout) can be done as a multiplication by 1/log(bailout).

9. OK doing this as I go....substituting log(|finalz|)/log(|zold|) for the power gives the nicely balanced:

   smoothiter = iter - log(log(|finalz|)/log(bailout))/ log(log(|finalz|)/log(|zold|))

Now can log(log(a)/log(b))/log(log(a)/log(c)) be simplified any further ?

[reesej2]

Well, you can simplify it to (log(log(a)) - log(log(b))) / (log(log(a)) - log(log(c))), which I think is slightly easier to calculate. Overall, this seems like a good method... does it produce appreciably different images? Also, what's the computation time look like?

[David Makin]

Well, you can simplify it to (log(log(a)) - log(log(b))) / (log(log(a)) - log(log(c))), which I think is slightly easier to calculate. Overall, this seems like a good method... does it produce appreciably different images? Also, what's the computation time look like?

I meant was there any way to say eliminate log(a)

As to calculation time obviously using the fixed estimate of divergence is faster as it reduces the divisor to a fixed constant at runtime instead of 3 logs and the extra |zold|
The difference between the times taken is greatest when using the smooth iteration value *solely* for delta DE since then using the estimated divergence simplifies the calculation of the difference in smooth iteration values of two points considerably.
Having said that it's not a massive difference, for instance a z^8+c Mandelbulb rendered using calculated divergence that took 1 min 7 secs on my system took 1 min 2 secs using estimated divergence.

In practice whn calculating the divergence then using:

  smooth iter =   iter + (log(log(bailout)) - log(log(|finalz|)))/log(log(|finalz|)/log(|zold|))

Is probably optimum for speed, no change to your numerator because the bailout part can be precalculated here giving just 2 runtime logs and one subtract, the denominator changed to the dividing form because it reduces things from 4 logs and a subtract to 3 logs and a divide.

It's essentially what I was already using except it's eliminated some multiplies by 0.5 that I should have realised are not necessary

As to images, they won't be any different in my case, this just slightly optimises the calculation

Points to note about using the method are:

1. In some cases using log(|finalz|)/log(|zold|) can be reduced to log(power) where power is the estimated divergence of the fractal *however* this should only be done if divergence is consistent over the whole image otherwise there will be discontinuities at iteration boundaries.
For say z^p+c this means using power=p and a fairly high bailout - say at least 10,000.
For fractals where the divergence varies across the fractal a lot more (such as the standard "Lambda" Mandelbrots) then it's better to use the calculated divergence.
If it's possible to use the fixed estimate divergence (power) then the calculation of difference in smooth iteration for two points on a viewing ray simplifies to:

     i1 - i2 - log(log(|finalz1|)/log(|finalz2|))/log(power)

i.e. the bailout terms from the two smooth iter values cancel out - however you can't do that when using the calculated divergence because they don't have a common divisor.

2. Using the calculated divergence (in 2D anyway) means that smoothing works even for very low bailouts (even 4 on z^2+c) and it also produces good results on say exp(z)+c or Barnsley1 or Barnsley2 or sin(z)+c etc. without breaks on iteration boundaries (except where iteration changes really are geometrically discontinuous).

3. Using the calculated divergence also makes the smoothed iteration calculations more "black box" since the only value from the main formula required is the bailout value.

4. For more complicated fractal formulas (eg. 3D/4D) because calculation of smooth iteration is only done once at the end of the iteration loop the extra cost of using calculated divergence is usually very small compared to possible optimisations you can make to the calculations within the iteration loop itself.

[David Makin]

Well, you can simplify it to (log(log(a)) - log(log(b))) / (log(log(a)) - log(log(c))), which I think is slightly easier to calculate. Overall, this seems like a good method... does it produce appreciably different images? Also, what's the computation time look like?

Apologies, I was thinking mathematically instead of programatically - of course the above is better since you only need to calculate log(log(|finalz|)) once so it's a total of 4 runtime logs, two subtracts and one divide whereas using the division method in the denominator is  4 runtime logs, a subtract and two divides

[reesej2]

Well, if you could somehow get rid of those subtractions, like turn it into a ratio of two logarithms or something, it'd be even better. Don't think it can be done, though.