Zitat:

---

Original geschrieben von hybrid

Ähm, Stefan?
Wenn ich mich nicht täusche kürzt sich "/log(exp(1))" zu "/1", was man auch kpl. weglassen kann

---

Ähmm, Malte?
log != ln

(Siehe http://de.wikipedia.org/wiki/Logarithmus, Stichwort "Basisumrechnung")

Zitat:

---

Original geschrieben von Stefan Wimmer

Zitat:

---

Original geschrieben von hybrid

Ähm, Stefan?
Wenn ich mich nicht täusche kürzt sich "/log(exp(1))" zu "/1", was man auch kpl. weglassen kann

---

Ähmm, Malte?
log != ln

(Siehe http://de.wikipedia.org/wiki/Logarithmus, Stichwort "Basisumrechnung")

---

Naja, Malte hat doch einigermassen recht: in der Wikipedia steht:

Zitat:

---

log
In der Mathematik steht log für den natürlichen Logarithmus, in technischen Anwendungen (so z.B. bei Taschenrechnern) für den dekadischen Logarithmus, in der Informatik für den dyadischen Logarithmus. Gelegentlich wird log auch verwendet, wenn die verwendete Basis keine Rolle spielt.

---

In der libm steht log() für den natürlichen Logarithmus, der 10er-Logarithmus ist log10(), und so dürfte das auch der GCC für den AVR mit seinen Bibliotheken sehen. Und eigentlich müssten es andere C-Compiler auch so sehen.

Geändert von Andreas Mueller am 06. Januar 2007 um 01:04

Zitat:

---

Original geschrieben von CharlyMai
Weiterhin kann man (fast) jede Formel so zerlegen, dass nur noch 2 Variablen (3 mit Ergebnis) pro Schritt zur Berechnung notwendig sind.

---

Das "fast" darfst Du weglassen, es gibt meines Wissens keine Operation mit drei Operanden, also ist es immer möglich, auf eine Folge von Operationen mit zwei Operationen zu reduzieren. Dass die Bascom-Entwickler das allerdings dem Benutzer überlassen wollen überrascht mich doch etwas...

Zitat:

---

In der libm steht log() für den natürlichen Logarithmus, der 10er-Logarithmus ist log10(), und so dürfte das auch der GCC für den AVR mit seinen Bibliotheken sehen. Und eigentlich müssten es andere C-Compiler auch so sehen.

---

Jupp!
$ man log
...
DESCRIPTION
The log() function returns the natural logarithm of x.
...


Grüße
Malte

PS: Abgesehen davon ist log10(exp(1)) natürlich auch konstant, was der Compiler aber leider auch nicht wegoptimiert bekommt...

Geändert von hybrid am 08. Januar 2007 um 14:03

Da ist es aber schön zu lesen (und geht runter wie Öl) das der hochgelobte C-Compiler auch nicht alles wegoptimiert bekommt ....

viele Grüße
Pierre

Zitat:

---

Original geschrieben von CharlyMai

Da ist es aber schön zu lesen (und geht runter wie Öl) das der hochgelobte C-Compiler auch nicht alles wegoptimiert bekommt ....

---

Woher soll der Compiler wissen können, dass weder log10 noch exp keinen Seiteneffekte haben, der Ausdruck log10(exp(1)) also schon zu Kompilationszeit ausgewertet werden kann? Richtig: er kann es nicht wissen, also kann er auch nicht wegoptimieren. Anders sieht es hingegen mit dem Ausdruck (4711-4709)/2 aus. Hier kann der Compiler das wissen, und er optimiert es auch sauber weg. Der "hochgelobte" C-Compiler vermeidet also einen Fehler, indem er log10(exp(1)) nicht wegoptimiert. Hier wäre der Entwickler gefragt, der eigentlich wissen müsste, dass er wegoptimieren kann

Zitat:

---

Original geschrieben von Andreas Mueller

...Hier wäre der Entwickler gefragt, der eigentlich wissen müsste, dass er wegoptimieren kann

---

Klaro,
aber um aus den Kurs-Board mit einerm Widerstand und einem NTC zusammen mit einem "15-Minuten-Quickhack" mal eben ein Temperaturmessgerät zu basteln kann man es mit der Optimierungs-Liebesmüh' aber auch übertreiben...

Hey Stefan, das sollte doch gar kein Angriff sein!

Ich hätte das überhaupt nicht auf die Reihe bekommen, aber exp(1) sprang mir gleich ins Auge und da musste ich ein bißchen rechnen

Wo kommt denn die hochkomplexe Formel überhaupt her? Hast Du die hergeleitet, oder stand die in einem Buch/Datenblatt?

Man sieht sehr schön, daß ein paar Minuten mehr Beschäftigung mit den Innereien einer Software u.U. Jahre aun Rechenzeit einsparen kann.

Das erinnert mich an eine Situation vor sicher 15Jahren auf einem Uni-Rechner (Sun), auf dem ich per Modem (Berlin, kein 8-Minuten-Takt) eingeloggt war. Ein Prozess eines anderen Users lief schon stundenlang und ich musste auch irgendwas machen. Da wurde ich plötzlich per "talk" angepöbelt, ihm die Rechenzeit auf dem Ding nicht zu klauen, er hätte wichtige Berechnungen durchzuführen. Neugierig wie ich war schaute ich in seinem (offenen) home Verzeichnis nach und sah, was so wichtig war: Eine diskrete Fourier-Transformation, bei der er für jeden Datenpunkt und jeden Durchlauf den sinus und cosinus des jeweiligen Winkels neu berechnete.
Mit einer Tabelle für die sin und cos-Werte wäre das ganze schon mal sicher um den Faktor 100 schneller geworden. Mit einer FFT vermutlich um den Faktor 10.000...

Wenn ich mir heutige Software ansehe, die auf Prozessoren mit > 1000MIPS und > 1000MFlops immer noch schleicht, vermute ich, der Knabe von damals ist nicht der einzige !

Grüße
Malte

Geändert von hybrid am 09. Januar 2007 um 14:21

Zitat:

---

Original geschrieben von hybrid

Hey Stefan, das sollte doch gar kein Angriff sein!

---

...so habe ich es ja auch gar nicht aufgefasst!

Zitat:

---

Wo kommt denn die hochkomplexe Formel überhaupt her? Hast Du die hergeleitet, oder stand die in einem Buch/Datenblatt?

---

...die Formel steht in jedem besseren Datenblatt oder Abhandlung zu NTCs, z.B. auch HIER.


Der Effekt, mit hirnlos dahergeschriebener Software auch die schnellsten Prozessoren bei einfachsten Aufgaben in die Knie zu zwingen hat übrigens schon einen eigenen Namen bekommen: "Bloating".
Der Name kommt daher, weil der heutige Programmierer nicht mehr nötig hat, sein eigenes Hirn zu strapazieren, denn er kann ja einfach mal ein paar -zig Bibliotheken dazulinken, dann ist schon irgendwo das mit drin, was er explizit gerade braucht. Festplattenplatz kostet ja heutzutage nichts mehr.

Gott bewahre, dass so einer mal versucht auf embedded Systemen was zu machen. Der braucht dann einen ARM oder Coldfire mit 16MB SDRAM um eine LED zum Blinken zu bringen...

Geändert von Stefan Wimmer am 09. Januar 2007 um 21:00