Mathe mit Strings (die deutsche StringMatheLib ._. )

[himitsu]

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)