Einen "kleinen" Fehler in der Division hab ich noch entdeckt, da wurde bei der letzen Umstellung ein Vergleich mit einem "falschen" Wert gemacht, welcher vorher zu früh auf "1" gesetzt wurde.
OK, da das nur die interne optimierung betraf, wurde zwar immernoch richtig gerechnet, aber leider wurde mit steigender Dezimalstellenanzahl (der Stellen-Differenz zwischen Divisor und Dividend) die Berechnung expotentiell zur Stellenanzahl verlangsamt
Dann hab ich mal einige Stringoperationen beim Vergleich entfernt
und wenn dann demnächst eine "neue" Normalisierungsfunktion vorhanden ist, wird bei bereits normalisierten Zahlen keine Stringoperation/-veränderung mehr erforderlich sein, also nur noch ein "reiner" Vergleich.
Delphi-Quellcode:
// vorher
Function TMathe.Vergleich(a, b: String): TValueRelationship;
Begin
_Formatieren(a, False, True);
_Formatieren(b, False, True);
If (a[1] = '-') and (b[1] = '+') Then Result := LessThanValue
Else If (a[1] = '+') and (b[1] = '-') Then Result := GreaterThanValue
// jetzt
Function TMathe.Vergleich(a, b: String): TValueRelationship;
Begin
If _ImmerNormalisieren Then Begin
_Normalisieren(a);
_Normalisieren(b);
End;
If (a[1] = '-') and (b[1] <> '-') Then Result := LessThanValue
Else If (a[1] <> '-') and (b[1] = '-') Then Result := GreaterThanValue
Das Nachkommaproblem bei Potenz10, Produkt10 und Quotient10, im Fließkommaparser, ist jetzt behoben,
aber für Potenz hab ich keine wirkliche Lösung, außer daß ich da wohl eine komplett eigene Potenz-Funktion (nur für den Parser) erstellen müßte,
denn so wäre das nicht wirklich effektiv,
Delphi-Quellcode:
// in Ganzzahl umwandeln
a := Trunc(a * (10 ^ n));
b := Trunc(b * (10 ^ n));
// rechnen
Result := Mathe.Potenz(a, b);
Result := Mathe.Quotient(Result, 10 ^ (n * b-1));
// wieder in natürlichen Zahl umwandeln (mit Komma)
Result := Result / (10 ^ n);
// n = Anzahl der Nachkommastellen
da dann abhängig von den Nachkommastellen ein sehr großes Zwischenergebnis entsteht ... also dieses wäre
a*10^n ^ b*10^n = 20*10^100 ^ 50*10^100
102 ^
20^50 bei 100 Stellen nach'm Komma = statt einer 65-stelligen Zahl eine mit über 5e103 Dezimalstellen
Nja, aber erstmal schau ich nach den Rechenfehlern, welche noch auf Seite 5 erwähnt wurden.
[add]
Zitat:
[01.07.2009 19°° v1.4]
- Verzögerungsfehler in Division entfernt, welcher die Rechenoptimierung abschaltete (#76)
- Vergleichsfunktion optimiert (#76)
- Potenz10, Produkt10 und Quotient10 in StringMatheParserFloat.pas berichtig und freigegeben (Nachkommastellenproblem #76)