EPS = 0.0001...?????

[Hmooslechner]

Wie geht Ihr eigentlich mit der Fehlermeldung um, die man bekommt, wenn man einem Array zB.hypotenuse3D eine reale Zahl zuordnet, um Divisionen durch Null zu verhindern.

 
EPS1 = 0.0001


hypotenuse2D[i] = sqr((x[i+1]-x[i])^2 +(y[i+1]-y[i])^2)   !!Distanz Jetzt - Nächster
hypotenuse3D[i] = sqr(hypotenuse2D[i]^2 + (z[i+1]-z[i])^2)  !!3D

if z[i+1] = 0 then z[i+1]  = EPS1
if z[i] = 0 then z[i]  = EPS1
if y[i+1] = 0 then y[i+1]  = EPS1
if y[i] = 0 then y[i]  = EPS1


	beta = ((x[i+1]-x[i])/hypotenuse2D[i]) !!Division - möglicherweise durch 0 - mit EPS verhindert

Bei diesem Beispiel wird ja durch null dividiert, wenn Z null ist. - Dann gibts ja eine Fehlermeldung - was ja ganz ok ist .

Um dies zu verhindern legt man eben bei hypotenuse3D =0 fest, dass eben nicht ganz null reingeschrieben wird. Ist sehr "dirty - Aber wie löst Ihr das?

Man bekommt dann eben folgende Warnung:

"Die Verwendung von realen Typen kann zu Präzisionsproblemen führen bei Zeile..." - Was ja auch stimmt, aber in so einem Fall ja beabsichtigt ist. Kann man die Meldung eigentlich abschalten? Oder sonstwie umgehen, weil somit der "Debugger" (falls man das so nennen soll) fast sinnlos wird. Besonders bei Programmen, die solches EPS dann oft benötigen..

[Hmooslechner]

Das genau zu wissen wäre wirklich einmal eine interessante Information. In meinen C++-Zeiten hat man uns gelehrt, dass man besonders Divisionen mit Kommastellen möglichst im Programm vermeiden sollte, da der damals normale Hauptprozessor mit Gleitkomma - Operationen Probleme hatte. Zum Betrieb des damals noch steinzeitlichen Autocad 1.18 war sogar noch nötig, am PC einen zusätzlichen teueren Koprozessor einzubauen, der diese Aufgabe übernehmen sollte. In den Pentiums war der dann mit eingebaut.

Mir persönlich neu ist Deine Info, dass Stringoperationen langsamer sein sollen, da die doch eindeutig mit Bytes - also mit 8-Bit-Buchstaben mit direkten Anfragen durchgerechnet werden - im Gegensatz zu Gleitkommaoperationen, die im entsprechenden Prozessor mit vielen Iterationen im brute-force-Verfahren ausgerechnet werden. (was natürlich bei unseren beiden Möglichkeiten nicht zutrifft - das sind einfache Vergleiche von Werten)

Du könntest durchaus recht haben, dass die EPS-form effizienter ist, weil die Umwandlung von Zahl in String entfällt. Vielleicht könnte mans testen, indem man beide Arten in einer sehr großen Menge wiederholt und die Zeit misst. Akademische Hirnw.. grins.

noch ein Zitat aus dem GDL-Kochbuch -Abschnitt 1.25:

Rechner können leichter multiplizieren als dividieren. Zu dividieren kann vielleicht 32 Recheneinheiten beanspru- chen, wohingegen multiplizieren 1,2 oder 4 Rechenein- heiten benötigt, abhängig davon, über welchen Rechner wir sprechen, und ob der Rechner optimiert ist für Fließ- kommas oder Ganzzahlen. Es mag auf den ersten Blick einfacher sein, einen Ausdruck wie „LET len=wid*3/4“ zu schreiben, aber er wird wahrscheinlich schneller in der Form von „LET len=wid*0.75“ berechnet. Sicherlich macht sich der Zeitunterschied nur bei extrem langen Scripten bemerkbar.
Sie schreiben immer einen effizienten Code, indem Sie Polylinien und klare Strukturierung verwenden.

Auch interessant wäre - ob es schneller geht - Punkte zu berechnen und dann als Startpunkte der 2D-3D-Anweisungen zu verwenden oder das Koordinatensystem zu verschieben und die Teile mit lokalem Startkoordinaten 0 zu setzen.

Einen Vergleich in dieser Richtung habe ich schon als Video gepostet: native Morphs bauen wesentlich langsamer auf als der selbe Körper in ein GDL umgewandelt - seltsam aber wahr.

[Frank Beister]

Die Probleme bei Stringoperationen sind, dass deren Länge undefiniert ist. Sie können 2 oder 255 Zeichen lang sein. Bei jeder Operation muss eine neue Kette gebildet werden und belegt Speicherplatz. Diesen wieder effizient freizugeben war zumindest bei früheren Betriebssystemen und Sprachen ein Problem, weil der Arbeitsspeicher bei intensiver String-Nutzung leicht fragmentierte. Daher wurde von Zeit zu Zeit eine Garbage collection durchgeführt, die wieder aufräumte. Wohingegen numerische Werte auf Grund ihrer strikten Definition besser zu verwalten sind. Ich glaube nicht, dass das heute wirklich relevant ist, aber es ist etwas wie Jogginganzug in der Oper. Kann man machen, ist aber kein guter Stil. 😉 (Und manchmal kommt schlcht nicht ans Ziel damit)