Mathe mit Strings (die deutsche StringMatheLib ._. )

[gammatester]

Ist es nicht langsam mal Zeit, in die Units eine Versionsnummer rein zuschreiben? Bei den häufigen Änderungen weiß man sonst ja gar nicht was aktuell ist und worauf man sich beziehen soll.

Außerdem sind auch dringend einige Kommentare nötig (bzw sinnwolle Bezeichner). Was zum Bleistift macht eigentlich in Positive StringMatheFloatRec.pas?????

Delphi-Quellcode:

Class Operator MatheStringX.Positive(r: MatheStringX): MatheStringX;
    Begin
      r.PruefeN;
      Result._n := r._n;
      Result._f := r._f;
    End;

oder: MatheStringX.Negative sollte doch wohl irgendwie "absolute" enthalten!? Vom Code habe ich den Eindruck, das nur was Negatives negiert wird (außer r.PruefeN, daß aber gar nix prüft, sondern aus einem Leerstring eine '0' macht). Ganz abgesehen davon, daß ich das Teil selbst mit Delphi 9 nicht übersetzen kann, geschweige denn mit D6.

[himitsu]

Zitat:

Zitat von gammatester

Ist es nicht langsam mal Zeit, in die Units eine Versionsnummer rein zuschreiben?
Bei den häufigen Änderungen weiß man sonst ja gar nicht was aktuell ist und worauf man sich beziehen soll.

Kennst du die Gedanken, wie "so, es läuft und jetzt wird wohl so schnell nichts mehr dran geändert" ? :lol:

Nja, ich wollte demnächst da den Header wie aus himXML reinpacken, also zusammen mit Lizenz, Version und Co.
Nur bin ich da noch nicht ganz fertig ... kommt demnächst.

Aber immerhin wird seit 'ner Weile im Beitrag #1 ganz unten das Datum+Uhrzeit der da hochgeladenen Version angezeigt. :angel2:

Aber ich schreibe vermutlich gleich meinen Lizenztext und dann kommst das alles mit rein.

[quote="gammatester"]Außerdem sind auch dringend einige Kommentare nötig (bzw sinnwolle Bezeichner). Was zum Bleistift macht eigentlich in Positive StringMatheFloatRec.pas?????

Delphi-Quellcode:

Class Operator MatheStringX.Positive(r: MatheStringX): MatheStringX;
    Begin
      r.PruefeN;
      Result._n := r._n;
      Result._f := r._f;
    End;

was Positive ist, steht in der Delphi-OH :mrgreen:

im Grunde ist es eine "schwachsinnige" Funktion (zumindestens in Bezug auf "normale" Rechenoperationen),
denn es entspricht dem +X

PS: siehe http://www.delphipraxis.net/internal...t.php?t=151206

Negative ist -X

ja und Add ist X + Y

also in Positive wird hier praktisch nichts anderes gemacht, als den Wert unverändert zurückzugeben :nerd:

Zitat:

Zitat von gammatester

oder: MatheStringX.Negative sollte doch wohl irgendwie "absolute" enthalten!?

so hab ich's grad vorgefunden

Delphi-Quellcode:

Class Operator MatheString.Negative(Const r: MatheString): MatheString;
  Begin
    Result._i := r._i;
    If _Mathe.istPositiv(Result._i) Then _Mathe.Negieren(Result._i);
  End;

es wird die Zahl negativ gemacht ... und wie ich grad merk ist das völlig idiotisch,
denn es soll ja -X entsprechen ... also muß das IF-Then raus.

_i = der interne Integer
_f = der interne Float bzw. die Fließkommazahl

dachte eigentlich das könnte man sich noch denken, da es ja sonst keine internen Variablen gibt

OK und das _n ist neu und soll die Nachkommastellen enthalten (hab da grad einen Kommentag mit dazugeschrieben)

und sonst dachte ich, hällst die "unverwechselbaren" internen Variablen schön handlich kurz :stupid:

PS: ja, ich weiß, viele nennen diese Art der Variablen Fname und bei mir ist es halt _name, da ich diese besser erkenne.

PrüfeN stellt nur sicher, daß _n keine uninitialisierten Werte enthält, da standardmäßig nur der String von Delphi automatisch initialisiert wird.

[himitsu]

Versionshinweis und Lizenz hinzugefügt

Version: v1.0 Stand 16.06.2009
Lizenzen: MPL + (L)GPL

neue Version mit Variants (StringMatheVar.pas) beigelegt ... man darf sich gern bei sirius dafür bedanken (oder ihn deswegen verhauen) :nerd:

ja und ich hab mir mal erlaubt einen neuen Kommentar reinzumachen :angel2: (beim _n in StringMatheFloatRec.pas)

[toms]

Zitat:

Zitat von himitsu

Bin gespannt, ob es nun auch in D5 läuft.

Funktioniert noch nicht ganz:

[Error] StringMatheLib.pas(120): Undeclared identifier: 'TValueRelationship'

Zudem:

[Error] Demo1U.pas(43): Undeclared identifier: 'Buttons'

Delphi-Quellcode:

RadioGroup1.Buttons[1].Visible  := False;
RadioGroup1.Buttons[6].Visible  := False;
// etc..

müsste unter D5 so geschrieben werden:

Delphi-Quellcode:

    with RadioGroup1 do
    begin
       Controls[1].Visible := False;
       Controls[6].Visible := False;
       // etc.
    end;

[himitsu]

das .Controls läuft auch in aktuellen Versionen :)

ja und bezüglich des TValueRelationship ... da hatte klein himi die Ersatzdefinition an falscher Stelle definiert (erst nachdem sie das erste Mal verwendet würde) :oops:

[himitsu]

ich experimentiere grad mit einem MatheParser :shock:

was er so theoretisch kennt

• Klammern: ( )
  
• Operatoren: + - * / div // mod ^
  
  // = entspricht mod
  ^ = Potenz
  
• Konstanten:
  pi10 = π * 10^10
  pi100 = π * 10^100
  e10 = e * 10^10
  e100 = e * 10^100
  
• Funktionen: Summe Plus1 Differenz Minus1 Negieren Absolut
  Produkt Quotient Modulo Quadrat Quadratwurzel Potenz Potenz10
  SummeModulo DifferenzModulo ProduktModulo PotenzModulo
  Zufallszahl gibVorzeichen Dezimalstellen
  
  Parameter siehe TMathe
  gibVorzeichen = Mathe.gibVorzeichen + '1'

[edit]
Anhänge entfernt
siehe Beitrag #56: ist jetzt im Post #1 enthalten

[Dax]

Ist "Ergebis" absichtlich so geschrieben? O:-)

[himitsu]

Zitat:

Zitat von Dax

Ist "Ergebis" absichtlich so geschrieben? O:-)

ja :mrgreen: (ist ja fast so gut, wie das Parster, was es noch bis vor 1,5 Stunden gab)

[Dax]

Rein theoretisch könntest du dich ja des Schinkens annehmen und entsprechende Plugins für die SML basteln, meinst du nicht? *g*

[gammatester]

Bug: 2^10 = 20, 2^1000 mod 9 = 2 etc. Grund:

Delphi-Quellcode:

Function Operator_Potenz(Mathe: TMathe; Const a, b: String): String;
Begin
  Result := Mathe.Produkt(a, b);
End;

[gammatester]

Bug:

Code:

StringMatheLib.pas(810)
StringMatheParser.pas(163) Error: Undeclared identifier: 'SummeModulo'
StringMatheParser.pas(169) Error: Undeclared identifier: 'DifferenzModulo'
StringMatheParser.pas(491)
ParserU.pas(5) Fatal: Could not compile used unit 'StringMatheParser.pas'

Wahrscheinlich benutzt Du ein neuere Version von StringMatheLib, die nicht dabei ist.

[himitsu]

ja, die Beiden sind neu

Delphi-Quellcode:

* Function TMathe.SummeModulo(a, b, m: String): String;
    Begin
      Result := Modulo(Summe(a, b), m);
    End;

  Function TMathe.DifferenzModulo(a, b, m: String): String;
    Begin
      Result := Modulo(Differenz(a, b), m);
    End;

wollte eigentlich nur noch schnell die Units aufräumen und etwas optimieren, bevor ich alles hochlade

und ups :oops: , blödes Copy&Paste :nerd:

[gammatester]

Bevor Du optimierst, solltest Du ein grundsätzliches Problem bei dieser Art Parser beseitigen:

Bei Ausdrücken der Art <Term> ::= <Factor1> 'mod' <Factor2> hat man bei Langzahlbibliotheken immer das Problem, daß Factor1 nicht normal ausgewertet werden sollte, sondern wenn der 'mod'-Operator benutzt wird, sollte zuerst Factor2 ausgewertet werden und dann Factor1 via Modulararithmetik mit Modul Factor2. Sonst wirst Du zB praktisch nie eine RSA-Verschlüsselung bzw PotenzMod-Operation mit Nicht-Spielzeugzahlen durchführen können.

Gammatester

PS: Dies ist auch ein Grund, warum Operatorüberladen bei mod eine kitzlige Sache ist, vgl. Hagen's Beitrag

[himitsu]

Falls du sowas meinst R := A ^ B mod C:
Da ich bei den Operatoren die Reinfolge der Operationen nicht beeinflussen kann, wird hier immer erst A ^ B gerechnet und dann erst (A^B) mod C,
aber dafür ist die Lib Selber erstmal als Klasse ausgelegt, wo es die Funktion ProduktModulo gibt. :zwinker:

Die Operatoren ala MOD sind ja nur als "eingeschränktes" Zusatzmodul verfügbar.

[gammatester]

Ja das meinte ich. Allerdings ist diese Nicht-Implementation doch ein wenig einschränkend für einen Langzahl-Rechner. Aber nun zu etwas Positivem, nämlich ein Bug, der beseitigt werden kann: :wink:

2^3^4 wird als (2^3)^4 geparst und nicht, wie es mathematisch richtig wäre, als 2^(3^4).

[himitsu]

so, hab mal den 1. Beitrag editiert und alles Neue mit eingefügt.

zusätzlich wurden der Parser und die "Grund"Lib um folgende Funktionen erweitert:

Code:

Produkt10         r = a * 10^b
Quotient10        r = a div 10^b
Modulo10          r = a mod 10^b
QuotientModulo10  r = a div 10^b   und    m = a mod 10^b

hier wird dann nix gerechnet, da Operationen in 10-Potenzen ja einfach und vorallem schnell, durch Anhängen von '0'en und durch einfaches Umkopieren erledigt werden können. :)

ich hab jetzt allerdings noch nicht alles getestet, aber ich hoff einfach mal es funktioniert
diese Funktionen werden dann auch demnächst in die Normalisierungsfunktion mit einfließen (zumindestens teilweise)


ach ja, falls sich wer wundert: "Normalisieren" entfernt einfach alle ungültigen Zeichen ... aus "-c1a0-" wird also "-10" ... ich glaub da werd' ich demnächst noch was dran ändern.

[add]
es ist doch implementiert ... du mußt da einfach nur die Funktion nehmen und nicht die Operatoren :zwinker:

und was den behebbaren Bug betrifft, da müßte es doch reichen, wenn ich die Auswertung einfach rückwärts angeh :mrgreen:
(wird also hoffentlich beim nächsten Update behoben sein)

[edit]
Bug ist behoben :mrgreen: (siehe #1)

[edit2]
jetzt mekert er bei (2^3)^4 oder ging das schon immer nicht :gruebel:

[gammatester]

Wahrscheinlich bin zu blöd oder Dein Teil mag mich nicht. Wie gebe ich eine Funktion ein? PotenzModulo(????). Aber auch Summe(1,2) mault: Zahl erwartet. Summe( 1 2) mault: Komma erwartet ...

Produkt10('12', 4) oder Produkt10('12', '4') ergeben immer noch 12, statt 4 kannst Du auch 7 oder 42 einsetzen.

Da der Code nicht funktioniert, kann ich auch nicht testen ob Produkt10('0',4) = '0000' ist. Nach Quellcodelage schon. Also Test auf 0 bevor 'geshiftet' wird.

[himitsu]

ups, das mit Summe und Co. ist ein kleiner Fehler im Parser :oops:

so geht es

Code:

Summe(1 , 2)

Problem, das Komma wird mit zur Zahl genommen (also 1,2 aka 1.2 in Pascal ) ... war blöd, da es sich hier doch eh nur um eine Ganzezahllib handelt :roll:
und später wird richtig erkannt, daß in der Zahl kein Komma vorkommen dürfte :stupid:

[edit]
einfach das ',' aus der Whileschleife entfernen und schon sollte es gehn

Delphi-Quellcode:

Function TMatheParser.Trenne(Var Liste: TMatheParserListe; Const S: String; i: Integer): Integer;
...
        End Else If S[i] in ['0'..'9'] Then Begin
          i2 := i;
          While S[i2] in ['0'..'9', '.'] do Inc(i2);

Dennoch hab ich vermutlich irgendwo in der Klammerbehandlung ein Fehler, welcher z.B. (2^3)^4 durchdrehn läßt und einen String zerschießt. :wall:

[gammatester]

So weit OK bei den Funktionen. Das Produkt10-Problem betrifft allerdings die StringMatheLib und bleibt somit bestehen (allerdings kann man jetzt mit dem korrigierten Parser schneller feststellen, daß was nicht stimmt :wink:)

[himitsu]

das Produkt10(0,4) sollte jetzt gehn :)

beim Füllen mit '0' war der PChar etwas zu hoch (das Inc(P) mußte nach dem P^:='0' rein)
und der Fall bezüglich a='0' wird nun auch beachtet.


und bezüglich (2^3)^4:

Zitat:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt Demo5.exe ist eine Exception der Klasse EOutOfMemory mit der Meldung 'Zu wenig Arbeitsspeicher' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

Zitat:

---------------------------
Demo5
---------------------------
Ungültige Zeigeroperation.
---------------------------
OK
---------------------------

da dreht Delphi aber auch ganz schön an den Fehlermeldungen :shock: (ist beides die "selbe" Exception)

[add]
da war wohl wirklich ein Fehler in TMatheParser.Berechne > Tausche

[gammatester]

Hier das nächste Parser-Feature: 3*-2 liefert -6, das ist zwar ungewöhnlich aber OK. Aber 3*--2 liefert 3*--2! :o Ist zwar auch nicht falsch aber ...

[gammatester]

Diesmal was zur den Konstanten pi10, pi100 und e10. Da
Pi*10^100 = 31415926535897932384626433832795028841971693993751 05820974944592307816406
2862089986280348253421170679.821480865132823066470 93844609550582231725359408128481...
ist, sollten doch die letzten Stellen bei pi10 ...26536 und bei pi100 ...70680 lauten. Analalog e10='27182818285'.

[edit=Luckie]Beitrag formatiert. Mfg, Luckie[/edit]

[himitsu]

zu PI und e ... nein, denn ich hab vorgestern gelernt, daß derartige Zahlen nicht gerundet werden. :mrgreen:

Wiki hat gesagt:

Anm.: Der angegebene Wert ist nicht π auf 100 Nachkommastellen gerundet, sondern es handelt sich um die ersten 100 Stellen der Dezimalentwicklung, d.h., die 100. Nachkommastelle ist eine 9. Gerundet wären die letzten zwei Ziffern 80, nicht 79 (die 101. Stelle lautet auf 8). In der Zahlentheorie wird prinzipiell nicht gerundet, das ist nur bei konkreten physikalischen Messungen und ähnlichen Gebieten der angewandten Mathematik von belang.

3*--2 war ein Fehler in der "istZahl"-Prüfung, welcher die Zahl in den ersten zwei Durchgängen (2 und -2) durchließ, wobei auch --2 entstanden ist, aber bei der Übergabe an die Funktion es als Falsch ansah und somit nicht verarbeitete :oops:

[himitsu]

Hab die Veraltung der Konstanten, Funktionen und Operatoren etwas verbessert (bzw. erstmal Funktionen dafür erstellt)

* nun gibt es 2 Zwischenspeicher (Mem1 und Mem2 ... zum Speichern Button drücken und aufrufen via Konstante)
* und die Konstante "Last", welche das letzte "erfolgreiche" Ergebnis enthält
* die Rechendauer und Zahlengröße steht unterm Berechnenbutton
* im Edit wurde [Enter] zum Berechnen definiert

"1" ins Edit eintragen (man braucht halt erstmal ein "Last", um es zu verwenden)
[enter]
nun "Quadrat(Last)+1" ins Edit eintragen
[enter]
[enter]
[enter]
...

und nun nur noch zusehn, wie sich der Rechner bald zu tote rechnet :nerd:

also mit Hilfe von Demo1 und Demo5 kann man sich nun vermutlich ganz leicht einen netten Ganzzahl-Taschenrechner zusammenbasteln :angel2:


[add]
und ich hatte inzwischen mal die "langsamen" Funktions-Versionen rausgebaut,
dafür gibt es es jetzt bei einigen Funktionen anfangs eine auskommentierte Version

Delphi-Quellcode:

Function TMathe.Name(...
  //Begin
  //  ... langsamer/einfacherer Code
  //End;
  Begin
    ... etwas optierter Code
  End;

[himitsu]

- ein bissl aufgeräumt
- TMathe.Quadratwurzel, TMathe.PotenzModulo und Abhängiges stark beschleunigt
- schnellen TMathe.Quotient2 eingeführt r := a div 2 (Grund für vorherigen Punkt)
- Demo6 erstellt = "Fließkomma"-Parser (alles mit # rechnet noch mit "falscher" Nachkommabehandlung)

Download in #1

[xZise]

Moin!

Ich habe mir dein Code mal angeguckt. An sich ganz ordentlich (wobei ich es selber hasse, wenn "Sonderzeichen" benutzt werden (außer Konstanten) :D ). Aber es ist dein Code also kein Ding.

Aber eine Sache zu Produkt! Im Moment sieht das so aus:

Delphi-Quellcode:

While b <> '' do Begin
  For i := 1 to ZeichenZuZahl[b[Length(b)]] do Result := Summe(Result, a);
  a := a + '0';             // a := Produkt(a, '10');
  Delete(b, Length(b), 1);  // b := Quotient(b, '10');
End;

Könnte man da nicht eine For-Schleife verwenden?

Delphi-Quellcode:

for j := Length(b) downto 1 do
begin
  for i := 1 to ZeichenZuZahl[b[j]] do Result := Summe(Result, a);
  a := a + '0';
end;

So fällt der Delete-Befehl weg. Und man ruft nur noch einmal "Length()" auf, statt wie jetzt 2*<Anzahl Stellen>. Außerdem ist imho eine For-Schleife immer schneller als eine entsprechende While-Schleife.

MfG
xZise

[gammatester]

Leider sind in der neuesten Ausgabe einige Verschlimmbesserungen drin:

1. Nicht mehr D6-kompatibel (xpman ...)

2. Auch D7 und höher gehen (bei mir) nicht:
M7\DCC32 -b Demo6.dpr
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
StringMatheLib.pas(1104)
StringMatheParserFloat.pas(660) Error: Incompatible types
StringMatheParserFloat.pas(919)
Demo6U.pas(5) Fatal: Could not compile used unit 'StringMatheParserFloat.pas'


Habe gestern abend noch einige Features (der alten Vers) gefunden.

Wenn x ein positive Zahl ist:

Code:

PotenzModulo(x,0,0)   -> 1  statt Fehler
PotenzModulo(x,0,1)   -> 1  statt 0
PotenzModulo(x,0,-1)  -> 1  statt 0

Plus1(-1)             -> -0  statt 0
Negieren(0)           -> -0  statt 0
Quotient(-0,-x)       -> -0  statt 0
Produkt(-x,0)         -> -0  statt 0

Übrigens: Ich (und mein Modem) fänden es toll, wenn die immer mehr werdenden Demo-EXE-Files separiert würden zum Runterladen bzw. ein separates nur Source-Zip da wäre.

Gammatester

[himitsu]

Sonderzeichen, Sonderzeichen ... Sonderzeichen? :gruebel:
(hatte mal 'nen Tag lang ain ä in einem Funktionsnamen ... ist schon irgendwie cool :mrgreen: )

jetzt nur noch a := a + '0'; durch das "neue" Produkt10(a, 1); ersetzt und es sieht fast schon professionell aus :stupid:

Zitat:

Außerdem ist imho eine For-Schleife immer schneller als eine entsprechende While-Schleife.

nicht immer, aber da es hier nicht vorrangig um Geschwindigkeit, sondern "Einfachheit" geht, werd ich das jetzt nicht nachmessen und einfach so einbauen :angel:

[add]
das xpman kann man ja beruhigt entfernen :)
hmmm, ich wußte nicht, in wie weit die D2009-.RES incl. Manifest mit älteren Delphis harmoniert, drum hatte ich eine D7-.RES verwendet und halt das XP-Manifest einzeln ... das kann ich ja gern wieder rückgängig machen :)

OK, hab ja auch sowas wie Modem (bin gestern 'ne Weile nur mit GPRS reingekommen :wall: )

-0 :shock: mal sehn was da falsch läuft und eigentlich sollte das - von der Normlisierung entfernt werden :gruebel:

Zitat:

StringMatheLib.pas(1104)
StringMatheParserFloat.pas(660) Error: Incompatible types
StringMatheParserFloat.pas(919)

hmmmm :? , wie sind denn die kompletten Meldungen?
- StringMatheLib.pas(1104) gibt es nicht ... es existieren doch nur 1103 Zeilen
- die 660 ... wundert mich jetztz, daß dieses gestern noch ging :shock: einen String nach "Char" Casten und erfolgreich vergleichen
- 919 ist klar (liegt an 660)

[gammatester]

In Ord(TMatheParserFListe(Liste[i + 1].Operanden)[i3].Operand) wendest Du ord auf einen String. Kann mir eigentlich keine Delphiversion vorstellen, die das erlaubt.

[xZise]

Zitat:

Zitat von himitsu

[...]jetzt nur noch a := a + '0'; durch das "neue" Produkt10(a, 1); ersetzt und es sieht fast schon professionell aus :stupid:

Naja ich weiß nicht :P Weil P10 macht mehr als an a eine 0 dran zuhängen. Weil P10 halt universell ist. Wobei du könntest ja einige "Kernfunktionen" erstellen die privat oder protected sind, die keine Prüfungen durchführen. Also das P10 nur "n Nullen" dran hängt.

Zitat:

Zitat von himitsu

Zitat:

Außerdem ist imho eine For-Schleife immer schneller als eine entsprechende While-Schleife.

nicht immer, aber da es hier nicht vorrangig um Geschwindigkeit, sondern "Einfachheit" geht, werd ich das jetzt nicht nachmessen und einfach so einbauen :angel:

Zitat:

Zitat von himitsu

[...]und ich hatte inzwischen mal die "langsamen" Funktions-Versionen rausgebaut,[...]

Aber ganz von der Hand zu weisen ist das Bestreben nach schnelleren Code ja auch nicht :D

MfG
xZise

[himitsu]

Zitat:

Zitat von xZise

Naja ich weiß nicht :P Weil P10 macht mehr als an a eine 0 dran zuhängen. Weil P10 halt universell ist.

ein sinnvoller Grund für P10 ist, daß der "Rechenweg" dann "versändlicher" wäre,
(es ist ja eigentlich ein *10 und im Code sieht es nach +0 aus)
nja und daß es sozusagen Insert, statt Concat (+) nutzt :stupid:

weißt du, was eine langsame Multiplikation ist?

Delphi-Quellcode:

// für c := a * b;
c := 0;
while b > 0 do
begin
  c := c + a;
  b := b - 1;
end;

so ähnlich sahen Produkt_langsam, QuotientModulo_langsam und Potenz_langsam aus :angel2:

Zitat:

Zitat von xZise

Aber ganz von der Hand zu weisen ist das Bestreben nach schnelleren Code ja auch nicht :D

ich hatte anfangs ja die "langsamen" Versionen noch als zusätzliche Extraversionen drin
und nun existieren sie nur noch virtuell als Kommantare

Zitat:

Zitat von gammatester

In Ord(TMatheParserFListe(Liste[i + 1].Operanden)[i3].Operand) wendest Du ord auf einen String. Kann mir eigentlich keine Delphiversion vorstellen, die das erlaubt.

String ist ein Zeiger und per Ord würde man wohl den "Pointer" in einen Integer casten :nerd:


sooo, nun müßte nur noch irgendwer alle möglichen restlichen Testfälle zusammenstellen :freak:

Delphi-Quellcode:

// Function StringMatheLib.UnitTest:
With TMathe.Create do
  Try
    _Test(Normalisieren(  '123') =  '123');
    _Test(Normalisieren( '+123') =  '123');
    _Test(Normalisieren( '-123') = '-123');
    _Test(Normalisieren('--123') =  '123');
    Try
      _Test(Normalisieren('a123') <> '123');
      _Test(False);
    Except
    End;
    _Test(Formatieren('+1234567', False, False) = '1234567');
    _Test(Formatieren('-1234567', False, False) = '-1234567');
    _Test(Formatieren('+1234567', True,  False) = '1.234.567');
    _Test(Formatieren('-1234567', True,  False) = '-1.234.567');
    _Test(Formatieren('+1234567', True,  True)  = '+1.234.567');
    _Test(Formatieren('-1234567', True,  True)  = '-1.234.567');
    _Test(Formatieren('+1234567', True,  False, 15) = '0000001.234.567');
    _Test(Formatieren('+1234567', True,  True,  15) = '+000001.234.567');
    _Test(Formatieren('-1234567', True,  False, 15) = '-000001.234.567');
    _Test(Formatieren('-1234567', True,  True,  15) = '-000001.234.567');
    //
    //Function  Vergleich       (a, b: String): TValueRelationship;       Overload;
    //Function  Vergleich       (a, b: String; Art: TVergleich): Boolean; Overload;
    //Function  istPositiv      (a:    String): Boolean;
    //Function  istNegativ      (a:    String): Boolean;
    ...

[gammatester]

Ohne nerven zu wollen, aber in beiden Zips ist die alte Version von StringMatheParser.pas (29.719 01.07.09 0:22) und der Fehler tritt bei mir immer noch auf. Da die Exes von heute 10Uhr sind, mußt Du sie doch irgendwie kompiliert haben!? Willst Du ernsthaft sagen, daß Dein Delphi die StringMatheParser aus den Zips ohne Fehler übersetzt?

[himitsu]

hab grad die Browsercache geleert, alles selber runtergeladen und vergleichen lassen ...
oben ist die aktuelle Version.

hatte es getestet und kompilieren lassen und danach gepackt und hochgeladen.

hab's auch grad nochmal (mit der Demo6) unter Delphi 7 versucht, und bis auf einige Sachen in den .DFMs, welche man ignorieren kann und dem Application.MainFormOnTaskbar:=True; in der .DPR lief es sofort (der Debugger bemängelt nur, zu recht, eine Exception im UnitTest, welche absichtlich ausgelößt und per Try-Except abgefangen wird)

[gammatester]

Habe gerade von einem Kollegen erfahren, daß Uni-Code D2009 den Parser mit dem kritschen Teil zwar übersetzt, aber alle Funktion mit mehr als einem Argument scheinen nicht mehr zu funktioniern. (Wäre nach Deinem "Argument" auch kein Wunder, den der Ord(Pointer) wir wohl nie ',' oder so sein)

Edit: Seine Prä-2009-Versionen erzeugen den gleichen Fehler wie bei mir

[himitsu]

Zitat:

[01.07.2009 14²° v1.4]
- einige Dateien von UTF-8 nach Ansi konvertiert
- wegen #72 Version erhöht und alles neu kompiliert bzw. hochgeladen
- weitere Konstanten in die Parser eingefügt

wie gesagt, mit D7 hatte ich keine großen Probleme
und in D2009 lief es sowieso

werd' gleich nochma TDE versuchen


wobei Ord(Pointer) eigentlich schon seit 10°° behoben sein sollte :gruebel:
ich probier das mit den Parametern aber gleich nochmal aus.
[edit] ok, da stimmt wirklich was nicht ... mal sehn was da los ist [/edit]
[edit2] bin blöd, hab es nur in einem der zwei Parser geändert :wall: [/edit2]


und ich hoff die Kompilerschalter, bei den Konstanten, funktionieren (in D7 ging es zumindestens),
damit werden die Unicode-Versionen, wie Φ und π ausgeschlossen.

[add]
OK, erstmal hatte ich das Ord(Pointer)-Problem einmal übersehn

und dann hatte ich doch vor Kurzem die Verwaltung der Operatoren, Konstanten und Funktionen überarbeitet und mit neuen Funktionen versehn, wie z.B. SetzeOperator.

Nun wird intern z.B. das Komma nicht extra behandelt, sondern einfach zusammen mit den anderen Operatoren.

Delphi-Quellcode:

// aus'm Konstruktor
SetzeOperator('+', opDavor,      -1, nil);
SetzeOperator('-', opDavor,      -1, nil);
SetzeOperator(',', opDazwischen, -1, nil);
SetzeOperator(';', opDazwischen, -1, nil);

Das ging auch anfangs gut, also wo ich die Werte noch direkt in das Array eingetragen hatte.
Nun hat die SetzeOperator-Funktion die eigenschaft, daß sie einen Eintrag löscht, wenn keine Funktion (nil) übergeben wird und demnach nicht die "internen" Verwaltungs-Operatoren anlegte ... die fehlten also, wodurch eben auch kein Komma mehr erkannt wurde :wall:

Download in #1 aktuelle Version v1.4 14:30

[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. :stupid:

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 :shock:


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)

[himitsu]

ChangeLog

[01.07.2009 20°° v1.5]
- Rechenfehler aus #67 behoben

Delphi-Quellcode:

Plus1(-1)             -> -0  statt 0

dieses Problem tritt hier nicht auf
(wie vermutzt, wird es durch die "Normalisierung" behandelt)

eventuell lag es ja an einem Fehler der Normalisierung, welchen ich vorhin schon behoben hatten :gruebel:

Delphi-Quellcode:

PotenzModulo(x,0,0)   -> 1  statt Fehler
PotenzModulo(x,0,1)   -> 1  statt 0
PotenzModulo(x,0,-1)  -> 1  statt 0

diese Sonderfälle werden jetzt geprüft und behandelt

Delphi-Quellcode:

Negieren(0)           -> -0  statt 0

Sonderfall 0 wird nun beachtet und nicht behandelt

Delphi-Quellcode:

Quotient(-0,-x)       -> -0  statt 0
Produkt(-x,0)         -> -0  statt 0

war auf den Fehler in Negieren zurückzuführen


PS: laß dir mal im Debugger das e anzeigen ... vonwegen -0 gäbe es nicht :lol:

Delphi-Quellcode:

e := 0;
PByte(@e)[9] := $80;
if e = 0 then ;

[GPRSNerd]

Hallo himitsu,

bei deiner Demo1 werden jetzt bei allen Ausgaben, die keine Zahlen sind, Fehlermeldungen geworfen, a la "ungültige Zahl ""a ist größer als b"".
Kann man das irgendwie abschalten oder habe ich was übersehen?

Gruß,
Stefan

[himitsu]

OK, das hatte ich nicht beachtet :oops:

Ich schau gleich mal, aber ich hab 'ne Befürchtung :nerd:

Nach der Berechnung wird doch die Dezimalstellenanzahl ermittelt und mit angezeigt.
Und ich denk mit jetzt einfach mal, daß dabei die "neue" Exception in der Zahlenprüfung zuschlägt -.-°
(bis vor Kurzem wurden in der Normalisierung einfach stillschweigend alle ungültigen Zeichen gelöscht und nun gibt's halt 'ne Exception)

ich glaub statt die Demo umzuschreiben, werd ich die Zählfunktion umschreiben und dort die Exception abfangen und dann "0" zurückgeben.

Oder sollte ich lieber "-1" machen :?: (gültige Zahlen haben immer mindestens eine Stelle)


[add]
hab doch die -1 genommen

ChangeLog

[03.07.2009 12°° v1.5]
- Dezimalstellenfunktion mit Fehlerprüfung versehen und die Anzeige der Stellen in den Demos etwas umgestellt[/size]

[qwertz543221]

entschuldige, aber bei welchem beitrag finde ich die aktuelle version deines meisterwerks