---

nun, rein aus experimentierfreude, will ich eine Lisp-Funktion programmieren, die mir das bekannte Apfelmännchen zeichnet, dazu habe ich im netz eine LISP-Programm gefunden (siehe hier: http://xarch.tu-graz.ac.at/autocad/lisp/FAQ-link/msg00412.html) im Prinzip hab ich das Programm auch shcon verstanden und kann es sicherlich umsetzen in AutoLISP, damit AutoCad das zeichnen kann, nur bevor ich anfange wollte ich wissen ob AutoCad überhaupt die Kernberechnung nachvollziehen kann:

Zitat:

---

    (declare (long-float delta-x-cell delta-y-cell x y)
    (type (complex long-float) z))

---

???

und desweiteren wollte ich Fragen ob jemand ein Tipp hat, da ich zuerst vorhatte das ganze als einzelne 3D-Punkte auszugeben (also statt wie gewöhnlich mit Farben, mit einer Höhe), jedoch sich daraus kein 3D-Modell exportieren lässt, der weitere Gedanke war, das vielleicht als gigantisches Poly-Netz auszugeben, ist das möglich, oder überfordert das die meisten Rechner?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Imion:
nun, rein aus experimentierfreude, will ich eine Lisp-Funktion programmieren, die mir das bekannte Apfelmännchen zeichnet, dazu habe ich im netz eine LISP-Programm gefunden (siehe hier: http://xarch.tu-graz.ac.at/autocad/lisp/FAQ-link/msg00412.html)  im Prinzip hab ich das Programm auch shcon verstanden und kann es sicherlich umsetzen in AutoLISP, damit AutoCad das zeichnen kann, nur bevor ich anfange wollte ich wissen ob AutoCad überhaupt die Kernberechnung nachvollziehen kann:

???

und desweiteren wollte ich Fragen ob jemand ein Tipp hat, da ich zuerst vorhatte das ganze als einzelne 3D-Punkte auszugeben (also statt wie gewöhnlich mit Farben, mit einer Höhe), jedoch sich daraus kein 3D-Modell exportieren lässt, der weitere Gedanke war, das vielleicht als gigantisches Poly-Netz auszugeben, ist das möglich, oder überfordert das die meisten Rechner?

---

Welche "Kernberechnung"? In AutoLISP kannst Du natürlich ganz hervorragend mit imaginären Zahlen rechnen - i ist ja nichts anderes als die Einheit 1 auf der Y-Achse. Die Funktionen dazu mußt Du Dir natürlich selber basteln.

Ob Du Ergebnis sinnvoll als Polymesh ausgeben kannst, hängt v.a. davon ab, wieviele Knotenpunkte Du errechnen lassen willst. Ich denke mal, dass alles, was halbwegs detailliert aussieht, den Rahmen des Möglichen sprengt. Statt Punkte kannst Du vielleicht farbige SOLIDs anzeigen (keine Volumenkörper!).

Ganz allgemein: das ist eine nette Fingerübung, wenn Du LISP lernen willst. Wenn Du Apfelmännchen sehen und erforschen willst, solltest Du sowas aber in C programmieren - LISP ist da nicht performant genug.

Gruß
Tom Berger

------------------
Architekturwerkzeuge für AutoCAD: http://www.archtools.de

---

naja ich find die formen die man damit generieren kann einfahc interessant und würde gernr quasi in details reinzoomen udn die dann als 3d-modell rendern, damit lassen sich z.B. genial küsten generieren oder irgendetwas anderes wo man zufallswerte braucht, die aber irgendwie rhythmishc sein sollen, wnen ich aber ehrlich bin, hab ich noch ncith ganz verstanden, wie man die mandelbrotmenge errechnet ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Imion,

ich sehe da irgendwie einen Widerspruch: Mandelbrot vs. Zufallszahlen. Geht es wirklich um Algorithmen, die Selbstähnlichkeit erzeugen, oder geht's dir um Küstenverläufe usw. - die mögen zwar komplex sein, aber sie weisen keine strenge Selbstähnlichkeit auf. Da würde ich mich dann eher damit befassen, wie man in AutoLisp Zufallszahlen erzeugen kann (leider immer noch nicht eingebaut, aber es gibt Anleitungen zu Hauf). Wenn dir so etwas Spaß macht: Random-Generator schreiben, und als nächstes dann einen, der (Gauss-/?-)normalverteilte Zahlen produziert. Damit kriegt man schon recht nette Küstenverläufe hin (und am Strand wachsen dann auch schon gaussverteilte Schachtelhalmgewächse). Ganz nett kriegt man so etwas hin, wenn man den Würfelmechanismus einschlägiger Rollenspiele benutzt: 2 Würfel à 6 Seiten (wie in der Kneipe beim Lügenpasch) liefern etwas abgehackte Werte (im Fachjargon: 'diskrete'), aber 3 x 16 Würfel à 16 Seiten können schon ein recht farbiges Bild dieser Welt erzeugen.

Mein wichtigster Tipp: Rekursive Programmierung - damit steht und fällt (erstmal) alles. Später gibt's auch nichtrekursive Verfahren, aber die sind schwieriger;-)))

Ich stimme übrigens Tom zu, in allem, was er gesagt hat: Appelmännekens als Vektorgrafik sind der echte Prozessorkiller;-)

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

oh da hab ich aber was anderes gehört, da haben wissenschaftler "herausgefunden" dass sich die unendlichkeit des zufalls immerwieder wiederholt (halt unendlich lang).

naja und das mandelbrot ist sone sache, je mehr ich reinzoome, desto mehr komme ich dieser unendlichkeit näher, denn egal wie nah man reinzoomt findet man immer wieder neue kleinere apfelmännchen, es ist schon ne lustige sache ...

aber der zufallsgenerator ist mir zu chaotisch, ich möchte einen unendlichkeitsgenerator, den man einfahc nur einschrenkt quasi programmieren... naja mal sehen ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Imion,

Du bist lustig 

Auch auf die Gefahr hin dass ich jetzt was nicht ganz raffe

> dass sich die unendlichkeit des zufalls immerwieder wiederholt
> (halt unendlich lang).

Sicher, Du könntest ja auch unendlich lang in 'ner Kneipe rumwürfeln.
Naja, beinahe 

Den sechs dingern auf den Würfeln ist das aber nun - denke mal - total egal.

Möglicherweise bin ich aber jetzt total im falschen Film und
... das bin ich i.e. meistens  , sorry

lg Nancy
--
Shit will make the flowers grow and that's beautiful.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich LISPel nicht ein Stückchen und meine Mathekenntnisse kratzen auch nur die Chaoskante an aber ich kann nur ehrfürchtig staunen: eingeschränkte Unendlichkeit und zu chaotische Zufallsgeneratoren finde ich genial.

IMHO stehen die weit über dem weißen Rappen und dem schwarzen Schimmel. However, ich klinke mich hier mangels Wissens lieber wieder aus...

------------------
ciao bene

"Bloody Stupid Johnson"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

ich denke bene hats ungefähr so ausedrückt, warum ich nicht in die kneipe geh und stundenlang rumwürfel, naja heut hab ich eh keine zeit, mal sehen was die woche so bringt (an zeit) ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von mapcar:

ich sehe da irgendwie einen Widerspruch: Mandelbrot vs. Zufallszahlen. Geht es wirklich um Algorithmen, die Selbstähnlichkeit erzeugen, oder geht's dir um Küstenverläufe usw. - die mögen zwar komplex sein, aber sie weisen keine strenge Selbstähnlichkeit auf.

---

Hallo Axel,

streng genommen weisen Küstenverläufe sehr wohl Selbstähnlichkeit auf, wenn Du immer näher hinein zoomst. Allerdings hat diese Selbstähnlichkeit ihre Grenzen an der endlichen Beschaffenheit der Materie.

Zitat:

---

Da würde ich mich dann eher damit befassen, wie man in AutoLisp Zufallszahlen erzeugen kann (leider immer noch nicht eingebaut, aber es gibt Anleitungen zu Hauf). Wenn dir so etwas Spaß macht: Random-Generator schreiben, und als nächstes dann einen, der (Gauss-/?-)normalverteilte Zahlen produziert. Damit kriegt man schon recht nette Küstenverläufe hin (und am Strand wachsen dann auch schon gaussverteilte Schachtelhalmgewächse).

---

Das ist - im Gegensatz zur Mandelbrotmenge - ein sehr interessantes Gebiet für LISP Programmierung. Als Appetithappen und Grundlage empfehle ich das Buch "The Algorithmic Beauty of Plants" (http://www.amazon.de/exec/obidos/ASIN/3540972978/qid=1079344009/sr=2-1/ref=sr_aps_prod_1_1/028-1462154-6760503)

Nach dem Mitautor Aristid Lindenmayer sind die sogenannten L-Systeme benannt, die innerhalb der Fraktale eine eigene Klasse bilden. Mit diesen L-Systemen lassen sich auf verbüffend realistische Weise Pflanzen und deren Wachstum simulieren (siehe den Pflanzengenerator in AccuRender http://www.mcneel.com). Wenn man sich die Beschreibungssprache dieser L-Systeme ansieht, dann muß man unwillkürlich an LISP denken - man kann diese nämlich fast 1:1 nach LISP übersetzen.

Ich hab' diese L-Systeme immer als Einstieg für meinen LISP-Kurs an der Uni genommen, da diese wirklich extrem einfach in Form von Rekursion implementierbar sind, und weil man damit außerordentlich schnell sehr interessante und für die Weiterarbeit motivierende Ergebnisse erzielt, die man anders kaum kriegen kann.

Gruß
Tom Berger

------------------
Architekturwerkzeuge für AutoCAD: http://www.archtools.de

---

gut soweit hab ich nun endlich die mandelbrot-berechnung verstanden, bevor ich ans detail-optionen rangehe, muss erstmal die hauptfunktion funzen, soweit bin ich:

 

Zitat:

---

(defun Mandelbrot (/ Startpoint Endpoint num-x-cells num-y-cells iterations)
  (if (setq Startpoint (getPoint "\nStartpoint of Field (x and y values must have no negative values): "))
    (if (setq Endpoint (getPoint Startpoint "\nEndpoint of Field (must have higher x and y values as the Startpoint and no negative values): "))
      (if (setq num-x-cells (getdist "\nNumber of x-cells (integer-values recommened): "))
    (if (setq num-y-cells (getdist "\nNumber of y-cells (integer-values recommened): "))
        (if (setq iterations (getdist "\nIterations (integer-values recommened): "))
          (if (setq height (getdist "\nHeight of Values in Mandelbrot-Area (0 recommened): "))
            (if (setvar x (car Startpoint))
              (if (setvar y (cadr Startpoint))
                (if (setvar z (complex x y))
                  (if (setvar delta_x (/ (- (car Endpoint) (car Startpoint)) num-x-cells))
                    (if (setvar delta_y (/ (- (cadr Endpoint) (cadr Startpoint)) num-y-cells))
                      (if (entmake (list '(0 . "Polyline") '(66 . 1) '(70 . 64) (cons 71 num-x-cells) (cons 72 num-y-cells) '(75 . 8)))  ;;; end of setting up all values and the polynet entity 70 with value 64 defines polyline as polynet, entity 75 with value 8 defines polynet for bezier-faces
                        (while (< x (car Endpoint))
                          (while (< y (cadr Startpoint))
                            (setq i 0)
                            (setq z_final height)
                            (setq z (complex x y)
                            (while (< i iterations)      ;;; start of calculating the complex-height
                              (setvar z (+ (complex x y) (* z z))
                              (while (> (+ (* (realpart z) (realpart z)) (* (imagpart z) (imagpart z))) 4)
                                (setvar z_final z)
                              )
                            (setvar i (+ 1 i)
                            )
                          (entmake (list '(0 . "Vertex") (cons 10 (list x y z_final))))
                          (setvar y (+ delta_y y))
                          )
                        (setvar x (+ delta_x x))
                        )
                      )
                    )
                  )
                )
              )
            )
          )
        )
      )
    )
  )
  )
)

---

ich hab den quelltext nochnicht überprüft, aber schon jetzt fällt mir auf, dass der die berechnungen "complex" "imagpart" und "realpart" nicht kennt, wie es der normale lisp tut, in der 'kal-referenz fand ich auch nichts hilfreiches, kann mir da jemand weiterhelfen?

ich sehe grad das da n logischer fehler in der berechnung ist, aber daran jetzt wieter rumutüfteln bringt nichs, solange ich nciht weiss wie ich mit autolisp komplexe zahlen berechne...
(habe den quelltext nochma verbessert, aber so wie er da steht bringen die iterations quasi garnichts, d.h. die eine while schleife bringt garnichs und somit gibts für die zu berechnenden zahlen auch keine variable höhe ...)
[Diese Nachricht wurde von Imion am 26. Mrz. 2004 editiert.]

[Diese Nachricht wurde von Imion am 26. Mrz. 2004 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Na, das ist doch genau das, was dir Tom Berger shon in seiner ersten Antwort gesagt hat: Komplexe Zahlen als Liste von 2 Elementen speichern, dann ist realpart = car und imagpart = cadr. Die Zeiten, wo es noch ganz einfach ging (setq realpart car imagpart cdr) sind aber in AutoLisp leider vorbei.

Der Ausdruck (setvar z (+ (complex x y) (* z z))) wird aber so kaum laufen, er würde eine überladene Funktion + voraussetzen, die es in AutoLisp aber nicht (mehr) gibt. Den Konstruktor kannst du mit complex = list annehmen, aber am + wird es scheitern. Da musst du dir eine Funktion ComplexAdd schreiben (oder bei R. Urban besorgen) und anstelle des + verwenden.

Das ist jetzt das, war mir bei einem flüchtigen Blick aufgefallen ist. Kann sein, dass ich da noch schlimmeres übersehen habe;-)

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Komplexe Zahlen als Liste von 2 Elementen speichern, dann ist realpart = car und imagpart = cadr.

---

um sie aber in eine liste zu speichern muss ich sie doch erst berechnen und manuell eintippen spricht leider gegen meinen anwendungsbereich, da es wohl sehr viele werden udn ich dem anwender (bzw. mir) die möglichkeit geben will es ins unendliche fortzusetzen...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

In der Zeile  (if (setvar z (complex x y))... hast du doch so einen Fall:

(defun complex(real imag / )(list real imag))
(defun realpart(cmplx / )(car cmplx))
(defun imagpart(cmplx / )(cadr cmplx))

(setq myC(complex 3 2)) => (3 2)

(realpart myC) => 3
(imagpart myC) => 2

Bis dahin ist das doch allerbanalstes Lisp. Wie gesagt, soweit wird doch noch gar nix gerechnet. Erst bei +, aber das hier:

(+ '(3 2) 1.5734462)

funktioniert nun mal nicht so.

Und es kommt noch mehr:

(setq z (complex x y)
...
(setvar z (+ (complex x y) (* z z))

Hier das selbe Problem: Da soll z quadriert werden, aber z ist eine komplexe Zahl, heisst: Da stünde dann z.B. (* '(3 4)'(5 6))! Auch das haut so nicht hin - brauchst also noch ein ComplexMultiply.

Alles klar? Muss jetzt leider weg...

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

[Diese Nachricht wurde von mapcar am 29. Mrz. 2004 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

So, nun bin ich wieder da - die Java User Group rief;-)

Die Addition kannst du so implementieren (die zugrundeliegende Formel ist: z1 + z2 = (a + bi) + (c + di) = (a + c) + (b + d ) * i,

(defun ComplexAdd(z1 z2 / )
  (list
    (+(realpart z1)(realpart z2))
    (+(imagpart z1)(imagpart z2))
  )
)

Das war jetzt die Schreibweise zum Mitdenken, kürzer und effektiver ist allerdings diese Implementation:

(defun ComplexAdd(z1 z2 / )(mapcar'+ z1 z2))

Die Multiplikation sieht so aus:

z1 * z2 = (a + bi) * (c + di) = (ac - bd ) + (ad + bc) * i
(es gelten Kommutativ-, Assoziativ- und Distributivgesetz)

(defun ComplexMul(z1 z2 / )
  (list
    (-(*(car z1)(car z2))(*(cadr z1)(cadr z2)))
    (+(*(car z1)(cadr z2))(*(cadr z1)(car z2)))
  )
)

Auch das ließe sich noch straffen, aber nicht so sehr wie bei der Addition, deswegen lasse ich das mal so stehen.

Aber jetzt noch mal das Wesentliche: In Common Lisp sind Funktionen wie + und * 'überladen' - d.h. sie können reelle Zahlen berechnen, z.B. (+ 3 4), aber sie können auch komplexe Zahlen berechnen, z.B. (+ '(3 5)'(1 0)) - zumindest, wenn man das wünscht. In AutoLisp konnte man solche Überladungen früher auch realisieren, damit ist aber Schluss, seitdem der AutoLisp-Interpreter (der im wesentlichen aus Peterborough, NH stammte - ein sehr netter Ort übrigens, eine Reise wert!!!) durch den VisualLisp-Interpreter ersetzt wurde, der aus Moskau stammt (da war ich noch nie).

Langer Rede kurzer Sinn: Du wirst den Code durchsehen müssen und da, wo komplexe Zahlen ins Spiel kommen, die Funktion + durch ComplexAdd ersetzen müssen. Komfort ist seit Acad14 nicht mehr drin - den Code in ein bisschen Watte einpacken, dass er auch so läuft, ist seit der 'Roten Fahne' nicht mehr.

Hinweise noch: Die Add/Mul einer komplexen Zahl kannst du so annehmen, dass R1 == (complex R1 0) ist - heisst: R1 + 0*i

Disclaimer: Diese Tipps wurden 'as is' gegeben - der Autor haftet nicht für Schäden, die daraus entstehen, dass er seit meheren Jahrhunderten nicht mehr mit komplexen Zahlen gerechnet hat, dass er sich den vorliegenden Code nicht mal richtig angeschaut hat, dass er immer noch dem alten Autolisp-Interpreter hinterherheult, wo soooooooo viel mehr möglich war usw. usf.

Wenn was *echt* falsch war, das werden Achim oder Tom schon reklamieren;-)

Gruß, Axel

PS: Wenn die Appelmännekens dann laufen, möchte ich aber auch was sehen!

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

[Diese Nachricht wurde von mapcar am 27. Mrz. 2004 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Und nochmal ich, heute hab ich ja Zeit:-)

In deinem Code solltest du aber noch ein paar Dinge klären, z.B. tausend unnötige ifs rausschmeissen. Und vielleicht mal die ganzen setvars durch setq ersetzen. Inzwischen habe ich auch mal einen Blick auf den Ausgangscode geworfen: Deine Zeile

(while (> (+ (* (realpart z) (realpart z)) (* (imagpart z) (imagpart z))) 4)

ist mit Sicherheit ziemlich daneben, denn die Zahl 4 ist wohl ein Abbruchkriterium (im O. ist das ein ((when ...)(return ...))! When mit While zu übersetzen, führt i.d.R. zu ziemlich langen Rechenzeiten, nährungsweise unendlichen;-) Das wäre also genau die Stelle, wo das einzige If hingehört.

Na ja, viel Spaß noch!

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

[Diese Nachricht wurde von mapcar am 27. Mrz. 2004 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von mapcar:
Komplexe Zahlen als Liste von 2 Elementen speichern, dann ist realpart = car und imagpart = cadr. Die Zeiten, wo es noch ganz einfach ging (setq realpart car imagpart cdr) sind aber in AutoLisp leider vorbei.

---

Hallo Axel,

Warum? Das funktioniert noch wie schon immer:

(setq realpart car)
#<SUBR @0222ef8c CAR>
(realpart '(1 2 3))
1

Sogar mein uraltes objectiveCAD funktioniert noch immer, das ja "on the fly" parametrische Objekte als LISP-Funktionen definiert. Was nicht mehr funktioniert, ist der Zugriff auf die Definition einer Funktion, denn die liegt nun leider nicht mehr in Listenform vor. Und damit funktionieren auch sich selbst modifizierende Funktionen nicht mehr. Aber auch all das geht noch immer, wenn man DEFUN-Q statt DEFUN verwendet. So ist die KI noch nicht mal in AutoCAD tot, und man kann noch immer selbstlernende Programme schreiben :-)

Übrigens fällt mir dazu eine sehr beliebte Fehlerquelle auch teurer kommerzieller Applikationen ein: die S::STARTUP Funktion muss unbedingt via DEFUN-Q definiert werden, damit mehrere Programme diese nutzen können.

Gruß
Tom Berger

------------------
Architekturwerkzeuge für AutoCAD: http://www.archtools.de

---

ich glaube hier wurde generell was missverstanden, die höhe der einzelnen punkte wird durch die dauer wie lang es dauert bis die komplexe zahl berechnet wurde dargestellt udn es gibt viele zahlen die halt unendlich lang (bzw. bis zu einem definierbaren timeout) berechnet werden => höhe 0 oder farbe schwarz, die mandelbrot menge ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Imion:
ich glaube hier wurde generell was missverstanden, die höhe der einzelnen punkte wird durch die dauer wie lang es dauert bis die komplexe zahl berechnet wurde dargestellt udn es gibt viele zahlen die halt unendlich lang (bzw. bis zu einem definierbaren timeout) berechnet werden => höhe 0 oder farbe schwarz, die mandelbrot menge ...

---

Nein, da hast Du was falsch verstanden. Auf die Menge der imaginären Zahlen in einem bestimmten Bereich wird rekursiv eine Funktion ausgeübt. Rekursiv heisst hier, dass das Ergebnis dieser Funktion beim nächsten Aufruf der Funktion wieder als Eingangsparameter verwendet wird.

Dabei gibt es nun Zahlen in diesem ursprünglichen Ausgangsfeld, bei denen nach sehr vielen rekursiven Durchläufen sich das Ergebnis auf einen bestimmten Wert einpendelt, es gibt Zahlen, bei denen das Funktionsergebnis zwischen zwei Randwerten hin- und herpendelt, und es gibt Zahlen, bei denen sich das Funktionsergebnis Richtung +/- Unendlich bewegt.

Die Rekursion machst Du nicht unendlich oft, sondern brichst zweckmäßigerweise schon vorher ab :-) und siehst nach, wie das Ergebnis ist - entsprechend färbst Du in die Ausgangszahlen ein. Und damit kriegst Du diese schönen Bilder.

Das Hineinzoomen funktioniert deshalb, weil das Verhalten eng nebeneinander liegender Ausgangszahlen eben nicht vorhersagbar ist. Kleine Änderungen können sehr große Auswirkungen haben. Anhand des Bilds beim Zoomen sieht man, dass da zwar eine gewisse Ähnlichkeit der Strukturen vorliegt, aber sie ist eben niemals vorhersagbar.

Man muß sich tatsächlich wundern, dass es so lange gedauert hat, bis diese Art des deterministischen Chaos bekannt wurde, weil sie vielen, wenn nicht sogar den meisten natürlichen Prozessen zugrunde liegt. Schon ein einfaches Pendel mit 3 stabilen Zuständen verhält sich chaotisch, was bedeutet, dass man nicht vorhersagen kann, bei welchem der Zustände das Pendel nach einer Auslenkung landen wird. Manche Esoteriker meinen nun, dass damit die strengen Naturgesetze widerlegt würden - aber das exakte Gegenteil ist der Fall: dieses chaotische Verhalten lässt sich exakt durch die einfachen Pendelgleichungen vorhersagen (und diese sind ja schon seit ein paar hundert Jahren bekannt!). Das Problem ist eben, dass man in der Wirklichkeit niemals das Pendel ganz exakt so auslenken kann, wie man die Auslenkung in dieser theoretischen Gleichung als Zahlenwert einsetzen muß. Und schon  ein halbes Angström weitere Auslenkung führt zu einem völlig anderen Ergebnis.

Gruß
Tom Berger

------------------
Architekturwerkzeuge für AutoCAD: http://www.archtools.de

---

Hallo Imion,
Ich will Dir den Spass am selber programmieren nicht verderben. Aber ich habe mal in Google „Mandelbrot AutoCAD“ eingegeben. Mir war das hat schon jemand gemacht – mindestens in 2d und mit Farben. Und siehe Da: http://new.cadalyst.com/code/browseyear.cfm?fullyear=1994

Ich habe den Code von Jason etwas abgeändert, so dass der Farbcode gerade die z Höhe ist.
Mit Punkten kann man aber nicht allzu viel anstellen ausser man habe ein Tool das aus Punktwolken Flächen macht. Das gibt es (z.B. Land developer Desktop oder ein kleines Plug in für 250 Euronen - http://www.fpsols.com/point_cloud_ac.html)

Also wäre die Frage wie man diesen code so abändert, dass es nicht Punkte sondern SOLIDS (AutoCAD 2d solids also 2d Flächen als Dreiecke) macht. Das sollte doch möglich sein.
Meine Idee:
A,B,C… sind Reihen
1,2,3 sind Kolonnen
1. Dreieck A1,A2,B1
2. Dreieck A2, B1, B2
3. Dreieck A2, A3,B2
usw.

Also „mein“ aktueller Stand:
==========
;;TIP 991:  MANDE.LSP (c)1994, Jason Orndorff

(defun c:MANDE ()
    (setq acorner (getreal "Enter lower left x coordinate {-.5 to 2.5}: "))
    (setq bcorner (getreal "Enter lower left y coordinate {-1.5 to 1.5}: "))
    (setq side (getreal "Enter length of side {3.0 max.}: "))
    (setq gap (/ side 100))
    (setq m (getint "Enter starting screen row: "))
    (setq n (getint "Enter starting screen column: "))
    (while (<= m 100)
      (setq bc (+ (* m gap) bcorner))
        (while (<= n 100)
          (setq ac (+ (* n gap) acorner))
            (setq az 0.0)
            (setq bz 0.0)
            (setq count 0)
        (setq size 0.0)
            (while
                (and (< size 4.0)
                    (< count 250))
                (setq q (* 2 az bz))
                (setq az (+ ac (- (* az az) (* bz bz))))
                (setq bz (+ q bc))
                (setq size (+ (* az az) (* bz bz)))
                (setq count (+ 1 count))                   
            )
    (setq z (- (* 2.458 (expt count 0.67)) 1.458))
            (command "farbe" (fix z))
            (command "punkt" (list n m z))
            (setq n (+ 1 n))
        )
        (setq n 1)
        (setq m (+ 1 m))
    )
)
=========
Ich hoffe Jason lässt mich nicht gleich verhaften wenn ich seinen schönen code abänderte. Wissend dass ich deine Frage nicht exakt beantwortete - Aber trotzdem

Gruss
Martin

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

meine idee war halt mit
(entmake (list '(0 . "Polyline") (70 . 64)) ein polynetz zu machen und jeden punkt der kreiiert wird einem punkt auf dme netz zuzuweißen, d.h. jedesmal wenn der einen neuen punkt kreiiert muss der eine x koordinate wieterspringen udn wenn der am ende einer reihe angekommen ist muss er eine zeile y weiterspringen und x auf 0 (oder 1) setzen... das hab ich mit 2 while-schleifen gemacht ...

BTW thx für den link, spart einiges an arbeit, jetzt nurnoch in 3d versuchen, ma morgen gucken ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mandelbrot_3d.jpg

Hallo,
Da war noch ein Fehler. mir 3d Punkten sollte man natürlich _3DFACE Dreiecke erzeugen - mit SOLIDS klappt das nur in der Ebene.
Aber das hättet Ihr ja wohl selber bemerkt.
Aber die "Mandelbrot Wolken" sehen hübsch aus.
Gruss
Martin

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Tom,

in diesen Fall funktioniert es wohl noch - es hängt davon ab, ob die Funktionen intern als 'special form' oder als Makros implemntiert sind. Bei den meisten Funktionen geht es in die Hose, deswegen meine Aussage 'geht nicht mehr'. Irgendwo gab's dazu auch mal eine längere Diskussion.

Code:

---

(setq then progn) => #<SUBR @0a912a28 PROGN> ; das geht zwar, aber...
(if(> 4 3)(then(princ"Wow!"))) = > error: cannot apply special form: PROGN

---

Wenn ich mich recht erinnere, geht's im VL-Editor überhaupt nicht...

Ich musste irgendwann (u.A. wegen (setq then progn else progn), das ich jahrelang verwendet habe) mit der Einführung des VL-Interpreters _alle_ Programme umstricken, die ich bis dahin geschrieben hatte. Ich verlasse mich also nicht mehr darauf, dass es bei car und cdr _noch_ geht, bei progn oder defun aber nicht. Schade;-)

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP