Das C bei der Mandelbrot-Menge

Neue Frage »

b00n07 Auf diesen Beitrag antworten »
Das C bei der Mandelbrot-Menge
Hi,
ich beschäftige mich gerade aus Interesse mit der Mandelbrot-Menge der Form Zn=Z[n-1]+C.
Da ist mir soweit auch alles klar eigentlich, ich bin mir nur nicht sicher ob ich das alles richtig verstanden habe

Klar ist das alle Zahlen, der Form Z=(a;b) die, wenn man sie in die Folge einsetzt, gleich bleiben oder gegen Null gehen in der Mandelbrot-Menge liegen und sollte man dies per Rechner machen schwarz gezeichnet werden in der Komplexen Ebende.

Nun gibt es da, aber auch immer diese Randwerte die andersfarbig gemalt werden, ich bin mir nun nicht sicher ob ich da noch richtig liege, die Farbe ist abhängig davon wie oft die Rekursion durchlaufen wurde um die eingezeichnete Zahl zu errechnen ? (gehe von einer Software aus die, die Mandelbrot-Menge zeichnet [z.B. XAOS])

Und meine weitere eigentlich wichtigste Frage:
Das C kann beliebig gewählt werden muss dann aber für eine Mandelbrot-Menge gleich sein ?
Und was ist C bei der einfachen Mandelbrot-Menge (also der Form Zn=Z[n+1]+C?
Meine Vermutung ist ja das C dann immer gleich Z[0] ist, oder täusche ich mich da ?

Würde mich über ein paar Antworten oder Bestätigungen meiner Vermutungen/Überlegungen freuen.
Elvis Auf diesen Beitrag antworten »

Deine Folge ist falsch, das wird keine Mandelbrotmenge sondern eine ganz und gar langweilige Menge. , und du marschierst auf einer simplen Halbgerade dorthin.

Damit die Sache lustig wird, hat Mandelbrot nicht nur die Addition sondern auch die Multiplikation bemüht. , und die Mandelbrotmenge ist die Menge aller , für die diese Folge beschränkt bleibt.

Die Farbe zeigt an, nach wievielen Rekursionen man berechnet hat, dass die Folge nicht beschränkt bleibt.
b00n07 Auf diesen Beitrag antworten »

gut beschränkt heißt die Zahl überschreitet nie eine Gewisse Grenze, sondern bleibt gleich oder wird kleiner oder ? nur woher weiß ich die grenze ?

und Z0 = 0, Zn heißt das der Real teil der komplexen Zahl bleibt immer 0 ?
Elvis Auf diesen Beitrag antworten »

Eine Menge komplexer Zahlen heißt beschränkt, wenn sie betragsmäßig beschränkt ist, wenn sie also in einem Kreis um den Nullpunkt liegt.

(Soviel ich weiß, gilt folgendes : ) Wenn ein der Folge einen Betrag größer als 2 hat, divergiert die Folge. Das kleinste n mit definiert somit den Farbwert.

c ist eine komplexe Zahl in der Folge . Schon ist eine beliebige komplexe Zahl, also im allgemeinen weder reell noch rein imaginär.
b00n07 Auf diesen Beitrag antworten »

und wieso liegt die Grenze für den Abstand zum Nullpunkt gerade bei 2 und nicht bei 4 oder sonst einem Wert ?

und bei der Folge Zn = Z[n-1] + C ist C immer Z0 ? Und wenn ich den Farbwert von C bestimmen will, heißt das also , dass wenn der Betrag nach einer bestimmten Anzahlt von iterationen größer 2 ist, bekommt es eine farbe, die ich zugeteilt habe, und wenn der Betrag konvergiert, oder gleich bleibt liegt C in der Mandelbrot-menge und iwrd schwarz gemalt.
b00n07 Auf diesen Beitrag antworten »

vergesst den Beitrag zuvor ich weiß warum ich immer falsch lag, habe einen Fehler beim quadrieren der komplexen Zahlen gemacht.

Habe jetzt ein Programm geschrieben das das ganze berechnet und zeichnet, mein Problem ist ich gehe genau vor wie oben beschrieben von euch, aber das Bild hier kommt dabei raus ?!
Die Farbabstufung ist
blau = 1 Iteration
grün = weniger als 10 mehr als 1
rot = weniger als 20 mehr als 10
weiß =mehr als 20 Iterationen
Mandelbrot also schwarz = über 180 Iterationen ohne das der Betrag die 2 überschritten hat

naja hier das was bei rauskommt, wo liegt jetzt noch mein Fehler, der Algorithmuss arbeitet 100% korrekt genau wie es mir hier erklärt wurde....
*Bild im Anhang
 
 
Elvis Auf diesen Beitrag antworten »

Als Versuch ist das ja ganz nett, aber bestimmt falsch. Alles außerhalb |c|>2 kannst du doch sofort ausschließen wegen z_1=c . Daher entspricht dein Bild nicht 100% der Erklärung, höchstens 100% dem was du von der Erklärung verstanden hast. Augenzwinkern
b00n07 Auf diesen Beitrag antworten »

ja klar ich weiß das es flasch ist, meine frage ist doch auch wo der fehler liegen könnte das ich nich das richtige Bild bekomme.
Zur meinem Vorgehen:
1. wenn der Betrag |Zn| nach 180 Durchläufen der Folge noch nicht größer 2 ist, gehört C=Z0 zur Mandelbrot-Menge.
2. Den Betrag |Zn| berechne ich so |Zn| = sqrt(Rel² + Im²) (*sqrt = Wurzel)
3. Je nachdem wie oft die Folge durchlaufen ist bis |Zn| größer 2 war wird der entsprechende Pixel des Startwerts C mit einer anderen Farbe eingefäbrt.

Hier noch Kurz der Entscheidende Alogrithmus wie ich ihn in mienem Programm verwende als Pseudocode:

code:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
while(n <= 180)
{
        z[n] = (z[n-1]^2) + c;

        if(abs(z[n]) > 2)
        {
            break;
        }
        ++n;
}

(*abs() = Betrag von...)
Elvis Auf diesen Beitrag antworten »

Wenn der "entscheidende" Teil in einem Code richtig ist, und das Programm macht etwas falsch, so ist der Teil falsch, den man für "nicht entscheidend" hält.
In der Initialisierung der Variablen kann man beliebig viele Fehler machen. Murphy lässt grüssen. Augenzwinkern
b00n07 Auf diesen Beitrag antworten »

nein definitiv, dort ist kein fehler habe jede stelle überprüft, ist vlt doch im Code ein Fehler vlt kann den Ausschnitt mal jemand beurteilen ob er richtig erscheint ....
Elvis Auf diesen Beitrag antworten »

Das habe ich doch schon längst gemacht und dir mitgeteilt dass und warum dein Ergebnis falsch ist. Glaubst du ernsthaft, man könnte falsche Ergebnisse durch weitere Diskussion verbessern ?
Airblader Auf diesen Beitrag antworten »

Kann dein Programm wirklich so einfach mit komplexen Zahlen arbeiten, bzw. die zugrundeliegende Programmiersprache?

Woher du dir die Sicherheit nimmst, beurteilen zu können, alles andere sei fehlerfrei, obwohl du hier den (eventuellen) Fehler ja auch nicht erkennst, würde ich auch mal gerne wissen. Big Laugh

Auf wikipedia findest du ein Beispiel, wie man das programmiertechnisch implementieren kann.

air
b00n07 Auf diesen Beitrag antworten »

habe eine Klasse definiert die mit komplexen Zahlen umgehen kann also alle Grundrechenarten. Mein Programm arbeitet theoretisch so wie der Algorithmus von Wikipedia, nur etwas besser da ich x und y koordinate nicht extern berechnen muss da meine Klasse beides in einem Schritt kann....
AD Auf diesen Beitrag antworten »

Dann sieht es danach aus, dass du eine oder mehrere der Rechenoperationen +-* dieser Klasse falsch implementiert hast. Ein beliebter Fehler wäre etwa



statt des richtigen .

Vielleicht nicht gerade der, aber irgendein grober Patzer dieser Art scheint dir unterlaufen zu sein.


EDIT: Wenn ich mir dein obiges Programmfragment so ansehe

Zitat:
Original von b00n07
z[n] = (z[n-1]^2) + c;

wie sieht denn z.B. dein Quellcode für die Überladung des hier verwendeten Operators ^ aus? verwirrt
b00n07 Auf diesen Beitrag antworten »

Das ist es ja, die überladung der Operatoren funktioniert wunderbar .... alles getestet da wird alles Korrekt berechnet. siehe zB das hier:
code:
1:
2:
3:
4:
5:
6:
7:
8:
9:
complex_n complex_n::operator^(double n)
{
    x = x*x - y*y ;
    y = 2*x*y;

    return *this;

}


Der einzige Fehler wäre das ich vlt falsch addiere aber das ist ja uach nichts besonderes das addieren ...

PS: falls jemand den ganzen Code sehen will, hier ist er gepostet: http://www.hackerboard.de/code-kitchen/4...html#post304512
AD Auf diesen Beitrag antworten »

Da haben wir doch schon den Fehler!!! Korrekt wäre

code:
1:
2:
3:
4:
5:
6:
7:
8:
9:
complex_n complex_n::operator^(double n)
{
    double xtmp = x*x - y*y ;
    y = 2*x*y;
    x = xtmp;

    return *this;

}

Denke mal genau drüber nach, bevor du dir an die Stirn haust! Finger1


P.S.: Dass diese Funktion nur das Quadrat und nicht eine beliebige Potenz berechnet, da sehen wir mal gnädig drüber weg - schließlich brauchen wir hier nur Quadrate. Augenzwinkern


EDIT: Die Betragsfunktion hast du ebenfalls völlig falsch implementiert. Richtig wäre hier

code:
1:
2:
3:
4:
double complex_n::abs(complex_n a)
{
    return sqrt(a.x*a.x+a.y*a.y);
}



EDIT2: Und der nächste Fehler

code:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
int complex_n::mandelbrot(complex_n c)
{
    int n = 1;
    complex_n z[180];
    z[0] = c;

    while(n <= 180)
    {
        z[n] = (z[n-1]^2) + c;

        //z[n].out(); cout<<" n: "<<n;

        if(abs(z[n]) > 4)
        {
            break;
        }
        ++n;
    }

    return n;
}

Maximal gehst du bei diesem Code bis zu Feldelement z[180]. Das gibt es aber gar nicht bei der Deklaration complex_n z[180]; , sondern nur die Elemente z[0],...,z[179]. Die Deklaration sollte also lauten

complex_n z[181];

Deine Einschätzung "einziger Fehler" hätte also falscher nicht sein können. Mehr Selbstkritik wäre angebracht!
b00n07 Auf diesen Beitrag antworten »

Der Fehler ist gefunden !

Wenn ihr euch oben die Methode zum quadrieren anschaut fällt euch vlt auf das der Y-Wert mit dem bereits neuberechneten X-Wert berechnet wird, nicht mit dem Ausgangswert ....

Danke für die Hilfe!
b00n07 Auf diesen Beitrag antworten »

ach ok, da kam mein Beitrag zu spät ^^ , in einem anderen Forum kam jetzt auch ne Antwort...

Also ich habe jetzt nur den Teil bei der Berechnung des Quadrats korrigiert mit der Flaschen berechnung des Y-Werts, jetzt funktioniert es....

Die anderen "Fehler" sind keine, glaub es mir^ ^ auf das 181 Element würde nie zurück gegriffen, und meine Betragsfunktion arbeitet nicht nach dem Prinzip |sqrt(Rel² + Im²)| < 2 sondern |Rel² - Im²| < 2² , stimmt demnach genauso ^^
und deine Art den Betrag zu berechnen hatte ich auch schon verwendet hatte aber nichts geändert ....

Aber Danke für die Hilfe ich glaube den dummen Fehler mit dem falschen X wert hätte ich im Leben nicht mehr gefunden ^^
AD Auf diesen Beitrag antworten »

Zitat:
Original von b00n07
Die anderen "Fehler" sind keine, glaub es mir

Grundsätzlich glaube ich gar nichts, sondern halte mich an die Fakten. Und die zeigen zwei Programmierfehler und eine mathematische Absonderlichkeit (s.u.).

Zitat:
Original von b00n07
auf das 181 Element würde nie zurück gegriffen

Das habe ich ja auch nie behauptet:

Es wird aber auf das 180.Element zurückgegriffen, und das gibt es bei dir nicht!!! Offenbar weißt du nicht richtig, was die Felddeklaration in C/C++ bedeutet, ich habe es doch oben erläutert. Mit deinem Code kommt es zu einer Speicherzugriffsverletzung. Vielleicht ist dein System so tolerant, diese Speicherzugriffsverletzung nicht zu ahnden, bei mir war es aber der Fall (ich hab den Code geprüft).

Zitat:
Original von b00n07
, und meine Betragsfunktion arbeitet nicht nach dem Prinzip |sqrt(Rel² + Im²)| < 2 sondern |Rel² - Im²| < 2²

Das zu deinem Abbruchkriterium gehörende Gebiet:



Dann ist es irgendeine Bewertungsfunktion, aber definitiiv NICHT der Betrag einer komplexen Zahl. Deine Funktion als "Betrag" zu bezeichnen, ist irgendwie eine Irreführung.

Du solltest nicht so flapsig über berechtigte Kritik hinweggehen, sondern ernsthaft drüber nachdenken.
b00n07 Auf diesen Beitrag antworten »

nun gut, also wenn ich das richtig verstanden habe, wir der Betrag einer komplexen Zahl über den Satz des Pytagoras ausgerechnet a² + b² = c² hierbei ist a der Reelle Teil und b der imaginäre Teil, oder ? Demnach müsste doch meine Berechnung des Betrages genauso stimmen wie das mit der Wurzel ?
Außerdem habe ich meine Schreibweise auch auf diversen Seiten gefunden ....

So, desweiteren bekomme ich persöhnlich von meinem Compiler keine Fehlermeldung wegen des 1800sten Elements, und auch wenn ich dieses Ausgeben lasse steht dort ein korrekter Wert.
Vlt mag es daran liegen das ich unter Linux arbeite und das Toleranter ist.

Und ich nehme Kritik sehr wohl an sonst hätte ich hier meine Problem nicht gepostet, ich glaube nur das meine Betragsfunktion nicht so falsch sein kann weil, und weil sie auch häufig auf diversen Seiten zu finden ist. Wenn du mir das erklären kannst nehme ich den Fehler auch an....

PS: über das mit dem lezten Element eines Arrays weiß ich eigentlichshcon bescheid, nur ich hatte damit niemals ein Problem und schreibe miene Programme immer schon so das in das letze Element genauso geschrieben wird, vlt mag es am Compiler/Betriebssystem liegen....
kiste Auf diesen Beitrag antworten »

In b steht aber keine imaginäre Einheit mehr. Das ist ja gerade der Basisvektor bei Identifizierung als -Vektorraum.

Daraus ergibt sich . Das Minus ist also falsch!

Und das dein Programm funktioniert liegt höchstwahrscheinlich nur daran dass im Compiler die Fehlerüberprüfung ausgeschalten ist und der Speicher in der Halde zufällig frei ist!
AD Auf diesen Beitrag antworten »

Zitat:
Original von b00n07
und schreibe miene Programme immer schon so das in das letze Element genauso geschrieben wird, vlt mag es am Compiler/Betriebssystem liegen....

Aha, also du und deinesgleichen sind das, denen wir Anwender immer diese Sicherheitslücken wegen "Buffer overrun" verdanken, nur weil sie nie richtig C/C++ gelernt haben. Augenzwinkern

Mal im Ernst: Das ist unseriös, diesen Fehler drin zu lassen, nur weil dein Linux das zufällig toleriert, weil der Platz für das eine Element gerade mal nicht anders vergeben ist (vielleicht wegen aligning o.ä.). Mit diesem Programmierstil wirst du mal kräftig baden gehen. Und der Compiler meldet das nicht, weil es kein Syntaxfehler ist und der Compiler den möglichen Laufzeitfehler zur Kompilierzeit nicht erkannt hat (gute Compiler können hier aber durchaus ein Warning geben).

Und was den Betrag betrifft: Da solltest du dich nochmal auf den Hosenboden setzen und in Erfahrung bringen, was der Betrag einer komplexen Zahl ist (siehe Anmerkung von Kiste). Dass dich nicht mal der Graph oben überzeugt hat, also wirklich... Finger1
Fünkchen Auf diesen Beitrag antworten »

Ach ist das amüsant. Ich steig mit zwei ein. Wer bietet mehr?
Bitte die Programme kräftig kritisieren!

code:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
DEF FNnorm (x, y, n)
 j = 1
 xa = x: ya = y
 DO WHILE j <= n
  xb = x
  IF ABS(x) < 20 AND ABS(y) < 20 THEN T = 1 ELSE T = 0
  IF T = 1 THEN x = x ^ 2 - y ^ 2 + xa
  IF T = 1 THEN y = 2 * xb * y + ya
  j = j + 1
 LOOP
 FNnorm = (x ^ 2 + y ^ 2) ^ .5
END DEF


CLS : SCREEN 12: REM with 640x480 Pixel
 v = 4: K = 1

 DO WHILE K <= 200000
  x = RND * 4 - 2
  y = RND * 4 - 2
  R = FNnorm(x, y, 12)
  IF R < 2 THEN PSET (v * x * 35 + 320, v * -y * 40 + 240), 1
  K = K + 1
 LOOP

 PSET (v * 1 * 35 + 320, -v * 0 * 40 + 240 + 4)
 FOR L = 5 TO 635 STEP 35
  PSET (L, 240)
 NEXT L
 FOR L = 40 TO 440 STEP 40
  PSET (320, L)
 NEXT L
 COLOR 0: INPUT " ", wait$
END



#Datei apple.py
import math
import Image, ImageDraw 

black = (0,0,0)
size = (1000,1000)
im = Image.new("RGB", size, (255,255,255))
draw = ImageDraw.Draw(im)

def isapp(cx, cy):
  i=0; x = 0.0; y = 0.0
  while i<15:
    if x>2 or x<-2: break
    if y>2 or y<-2: break
    xt = x**2 - y**2 + cx
    yt = 2*x*y + cy
    x = xt
    y = yt
    i+=1
  if math.sqrt(x**2+y**2)<2: return True
  else: return False

tx=-2; ty=-2
while tx<=2:
  ty=-2
  while ty<=2:
    if isapp(tx,ty):
      sx = 200*tx+600
      sy = -200*ty+500
      draw.rectangle([sx,sy,sx+1,sy+1], fill=black)
    ty+=0.01
  tx+=0.01

del draw
im.save("apple.png","PNG")
AD Auf diesen Beitrag antworten »

Also wenn das hier ein Mandelbrotfraktal-Programmierwettbewerb werden soll, dann erwarte ich im Zeitalter der Vierkernprozessoren (und bald 8, 16, ... Kerne) eigentlich eine Multithread-Variante, die diese Kerne auch richtig zu nutzen weiß. Big Laugh

Noch besser natürlich, eine Multithread-Variante, die die zig bzw. sogar Hunderte Rechenkerne auf modernen ATI/NVidia-Grafikkarten kräftig zum Heizen bringen kann.

Zu dumm, dass es solche Programme bereits gibt, das ist etwas demotivierend für eigene Anstrengungen. smile
sulo Auf diesen Beitrag antworten »

Zitat:
Original von b00n07
...., in einem anderen Forum kam jetzt auch ne Antwort...



@b00n07
Du solltest wissen, dass ein solches Crossposting in keinem Board gerne gesehen wird, auch nicht bei Onlinemathe.
Üblicherweise reagieren wir mit Schließen des Threads.
Ich sehe davon ab, da deine Frage beantwortet wurde, bevor jemand dein Crossposting bemerkt hat.
Bitte vermeide es in Zukunft, deine Fragen gleichzeitig in mehreren Boards zu stellen.

LG sulo
AD Auf diesen Beitrag antworten »

Dazu kann ich noch anmerken, dass es ziemlich stillos ist, erst im anderen Forum in frecher Form

Zitat:
http://www.hackerboard.de/code-kitchen/40794-mandelbrot-menge-zeichnen-prog.html#post304512
verdammt leute, 180 views und keine Antworten ?! Faulheit oder ist mein Code nicht lesbar... ?

zu drängeln, dann aber die Leute lange nicht zu informieren, dass im Crossposting-Forum bereits eine Lösung eingegangen ist. Das mindeste ist, alle beteiligten Foren bei Lösungseingang zu informieren - und zwar zügig, wenn man schon so ein Drängler ist!!!

@sulo

Ich hatte gestern das Crossposting sehr wohl bemerkt. Die Antwort dort kam später als hier, ansonsten hätte ich gar nicht gepostet. Schlecht ist, dass b00n07 nicht in der anderen Richtung querverlinkt hat.
b00n07 Auf diesen Beitrag antworten »

nun ja ich entschuldige mich bei allen !
Aber es hat mich sehr irritiert dort keine Hilfe zu bekommen ^ ^

Ach und das mit dem Betrag habe ich eingesehen, ihr habt wohl Recht , wer hätte es gedacht ^ ^ . Die Sache mit dem 180 Element habe ich bereits erledigt, ich werds mir wohl angewöhnen das ordentlich zu schreiben, aber es fällt mir schwer weil ich auch nur gelegntlich programmiere ^ ^ .

Zu den mehrfach posts, es ist so, hier wollte ich mich informieren ob ich eventuel mathematische Fehler gemacht habe, im anderen Forum um Fehler im Programm zu finden. Das die Programmierung dann hier uach so reingekommen ist war ja nicht geplant, also entschuldige ich mich mal auch noch dafür ^ ^ .

Aber wenn man jetzt schon einmal dabei ist, was meint ihr wie kann man den zeichen-prozess noch schneller gestalten, ähnlich simpel wie mit Allegro, nur schneller ?

PS vlt sollte man diesen Thread nun auch verschieben, kommt ja auch vom Thema ab.

PPS: und ja ich sollte wenn ich um Hilfe frage nicht jede Kritik zurückweisen, aber es waren immer so kurz gefasste Antworten zum Teil wo ich nicht auf Ahnhieb gesehen hab was der jeweilige Poster gemeint hatte ..... also sorry zum 3ten
AD Auf diesen Beitrag antworten »

Keine Ahnung, wie deine Allegro-Bibliothek konzipiert ist, aber i.a. ist es schneller, das Bild in einer Speicherbitmap vorzubereiten und dann erst in einem Rutsch zum Bildschirm zu transferieren - ich hoffe mal, Allegro bietet sowas.

P.S.: Was Performance betrifft, ist bei deinem Programm übrigens noch einiges rauszuholen. Ich hab vor zwei Jahren ein altes Mandelbrotprogramm von mir mal multithreadingtauglich gemacht, und komme jetzt auf ca. 1.2 Milliarden Mandelbrot-Iterationen pro Sekunde (ohne Bildschirmausgabe) auf einem Intel Q9550 (2833MHz) bei voller Nutzung aller 4 Kerne und übersetzt mit dem Intel-C-Compiler 11.0, der die Vektor-SSE-Recheneinheiten gut zu nutzen weiß. Aber alles noch reines C/C++, kein Assembler. Augenzwinkern

Zitat:
Original von b00n07
aber es waren immer so kurz gefasste Antworten zum Teil

Ich komme kurz, aber klar und deutlich auf den Punkt. Der Vorteil der Schriftform ist ja, dass man es sich immer wieder nochmal durchlesen kann, wenn man es beim ersten Durchlesen nicht verstanden hat. Nichts gegen Redundanz, aber man muss es ja nicht übertreiben - außerdem setze ich ein gewisses Mitdenken voraus, gerade hier im Hochschulforum. Augenzwinkern
Airblader Auf diesen Beitrag antworten »

@ Arthur

Nicht nur Mitdenken, sondern v.a. auch etwaiges eigenständiges Recherchieren, was damit genauer gemeint sein könnte ist eigentlich wünschenswert. Augenzwinkern

Zum Thema "schneller machen":
Arthur hat den ersten, "kanonischen", Trick dafür genannt. Ist das nocht nicht geschehen - mache es, es spart sehr viel Zeit.
Ein paar weitere Tricks findest du in der wikipedia im Artikel "Mandelbrotmenge", dort sind Performance-Techniken für Programme, die bishin in wirklich anspruchsvolle Methodiken reichen.

air
b00n07 Auf diesen Beitrag antworten »

Alles klar dann werde ichdas wenn man Zeit ist versuchen ^ ^

Danke für die Hilfe!
Neue Frage »
Antworten »



Verwandte Themen

Die Beliebtesten »
Die Größten »
Die Neuesten »