Volker,
ich bin da jetzt nicht im Thema, welcher Algorithmus da am schnellsten ist und C64, joa das ist lange her ... insoweit ist Dein Beitrag eher zum Schmunzeln.
Mit Assembler programmierte ich seinerzeit Grafik-Grundfunktionen (Punkt in x/y setzen, Linie/Kreis zeichnen), denn im C64-Basic konnte man sowas ja sonst punktweise mitverfolgen, so langsam war das.
Wichtig bei iterativer Näherung war natürlich immer Geschwindigkeit, KO-Kriterium war immer Beachtung der Speicherkapazität. Da gibt es ja auch den Trade-off - mehr rechnen vs. Daten im Speicher vorhalten.
Die Komplexität/Schnelligkeit von Formeln misst man (meist) in Anzahl der Mulitiplikationen und Additionen, gemessen über die Anzahl der (durchschnittlichen) Interationen. Es ist nicht nur die Formel selbst, sondern auch, wie man sie im Code dann umsetzt. Ein schönes Beispiel ist die FFT, die im Restklassenring (Modulo) sehr schnell rechnet.
Mindestens so wichtig ist dabei auch das Festlegen des Abbruchkriteriums und des max. Fehlers (sprich der in Kauf zu nehmende Ungenauigkeit).
Keplerellipsen ... sind die nicht analytisch lösbar? Meines Wissens ist erst das 3-Körper-Problem analytisch nicht mehr lösbar. Die Kurvendiskussion für Kegelschnitte programmierte ich seinerzeit ('86) in meinen Basic-Taschenrechner Sharp-1401**, für die Abi-Klausur brauchte ich das dann schon nicht mehr ... wenn man es programmieren kann, kennt man ja den Algorithmus aus dem Eff-Eff ...
**den Sharp-1401 hatte ich von 1985 (damals schweineteuer) bis 2013, bis die LCD-Anzeige ihren Geist aufgab. 28 Jahre, ich glaub, das ist beim heutigen IT-Equipment nicht wiederholbar. Beim C64 auf dem Dachboden müsste ich erst mal gucken, ob der überhaupt noch angeht und ob ich noch einen TV finde, der auf Kanal 33-36 (war's doch, oder?) die Signale empfängt.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Der damalige, aus der Speichernot geborene Programmierstil spiegelt sich noch heute im Source Code mancher Programmierer wider.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Im Grunde ist das heute nicht anders. Nur im Source Code selbst muss man nicht "sparsam" sein. Es reicht, wenn der ausführbare Code das ist. Sparsamkeitkeit im Sourcecode ist meist eine Umschreibung für fehlende Dokumentation. Bei der Webprogrammierung hat das sogar System und nennt sich Obfuskation.
Der Ballast kommt eher vom nicht Nutzen diverser Bibliotheken. Und da landet man beim Problem, dass das Nachschlagen/Suchen nach bestehenden Lösungen manchmal zeitaufwändiger ist als das Selbstprogrammieren. Das Thema Datenschnittstellen kommt noch hinzu.
