Logarithmus

[DasJan]

Fiese Überläufe hab ich aber auch nicht bemerkt,

Hast du auch alle Eingaben ausprobiert?
Aber egal. Wenn so was passiert, dann wird DieFüchsin das sicher merken.

Poste doch mal den Dreizeiler, ich bin gespannt (und zu faul, es selbst zu coden ).

Der Code ist sicher fehlerhaft, weil nicht getestet, aber so ähnlich könnte das in C aussehen (ohne den Trick, der bei Wikipedia noch angegeben ist):

Code: Alles auswählen

double ln(double x)
{
   int k;
   double result, s;
   result = 0.0;
   for (k = 0; 
        (1e-10 < (s = pow(((x-1) / (x+1)), 2*k + 1) / (2*k + 1));
        k++)
   {
      result += s;
   }
   return (2.0 * result);
}

Man könnte natürlich auch noch k = 0 nach vorne setzen und den Schleifenkopf zu

Code: Alles auswählen

for (; (1e-10 < (s = pow(((x-1) / (x+1)), 2*k + 1) / (2*k++ + 1)); )

reduzieren

Das Jan

[DasJan]

uff, also ich krieg als Ergebnis 61 raus, kann das sein, dass man so viele Versuche für dieses dämliche Zahnradrätsel braucht??? das wär ja katastrophal!

Mit welchen Zahlen rufst du denn die Logarithmusfunktion auf? Wenn log(2.0, x) bei dir 61 ist, dann ist entweder x sehr groß (2^61) oder der Algorithmus von khrismuc falsch.

Das Jan

[DieFüchsin]

joa x ist viel zu hoch wies scheint... hmmm aber ist möglicherweise halb so schlimm, dann schränke ich eben x stark ein

[DasJan]

Nachtrag @khrismuc: Den Trick, x in die Naehe von 1 zu bringen, sollte man schon anwenden. Sonst konvergiert es viel zu langsam. So kommt man bei der Berechnung von ln(5121024.64) von etwas ueber 8 Millionen Iterationen auf 6, plus 22 fuer die Berechnung von m.

Das Jan

[KhrisMUC]

Das feine an meiner Funktion ist ja, dass sie immer etwa gleichlang braucht. Erst probiert sie -100 bis 100 in Zehnerschritten, angenommen, bei 20 wird das Ergebnis zu gross, wird jetzt 11-20 durchprobiert, dann meinetwegen 13.1 bis 14, dann 13.51 bis 13.6, usw.
Ich hab bei 6 Nachkommastellen also 8 Durchläufe à 10 Testberechungen (im ungünstigsten Fall). Zwar rechne ich jedesmal base^test, aber eben nur höchstens 80mal.
Schneller und genauer geht's wohl kaum.

[DieFüchsin]

Jedenfalls funktioniert es

[DasJan]

Das feine an meiner Funktion ist ja, dass sie immer etwa gleichlang braucht.

Falsch. Du übersiehst, dass du nur Logarithmen zwischen -100 und 100 berechnen kann. Was liefert deine Funktion z.B. bei Logarithmus (2.0, 512.0)? Dein Algorithmus ist deswegen linar in der Länge der größtmöglichen Eingabezahl. Und die ist auch noch fest im Programm verdrahtet. Wenn jetzt jemand kommt und will bis 1000 rechnen, muss er das Programm verändern und neu kompilieren. Willst du dann aber nur ln(2) ausrechnen, braucht das Programm unnötig lange, weil es bei 1000 anfängt.

Das Jan

[KhrisMUC]

Was liefert deine Funktion z.B. bei Logarithmus (2.0, 512.0)?

Ohne es auszuprobieren, würde ich vermuten, sie liefert 9.000000...
Falsch ist gut, die Aussage stimmt, nur meine Funktion deckt halt nicht alles ab.
Übersehen habe ich das aber nicht, ich habe bewusst -100 bis 100 genommen, denn andere Werte für den Exponenten sind praktisch uninteressant, zumindest im Alltagsgebrauch.

Kann es sein, dass Du Exponent und Basis verwechselt hast?

Wenn ein Exponent tatsächlich mal größer als 100 sein sollte, braucht das Programm nur bis zu 10 Schritte mehr, angenommen der gesucht Exponent wäre 537, dann würde es base^-1000 testen, dann base^-900, usw, bis base^600. Aha, zu groß, weiter mit base^510, 520, ... 540, aha, zu gross, 531, 532, usw.
Die zwanzig Schritte vom Anfang würden sich lediglich auf den Tausenderbereich verlagern, danach gehts wie gewohnt weiter.