Autor |
Beitrag |
prote
Beiträge: 17
|
Verfasst: Do 07.04.05 21:52
super, sieht sehr interessant aus, werde ich mir mal bei Gelegenheit zu Gemüte führen
Allerdings hast Du'nen Fehler drin:
delfiphan hat folgendes geschrieben: | - evalMath behandelt als einziger verschachtelte Hoch-Operatoren korrekt: -2^-3^-4 = -4096 |
das wäre nach den allseits bekannten Regeln 4096 und zwar ohne "-" und selbst das wäre nicht korrekt, weil man bei der Schreibweise erst -3^(-4) rechnen müßte und danach erst das Ergebnis als Potenz von -2 ... siehe hierzu auch ein interessanter Wachstumsalgo mit "Hyper-Potenzen": de.wikipedia.org/wiki/Ackermannfunktion
|
|
uall@ogc
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: Do 07.04.05 22:53
@delfiphan
um dein problem zu lösen mussu alle funktionen mit parameter einfach als stdcall; markieren, dadurch werden die parameter auf den stack gepushed und die funktion bekommt die richtigen
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| Procedure Funktion(const S : String); type AnyProcedureX = procedure; Procedure InternalFunction1; begin ShowMessage(S); end; Procedure InternalFunction2(AnyProcedure: AnyProcedureX); stdcall; begin AnyProcedure; end; begin InternalFunction2(@InternalFunction1); end; |
funktioniert einwandfrei wärend hingegen
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| procedure Funktion(const S : String); type AnyProcedureX = procedure; Procedure InternalFunction1; begin ShowMessage(S); end; Procedure InternalFunction2(AnyProcedure: AnyProcedureX); begin AnyProcedure; end; begin InternalFunction2(@InternalFunction1); end; |
crashed, wo du meintest es gibt probleme
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
delfiphan
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Do 07.04.05 22:57
@prote: Der Text "-2^-3^-4 = -4096" stammt auch noch von der uralten Vor-Version So falsch ist es aber nicht: Es wurde dort einfach standardmässig links geklammert (das Minus-Zeichen stimmt übrigens: -x^2 = -(x^2)!). In der jetzigen Version wird die Hochoperation aber mathematisch korrekt rechts geklammert. (PS: Ob man jetzt "^" links oder rechts klammert, da scheinen sich auch kommerzielle Softwarefirmen nicht einig zu sein (vgl. Texas Instruments, Maple, Mathematica))
@uall: Danke ich werd den Parser aber mal so lassen. Wegen den paar Zeilen, die ich so sparen würde, programmier ich das jetzt nicht mehr um. :\ Aber danke für die Info
Information: Aktueller Download siehe weiter oben.
|
|
Tilo
Beiträge: 1098
Erhaltene Danke: 13
Win7 geg. WInXP oder sogar Win98
Rad2007
|
Verfasst: Sa 28.05.05 19:55
Mal als Vergleich: Mein Taschenrechner rechnet -2^-3^-4=-2^(-3^-4)=-0,991...
|
|
.Chef
Beiträge: 1112
|
Verfasst: Sa 28.05.05 22:41
delfiphan hat folgendes geschrieben: | - evalMath behandelt als einziger verschachtelte Hoch-Operatoren korrekt: -2^-3^-4 = -4096
-> TMathParser: Gibt "-6" zurück
|
Weil ich das gerade sehe: Mein Parser behandelt das sehr wohl, setzt allerdings die mathematisch korrekte Schreibweise -2^(-3)^(-4) voraus, also die Vorzeichen in Klammern. Diese "Ausnahmen" hab ich nicht mit berücksichigt.
Außerdem, wenn ich mich recht erinnere , beinhaltet mein Parser einen Syntaxcheck, d.h. fehlerhafte Stellen werden erkannt und die Ausführung abgebrochen. Es fehlt lediglich die Ausgabe. Es wäre aber ein leichtes - ich hatte nur keine Lust - den Quelltext an den entsprechenden Stellen um eine Exception und Fehlerstelle zu erweitern.
_________________ Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Sa 04.06.05 21:43
da ist neue konkurrenz aufgetaucht: www.delphipraxis.net...ic54895,0,asc,0.html
ist deiner schneller ?
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
delfiphan
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Sa 04.06.05 22:32
Ganz interessant. Werd ich gleich mal ausprobieren!
Also so wie's aussieht ist die Anwendung bei mir recht viel einfacher. Die Geschwindigkeit kann ich nicht direkt vergleichen; Variablen werden bei ihm glaub ich nicht direkt reinkompiliert; oder doch? Auf jeden Fall scheint meiner so (siehe unten) ca. 10x schneller zu sein. Und das gegen meinen Interface-Wrapper, welcher ja langsamer ist, als meine nackte Variante. Aber vermutlich geht's bei ihm auch noch schneller, ich weiss nur nicht wie.
tyParser:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| var sinc: IExpr1V; begin sinc := compileStr1V('x+2*x',['x']); D := 0; repeat sinc.Eval(D); D := D + 1 / 1000000; until D > 1; end; |
Konkurrenz:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| var Parser: TExCQParser; begin Parser := TExCQParser.Create; Parser.RegisterVariable('x',false); Parser.Parse('x+2*x'); D := 0; repeat Parser.SetVariable('x',[D]); Parser.Solve; D := D + 1 / 1000000; until D > 1; Parser.Free; |
Er hat vor allem ca. 7 Units und ich hab eine. Bei ihm ist es aber auch möglich, externe Funktionen zu definieren. Bei mir kann man nur externe Variablen definieren.
Mein Parser reiht schlussendlich einfach ein FPU-Befehl nach dem nächsten hin, von dem her gesehen kann es keinen Parser/Evaluator geben, der um Faktoren schneller ist. Was mein Parser nicht tut ist, einen Ausdruck zuerst zu vereinfachen. Er wird genau so übersetzt wie er eingegeben wird. Da ist also noch Verbesserungspotential.
Ich finde aber vor allem, dass die einfache Anwendung bei mir vor allem von grossem Nutzen ist. Allfällige Syntaxfehler werden bei mir nicht per Exceptions zurückgegeben, was ich irgendwie auch sympathischer finde (aber das ist Geschmackssache).
Und: Bei ihm ergibt "-2^2" halt 4 (statt -4). Und "-(1/2)" oder auch "2*(-1)" ergibt Access Violation. Und solche Details. Bei mir kann es fast gar keine Access Violations geben. Ist nicht OOP und es wird auch fast nirgends irgendwelchen Speicher alloziert..
|
|
F34r0fTh3D4rk
Beiträge: 5284
Erhaltene Danke: 27
Win Vista (32), Win 7 (64)
Eclipse, SciTE, Lazarus
|
Verfasst: Do 15.09.05 15:53
schaffst du es, deinen parser delphi3 konform zu machen ? dynamische arrays, overloads etc bereiten momentan probleme
vielleicht auch n einfaches beispiel, wenn ich zb nur sowas hier ausrechnen möchte:
ok habs so gemacht:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| procedure TForm1.Button1Click(Sender: TObject);
Var sinc: IExpr1V; begin sinc := compileStr1V(edit1.text); edit2.text := floattostr(sinc.Eval(1.0)); end; |
schöner parser, gefällt mir
|
|
delfiphan
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Do 15.09.05 19:47
Hmm der Parser auf Delphi3? Ich hab nicht mal Delphi3 ...
[info]Ach ja, irgendwo hatte es noch einen Bug oder zwei. Ich glaub wenn ein Variablenname mit klein e beginnt oder sowas gibt's manchmal Probleme. Der Bug ist im SimpleCalculator korrigiert; jedoch ist dort der Parser verändert worden, damit er mit komplexen Zahlen arbeitet. Der Compiler ist dort auch nicht mehr dabei. [/info]
|
|
F34r0fTh3D4rk
Beiträge: 5284
Erhaltene Danke: 27
Win Vista (32), Win 7 (64)
Eclipse, SciTE, Lazarus
|
Verfasst: Do 15.09.05 20:15
ja die dynamischen arrays lassen sich ja abändern und die overloads umbenennen, wenn ich lust habe, bringe ich den mal bei delphi3 zum laufen.
|
|
Midori
Hält's aus hier
Beiträge: 11
|
Verfasst: Do 20.10.05 17:27
Wau das klingt ja mal sehr interessant und genau das was ich grad suche.
Wäre es dir möglich das CBuilder5 kompatibel zu machen?
Er meldet leider:
[Pascal Fehler] tyParser.pas(1175): Undefinierter Bezeichner: 'NaN'
[Pascal Fehler] tyParser.pas(1271): Undefinierter Bezeichner: 'sign'
[Pascal Fehler] tyParser.pas(1272): Undefinierter Bezeichner: 'cot'
[Pascal Fehler] tyParser.pas(1276): Undefinierter Bezeichner: 'arccot'
*traurig*
Sind scheinbar nur Konstanten und einfache Funktionen.
Wäre super wenn es so umschreiben könntest, das diese in deiner Klasse
integriert sind
|
|
BenBE
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Do 20.10.05 18:09
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Midori
Hält's aus hier
Beiträge: 11
|
Verfasst: Do 20.10.05 20:50
Ok habs hinbekommen, aber wie das ganze unter CBuilder zum laufen zu bekommen ist habe ich noch net verstanden
SinC := CompileExpr(ParseExpr('sin(x)/x',['x']),tyPass1V);
ExprFunc1V SinC = CompileExpr(ParseExpr("sin(x)/x",OPENARRAY(TVarRec,("x"))),tyPass1V);
ExprFunc1V SinC = CompileExpr(ParseExpr("sin(x)/x",&TVarRec("x")),tyPass1V);
Mit dem ['x'] habe ich meine Probleme. Was ist das und wie muss man es in CBuilder angeben? Falls jemand ein kleines komplettes Beispiel hat wäre echt nett
|
|
FinalFantasy
Beiträge: 127
Windows XP
Delphi 5 Professional, Visual Studio 7 .NET (C#)
|
Verfasst: Fr 04.11.05 14:22
Wie kriege ich die das ganze in eine DLL um sie aus C# aufrufen zu können?
Klassen sind ja in DLLs nicht erlaubt.
(Delphi 5)
|
|
delfiphan
Beiträge: 2684
Erhaltene Danke: 32
|
Verfasst: Fr 04.11.05 22:52
Unter den Beispielen hat's einige, die ohne Klassen funktionieren. Die kannst du exportieren, jedoch weiss ich nicht, ob das mit dem array of const unter C# funktioniert...
|
|
Jakob Schöttl
Beiträge: 929
Erhaltene Danke: 1
Delphi 7 Professional
|
Verfasst: Do 22.06.06 17:17
Wahnsinn! Die genaue Fehlerbeschreibung...
Bloß mit zu großen Zahln hat er noch ein problem: "Invalid Float point operation."
eine englische fehlermeldung. Vllt hast du das vergessen.
|
|