|
asimes
|
 |
« on: March 14, 2012, 07:43:35 AM » |
|
I must be missing something really obvious... I don't really know what I'm doing wrong. I just discovered this: http://softologyblog.wordpress.com/2011/05/10/more-ducks-and-kaliset-variations/and I wanted to try out some of the formulas. The first one, z=1/abs(z)+c, seemed easy enough but didn't work for me. I don't have complex variables to work with, I have to keep track of real and imaginary myself: - I use 'x' and 'y' to be the real and imaginary parts of 'c' - I use 'zr' and 'zi' to be the real and imaginary parts of 'z' - I assumed that the abs(z) is sqrt(zr*zr+zi*zi) - I assumed that the abs(z) should only affect the real part of 'z' In a double for loop that goes through all the 'x' and 'y' of the screen... float zr = x;
float zi = y;
int n = 0;
while (n < maxIterations) {
float zMag = sqrt(zr*zr+zi*zi);
zr = 1/zMag+x;
zi = y;
if (zr*zr+zi*zi > 16) break;
n++;
} |
|
|
|
|
Logged
|
|
|
|
|
element90
|
|
« Reply #1 on: March 14, 2012, 09:32:50 AM » |
|
The abs function used in many formulae especially those derived from UF is NOT the magnitude of the complex number, the function strips the sign from both the real and imaginary components.
What programming language are you using?
If at all possible use a programming language that supports complex numbers as it will make your life much easier. As the complexity of the formula you wish to implement increases the difficulty in using pairs of real and imaginary numbers increases significantly especial when it comes to using non integer powers, complex powers, trig function etc. As a result implementing formulae is error prone.
An other thing to note about Ducks and Kaliset variations is that they usual do not have a bailout condition and are coloured using inner colouring techniques, exponential sum works well. Use a low number of iterations for example 40 or fewer.
|
|
|
|
|
Logged
|
|
|
|
|
asimes
|
|
« Reply #2 on: March 14, 2012, 04:51:01 PM » |
|
Ah, that makes more sense then. I've never done inner coloring, I'll have to try that out before I get the equation going then. I'm using Processing and Java.
|
|
|
|
|
Logged
|
|
|
|
|
element90
|
|
« Reply #3 on: March 14, 2012, 05:26:21 PM » |
|
From a quick look on the web there are complex number packages available for Java, I haven't look far enough to find a suitable package to download, I'm sure that you can find a suitable package or ...
If some one on this form knows of a complex number package and where to download it from then please feel free to add to this thread.
It is worth your while using a complex number package rather than wasting your time doing complex number arithmetic and keeping track of the real and imaginary parts yourself with the all the associated debugging as the package should've had most if not all the bugs squashed.
|
|
|
|
|
Logged
|
|
|
|
|
asimes
|
|
« Reply #4 on: March 14, 2012, 05:55:58 PM » |
|
To be honest I would rather figure it out myself. It's pretty hard for me since I'm not used to it yet but I'll get it eventually.
|
|
|
|
|
Logged
|
|
|
|
|
asimes
|
|
« Reply #5 on: March 15, 2012, 02:00:00 AM » |
|
I'm having a really hard time finding an interior color tutorial, the Wikipedia explanation is complicated and I haven't had luck with Google. Could someone please explain (even without code) how this works or point me in the direction of a tutorial please.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
Kali
|
|
« Reply #7 on: March 15, 2012, 04:37:07 AM » |
|
I'm having a really hard time finding an interior color tutorial, the Wikipedia explanation is complicated and I haven't had luck with Google. Could someone please explain (even without code) how this works or point me in the direction of a tutorial please.
A simple one could be to calculate the average value of the magnitudes at each iteration, then applying a color palette based on this result. Just store the sum of the magnitude values divided by the number of iterations you are doing (include a line like this on the iteration part: average=average+magnitude/maxiterations) Best results are obtained using "exponential smoothing", or "exponential sum" as element90 pointed... here you must calculate the accumulation of the exponent of the magnitude change at each iteration, like this: total = total + exp(-1/(abs(magnitude - previousmagnitude)) Then pick color based on the resulting total. Btw, original Kaliset ( http://www.fractalforums.com/new-theories-and-research/very-simple-formula-for-fractal-patterns/) uses real numbers only. Good luck... Kali |
|
|
|
|
Logged
|
|
|
|
|
asimes
|
|
« Reply #8 on: March 15, 2012, 05:00:28 AM » |
|
Thanks Kali, I'll try that out soon. One project obsession at a time... as soon as I figure out why I ended up with this technique instead of the one I shot for. I just discovered the method I got to work so far looks a lot better for Julia Interiors. I don't know what the technique is called though, does anyone know? It was referred to as bof60 because it appears on page 60 in "The Beauty of Fractals". Not a very useful name for me. Here's a Julia for c = (-0.75, 0):  |
|
|
|
|
Logged
|
|
|
|
|
asimes
|
|
« Reply #9 on: March 15, 2012, 07:04:53 AM » |
|
Kali, I tried out your equation and it makes some very nice results. However, it seems to have an interior and an exterior, maybe the method I used is not compatible? For the interiors I used the same method as the Mandelbrot and Julia I posted above but for the exteriors I just used standard Log Color (except that I left it blue to be able to differentiate easily). Kalibrot result:  Kali-Julia at (-0.2, -0.1):  |
|
|
|
|
Logged
|
|
|
|
|
asimes
|
|
« Reply #10 on: March 15, 2012, 08:31:43 AM » |
|
Opps, my bad... I was rereading the posts and forgot element90 had said not to use a bailout. No bailout, 50 Iterations, same color technique as above:  |
|
|
|
|
Logged
|
|
|
|
|
|
|
asimes
|
|
« Reply #12 on: March 28, 2012, 05:41:33 AM » |
|
Sure, this was written in Processing. If you have it this is ready to go // Alex: This name comes from page 60 if the book "The Beauty of Fractals"
float xmin = -2;
float ymin = -2;
float wh = 4;
int maxIterations = 1000;
void setup() {
size(800, 800, P2D);
}
void draw() {
loadPixels();
float xmax = xmin+wh;
float ymax = ymin+wh;
float dx = (xmax-xmin)/width;
float dy = (ymax-ymin)/height;
float biggestZMag = 0;
int interiorCount = 0;
float[] interiorDist = new float[width*height];
int[] interiorLoc = new int[width*height];
float x = xmin;
for (int i = 0; i < width; i++) {
float y = ymin;
for (int j = 0; j < height; j++) {
float zr = x;
float zi = y;
float closestZMag = 1000000; // Arbitrarily large
int n = 0;
while (n < maxIterations) {
float zrr = zr*zr;
float zii = zi*zi;
float twori = 2*zr*zi;
zr = zrr-zii-0.75;
zi = twori;
float localZMag = sqrt(zr*zr+zi*zi);
if (localZMag < closestZMag) closestZMag = localZMag;
if (zrr+zii > 16) break;
n++;
}
if (n == maxIterations) {
interiorDist[i+j*width] = closestZMag;
interiorLoc[interiorCount] = i+j*width;
interiorCount++;
if (closestZMag > biggestZMag) biggestZMag = closestZMag;
}
else pixels[i+j*width] = 0xffffff;
y += dy;
}
x += dx;
}
for (int i = 0; i < interiorCount; i++) {
int interiorColor = int(sqrt(interiorDist[interiorLoc[i]])/sqrt(biggestZMag)*255);
pixels[interiorLoc[i]] = interiorColor+(interiorColor<<8)+(interiorColor<<16);
}
updatePixels();
println("Time: "+millis());
noLoop();
}
void mousePressed() {
wh /= 2;
float xmax = xmin+wh;
float ymax = ymin+wh;
float dx = (xmax-xmin)/width;
float dy = (ymax-ymin)/height;
xmin += mouseX*dx;
ymin += mouseY*dy;
loop();
} |
|
|
|
|
Logged
|
|
|
|
|
|
|
David Makin
|
|
« Reply #14 on: March 30, 2012, 10:38:35 PM » |
|
For anyone reading this thread and encountering similar issues with respect to |z|, abs(z) and cabs(z) - a lot of fractal software (and languages they use for fractal coding) conform to the syntax of the mother/father of fractal software Fractint so if you want to be fairly sure you've got it correct then (in general) check the online docs for Fractint, but for this particular case in most fractal software for complex numbers if z = x+ i*y where x and y are real then:
abs(z) = abs(x) + i*abs(y)
|z| = sqr(x) + sqr(y) or x^2+y^2 if you prefer
cabs(z) = sqrt(sqr(x)+sqr(y)) or sqrt(x^2+y^2) or indeed sqrt(|z|)
i.e. abs(z) yields a complex result whereas |z| and cabs(z) yield reals.
The reason that |z| differs from the formal mathematical definition (i.e. the same as cabs(z)) is because it's so often possible to avoid the square root calculation such as when testing for bailout - also it should be noted that after |z| is calculated it can be worth retaining the value because often the actual magnitude (i.e. cabs(z)) is required (conditionally) afterwards and this can of course then be obtained via the sqrt alone without having to re-calculate x^2+y^2.
|
|
|
|
« Last Edit: March 30, 2012, 10:40:10 PM by David Makin »
|
Logged
|
|
|
|
|
May 14, 2011, 08:44:47 AM
Dilber MC Theme by HarzeM