Buddhabrot

[Eichhoernchen]

Es ist noch kein fertiges Programm was ich euch hier Präsentieren möchte, es sind eher Codeschnipsel mit nem schnell gebastelten Programm zusammen!

Und zwar geht es um die Buddhabrotmenge...(nicht Butterbrot)

Es ist ein Fraktal(denke ich zumidest, ist ja schwer zu definieren)

Hier estmal ein paar Bilder wie das aussieht:
BILD1 (Gefärbt)
Bild2
Bild3
Bild4
Missglückter färbeversuch

Den Namen hat es wegen seiner Buddha ähnlichen Form.
Also ich finde das recht cool.

So erstmal zum Buddhabrot, es hat was mit der Mandelbrotmenge zu tun, wie man glaub ich sehen kann.

Und zwar ist die Buddhabrotmenge sowas wie eine Karte der Punkte C der Mandelbrotmenge die Divergieren(d.h. nicht zur Menge gehören).
Als erstes sucht man sich ein zufälliges C, danach lässt man dieses C den Mandelbrotmengen Algorithmus durchlaufen, wenn das C nach N Iterationen noch zur Menge gehört, wird ein neues C gesucht und von vorne gestartet, wenn das C aber nicht dazu gehört, wird die Iteration wiederholt, und alle Atraktoren, die Punkte die z anspring( z = z² + c) werden markiert, bzw. das array an dieser Stelle wird um 1 erhöht.

Leider entstehen erst brauchbare Bilder wenn man dies sehr oft tut. Bei ca 5 Millionen Iterationen des Hauptalgorithmus, also nicht von der Mandelbrotmenge entsteht ein brauchbares schwarz/weiß Bild. Wenn man jetzt noch gern ein farbiges Bild hätte benötigt man gleich 3 Arrays (r, g, b). Für farbige Bilder sind Fluchtiterationen(die Iterationen der Mandelbrotmenge) deutlich höher zu setzen als für schwarz/weiß Bilder. Bsp.: 10000 Fluchtiteratioen, wenn der Punkt C unter 100 Iterationen divergiert gehört er zum Rot teil der Menge und das Rot array wird erhöht. Wenn C unter 1000 und über 100 Iterationen divergiert gehört C zum Gelb teil und das Gelb array wird erhöht. Und das Blaue bei 10000 und > 1000.
Anschließend wird nur noch duch ein einfaches verfahren die arrays als r, g, b Teil eines Bildes dargestellt.

Für grobe Bilder wie Bild3 oder Bild2 kann man mit einer Rechenzeit von ca 10-20 Minuten rechnen(AMD 3000+) mit Bildern wie Bild 1 muss man schon mit 1,5 Stunden Rechenzeit rechnen. Und das Bild was ich zur Zeit berechne ist schon seit 3 Stunden am Rendern (und noch nichtmal uir hälfte fertig).

Naja ihr könnt euch ja mal den Code anschauen, ich habe noch andere Färbeversuche jetzt im Programm, diese sollten aber kein Problem sein wegzudenken!

[Eichhoernchen]

hmmm ich hab das mal so getestet mit den units von dizzy und selbst geschriebenes Zeugs.

Ich muss sagen dissys Zeug ist in der Handhabung echt klasse, jedoch ist es langsamer musste ich feststellen.
Was sich bei meiner Berechnung in 1ner Sekunde ausschlägt, so wie ich es geschrieben hab dauerte die Rechnung ca 5 sekunden und mit dizzys Befehlen brauchte sie ca 6 sekunden.
Ich habe anstatt z.B.:

sqrC(c) das hier geschrieben:

Delphi-Quellcode:

c.x := c.x * c.x - c.y * c.y;
c.y := 2 * c.x * c.y;

und es ist schneller, woran liegt das, ich meine dizzys Zeug ist doch fast alles in asm geschrieben.
Außerdem ist auch das normale quadieren mit sqr langsamer als x * x zu rechnen. Kann mir das einer erklären, oder liegt es einfach daran das ich ne funktion aufrufe und das die Zeit nimmt?

[Khabarakh]

Zitat:

Delphi-Quellcode:

c.x := c.x * c.x - c.y * c.y;
c.y := 2 * c.x * c.y;

So wird das aber nichts :

Delphi-Quellcode:

TempX := z.x;
z.x := z.x * z.x - z.y * z.y;
z.y := 2 * TempX * z.y;

Ich habe mir mal eine Testanwendung geschrieben, im Schnitt kamen überall etwa die gleichen Zeiten heraus (CSqr eher langsamer).

Delphi-Quellcode:

function sqrC(const C: TComplex): TComplex;
const two: double = 2.0;
asm
  fld  C.x;
  fmul C.x;
  fld  C.y;
  fmul C.y;
  fsubp;
  fstp result.x;

  fld  C.x;
  fmul C.y;
  fmul two;
  fstp result.y;
end;

function CSqr(const C: TComplex): TComplex; inline;
begin
  Result.x := Sqr(C.x) - Sqr(C.y);
  Result.y := 2 * C.x * C.y;
end;

procedure CSqr2(var C: TComplex); inline;
var
  TempX: Single;
begin
  TempX := C.x;
  C.x := C.x * C.x - C.y * C.y;
  C.y := 2 * TempX * C.y;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Start: Cardinal;
  i, ii: Integer;
  TempX: Single;
  z: TComplex;
begin
  Start := GetTickCount;
  for ii := 0 to 1000000 do
  begin
    z.x := Sqrt(0.5);
    z.y := Sqrt(0.5);
    for i := 0 to 50 do
      z := sqrC(z);
  end;
  ShowMessage(Format('%d', [GetTickCount - Start]));

  Start := GetTickCount;
  for ii := 0 to 1000000 do
  begin
    z.x := Sqrt(0.5);
    z.y := Sqrt(0.5);
    for i := 0 to 50 do
      z := CSqr(z);
  end;
  ShowMessage(Format('%d', [GetTickCount - Start]));

  Start := GetTickCount;
  for ii := 0 to 1000000 do
  begin
    z.x := Sqrt(0.5);
    z.y := Sqrt(0.5);
    for i := 0 to 50 do
    begin
      TempX := z.x;
      z.x := z.x * z.x - z.y * z.y;
      z.y := 2 * TempX * z.y;
    end;
  end;
  ShowMessage(Format('%d', [GetTickCount - Start]));

  Start := GetTickCount;
  for ii := 0 to 1000000 do
  begin
    z.x := Sqrt(0.5);
    z.y := Sqrt(0.5);
    for i := 0 to 50 do
      CSqr2(z);
  end;
  ShowMessage(Format('%d', [GetTickCount - Start]));

end;

[dizzy]

Zitat von Eichhoernchen:

Kann mir das einer erklären, oder liegt es einfach daran das ich ne funktion aufrufe und das die Zeit nimmt?

Genau daran wird es wohl liegen. Deinen Code schreibst du direkt in die Schleife, wärend du im anderen Fall einen Funktionsaufruf hast, der leider etwas Overhead erzeugt. Der Gewinn ist bei der Lesbarkeit und Wiederverwendbarkeit. Ich bemängel jedoch schon länger, dass Delphi im Gegensatz zu C kein Inlining unterstützt womit beide Fliegen mit einer Klappe geschlagen wären. (Jaja, D2005 kann das, aber das hab ich nicht und will es nicht .)

In Khabarakhs Messung kommen beide Varianten auf fast gleiche Ergebnisse, weil auch beides in Funktionen ausgelagert ist. Zudem ist mein asm-code nicht so viel anders als der den Delphi aus deinem generiert. Mir fielen da nur gelegentlich kleine Dinge auf die nicht 100%ig optimal waren, und deshalb hatte ich gleich alles was ich konnte in asm gebaut. Da weiss man wenigstens was man hat ^^

\\edit: Khabarakh, du hast die asm-funktion nicht ge-inlined

[Khabarakh]

Zitat von dizzy:

\\edit: Khabarakh, du hast die asm-funktion nicht ge-inlined

Inlining wird für Assembler-Routinen nicht unterstützt . Ich mache heute noch einen größeren Test, dann werde ich sie auch per Hand inlinen.

Hab gerade die neueste Version meines MathBitmaps hochgeladen, zusammen mit der Unit im Anhang (und natürlich der GR32-Lib) sollte sich mein Programm nun kompilieren lassen.

[Eichhoernchen]

Zitat von Khabarakh:

Zitat:

Delphi-Quellcode:

c.x := c.x * c.x - c.y * c.y;
c.y := 2 * c.x * c.y;

So wird das aber nichts :

Delphi-Quellcode:

TempX := z.x;
z.x := z.x * z.x - z.y * z.y;
z.y := 2 * TempX * z.y;

Jaja, aber man wusste was ich meinte^^

Habe mir jetzt ma gr32 und Konsorten besorgt und ich muss sagen: Nicht schlächt...



Hmm es müsste mal ne Delphi version im Stil von D 5,6,7 rauskommen die aber solche "mängel" beseitigt.
Ich hab mir die D2005 Demo gerade von der Borland Website geladen und ich muss sagen: Wer da beim Start nicht einschlaft....
Und die Oberfläche ist kacke, nicht mehr so schön freischwebend, kann man zwar umstellen, ist aber nicht genauso.
Fazit: Neues Delphi 7 mit verbessertem Compiler^^ (da kann ich lange drauf warte)