|
Deine Ausführungen bedeuten Thomas hat recht - es wird auf jeder Seite der Gleichung vereinfacht bis Mathematica auf einen unbestimmten Ausdruck trifft, dann liefert TrueQ "defaultmäßig" False. Was ich nicht verstehe ist aber: Beispiel: 1 x=. y=. TrueQ[x/y==x/y] Liefert True Beispiel: 2 x=. y=. TrueQ[x/y==y/x] Liefert False Wenn MMA die Funktionen schlicht auf beiden Seiten vereinfacht (infinite evaluation loop) und quasi die Vereinfachung nach Deinen Ausführungen verglichen werden und für Beispiel 1. True ergeben, wieso dann nicht auch für Beispiel 2? Schließlich sind die Funktionen exakt gleich, auch die Parameter sind gleich, nur die Position der Parameter einer Seite ist unterschiedlich ( y/x satt x/y) Würde meine Variante stimmen, x und y element R durchlaufen numerische Teilbereiche (ähnlich wie bei Plot) , so ergäbe Beispiel 1 bei mir True, weil die komplette Teilbereichsevaluierung True ergibt. Denn für alle x und alle y ist die Funktion gleich True. Meine Variante ergibt für Beispiel 2 False, weil die Funktion beim Durchlauf der numerischen Teilbereiche für x ungleich y auf falsche Auswertungen trifft, während für x gleich y die Auswertungen True ergeben. Da aber Teile False sind, ist der ganze Ausdruck False. Analogie: Die Funktion Plot - Plot durchläuft numerische Teilbereiche einer Funktion, ist die Funktion überall definiert zeichnet Plot die Funktion (was True entspricht), stößt Plot auf einen nicht definierten Bereich, gibt es eine Fehlermeldung aus (was False entspricht). Auch hier reicht eine einzige nicht definierte Stelle, um die Funktion nicht auszugeben (somit False anzuzeigen). Mit freundlichen Grüßen [André El-Ama] -----Original Message----- From: Jens-Peer Kuska [mailto:kuska@XXXXXXX.de] Sent: Tuesday, February 15, 2005 4:34 PM To: Andre El-Ama; DMUG Subject: Re: Re(Woysch): Frage zur Aequivalenz von modifizierten DiracDelta-Funktionen Hallo, wir wissen schon was Mathematica intern auswertet, es wertet den Ausdruck nämlich solange aus, bis es keine Regeln mehr findet die es anwenden kann (infinite evaluation loop). Da x/y==x/y nun mal der gleiche Ausdruck ist, sind es die Regeln von Equal[], die sich zu True vereinfachen. Das muß auch so sein, sonst wird aus x/y+x/y nie 2 x/y. Die Vereinfachungsorgie hört nur auf, wenn Mathematica den Ausdruck auf jeder Seite in die "kanonische Form" (OrderedQ[]) gebracht hat. Dabei werden aber nur die build-in Regeln verwendet. Deshalb ist 1/(x*(1 + y/x)) == 1/(x + y) //TrueQ auch False, während 1/(x*(1 + y/x)) == 1/(x + y) // ExpandAll // TrueQ True ergibt, denn es wäre sehr ärgerlich wenn Mathematica ständig ExpandAl[] oder FullSimplify[] aufrufen würde. Dadurch würde alles ganz ganz langsam werden und wegen des zusätzlichen Speicherbedarfs von Simplify/FullSimplify[] könnte man nicht mehr damit arbeiten. Die standard build-in Regeln ordnen den Ausdruck nur um, letztlich um zu erkennen, ob jemand 2*a*5*Sin[2Pi x]*4 eingegeben hat, damit daraus 40*a*Sin[2Pi*x] werden kann und aus 2 x+ x + y + c +x eben c+ y + 4 x. Nach derm ersten Ordnen werden die Regeln benutzt die Zahlen zusammen fassen, c_+c_ :> 2 c und c_*c_:> c^2 ..., dann wird wieder geordnet, zusammengefaßt,... bis sich nichts mehr ändert. Alles was darüber hinaus geht, wird nicht erkannt. Fügt man die Regel zum Ausmultiplizieren zu den internen Regeln hinzu, z.B. mit Block[{Times}, a_*b_Plus := a*# & /@ b; 1/(x*(1 + y/x)) == 1/(x + y) ] kommt auch wieder True heraus und TrueQ[] ist auch True. Gruß Jens ----- Original Message ----- From: "Andre El-Ama" <Andre@XXXXXXX.de> To: "DMUG" <demug@XXXXXXX.ch> Sent: Tuesday, February 15, 2005 1:55 PM Subject: RE: Re(Woysch): Frage zur Aequivalenz von modifizierten DiracDelta-Funktionen > Hallo Jens-Peer, > > Im Grunde meinten wir (Thomas und ich) ja dasselbe, nämlich das die TrueQ > einwandfrei Funktioniert. > > Thomas führt das auf den einen Defaultwert zurück, sobald die Funktion > nicht > ausgewertet werden kann (unbestimmt ist). > > Ich glaube das TrueQ für x Werte einsetzt, (nämlich x element R) > zumindest > für Teilbereiche um eine Entscheidung zu treffen. > > Thomas Variante hat für mich was von einer "Glaskugel": MMA entscheidet > irgendwie, die Funktion ist unbestimmt. > > Leider wissen wir beide nicht exakt, wie MMA TrueQ intern überhaupt > auswertet > > DiracDelta ist zugegeben ein dummes Beispiel, das kam aber weder von > Thomas > noch von mir. > > Ich würde > > x=. > y=. > TrueQ[x/y==x/y] > False > > bevorzugen. > > Mit freundlichen Grüßen > > [André El-Ama] > > > -----Original Message----- > From: Jens-Peer Kuska [mailto:kuska@XXXXXXX.de] > Sent: Tuesday, February 15, 2005 12:38 PM > To: Thomas Hahn; Andre El-Ama > Cc: DMUG > Subject: Re: Re(Woysch): Frage zur Aequivalenz von modifizierten > DiracDelta-Funktionen > > Hallo, > > das ist ja HAARSTRÄUBEND ! > > DiracDelta[] ist eine *Distribution*, das heißt sie ist nur in Ausdrücken > > Integrate[f[x]*DiracDelta[x],{x,-Infinity,Infinity}] > > erlaubt und sinnvoll. Und auch nicht für beliebige Funktionen f[] > sondern nur für eine bestimmte Klasse z.B den Raum der (quadratisch) > integrablen Funktionen. > Eine nackte DiracDelta[] Funktion kann es nicht > geben. Es gibt immer nur Integrale in denen eine solche Funktion steht. > Um genau zu sein, ist DiracDelta[] diejenige Distribution, die > > Integrate[f[x]*DiracDelta[x],{x,-Infinity,Infinity}] -> f[0] > > zuordnet. Es ist also höchst sinnlos darüber zu spekulieren > ob DiracDelta[s]==DiracDelta[5 s] > ist oder nicht, denn es ist nur ein Ausdruck > > Integrate[f[x]*DiracDelta[x],{x,-Infinity,Infinity}]== > Integrate[f[x]*DiracDelta[ 5 x],{x,-Infinity,Infinity}] > > überhaupt definiert, und der ist natürlich > > f[0]==f[0]/s > > ob das True oder False ist kann man so nicht sagen, TrueQ[] sollte > aber auf jeden Fall False ergeben ... > Natürlich ist es schlimm, wenn so etwas überhaupt ausgewertet wird, > denn der Ausdruck DiracDelta[s]==DiracDelta[5 s] ist sinnlos, und > das FullSimplify[] das auch noch zu True vereinfacht ist bedauerlich, > weil eigentlich Indeterminate heraus kommen sollte. > Aber vermutlich ist es kein Bug, wenn bei der Eingabe von Unsinn auch > Unsinn > rauskommt ... > > Es ist eine beliebte Ungenauigkeit einfach das Integral und die Funktion > f[] wegzulassen und die Daumen zu drücken, das alle Integrale > konvergieren, das hat aber nix mit Mathematik zu tun, > sonder mit (Schreib-)Faulheit, genauso, > wie man in Differentialgleichungen gern die > Funktionsargumente weg läßt. > > Aus einer gewissen Laxheit/Faulheit heraus aber zu schlußfolgern, das > > DiracDelta[s]==DiracDelta[5 s] > > überhaupt etwas sinnvolles ergibt ist recht vermessen. Selbst > mit der üblichen "auch ganz doofe Studenten sollen das > verstehen"-Erklärung: > "Eine Diracsche Delta-Funktion ist überall null außer dort wo das Argument > verschwindet, dort ist sie unendlich." > ist klar das man "Unendlich" und "Unendlich/5" wohl eher nicht > vergleichen kann. > > Jedenfalls hat es die Anzahl der Postings in der DMUG dramatisch erhöht > > > Gruß > Jens > > > > > ----- Original Message ----- > From: "Thomas Hahn" <hahn@XXXXXXX.de> > To: "Andre El-Ama" <Andre@XXXXXXX.de> > Cc: "DMUG" <demug@XXXXXXX.ch> > Sent: Monday, February 14, 2005 3:45 PM > Subject: Re: Re(Woysch): Frage zur Aequivalenz von modifizierten > DiracDelta-Funktionen > > >>> >Na und, wo ist da ein Problem? >>> > x^2 == x^2 ist schon ja von sich aus True. >>> >>> Genau, "von sich aus True" entspricht in diesem Fall "x element R" >> >> Vielleicht steh ich gerade auf der Leitung, aber x^2 == x^2 >> ist auch im Komplexen True. >> >>> >Mathematica Basics: >>> >Alle ...Q-Funktionen liefern False, wenn das Ergebnis nicht >>> >bestimmt werden kann. >>> >>> schon mal falsch, denn es gilt nicht für Funktionen die "von sich aus >>> True" >>> sind. >> >> Natürlich ist TrueQ[True] True, d.h. daß TrueQ[x^2 == x^2] >> True ergibt, bestätigt in diesem Fall doch nur, daß x^2 == x^2 >> schon True ist. >> >> Das Ausgangsproblem war doch, daß >> >> TrueQ[ DiracDelta[s] == DiracDelta[s]/5 ] >> >> False ergibt, und da behaupte ich: das ist völlig korrekt, denn >> DiracDelta[s] == DiracDelta[s]/5 kann ohne zusätzliche Informationen >> eben nicht eindeutig als True oder False ausgewertet werden, und >> dann gibt TrueQ seinen Default, nämlich False zurück. Es ist >> ein Feature und kein Bug der ...Q-Funktionen, daß sie im >> Zweifelsfalle False zurückliefern. >> >>> >Im Übrigen habe ich mir das mit den ...Q-Funktionen nicht >>> >selbst ausgedacht, sondern das steht im Mma-Buch (müßte suchen, >>> >wo genau). >>> Ja, dauert "echt" lange im MMA-Buch unter "TrueQ" nachzusehen! >> >> Weil es nicht bei TrueQ steht, sondern in Section 2.3.5: >> >> An important feature of all the Mathematica property-testing >> functions whose names end in Q is that they always return False if they >> cannot determine whether the expression you give has a particular >> property. >> >> >> Schöne Grüße, >> >> Thomas >> >> >> > > |