Hi Jens,
Auch ich bin ein großer MMA Fan, doch manchmal kommen mir halt Zweifel.
Der normale Programmierer (sowohl MMA Programmierer als auch alle
anderen) wünscht sich doch ein Konstrukt welches für Lokalität ohne side
effects sorgt. In allen "üblichen" Progsprachen sind das nun mal
Funktionen mit lokalen Variable.
In MMA so dachte ich bisher sind dafür die Module[] Konstrukte zuständig.
Siehe dazu die MMA Hilfe:
Module[{x,y,...},expr]
specifies that occurrences of the symbols x, y, ... in expr
should be treated as local.
genau das: "should be treated as local" wird offensichtlich nicht immer
erfüllt.
das MMA seine localen Symbole bei jedem Aufruf neu mit x$nnn benennt ist
ja schön und gut, warum tut es das nicht auch für die Symbole welch auf
der rhs Seite einer Rule[] vorkommen ?
Es ist schon klar das MMA sein Verhalten nicht nach demokratischen
Regeln bestimmt.
Somit hilft es nicht wenn *Ich* mir ein gewisses Verhalten wünsche,
genauso wenig wie es hilft wenn sich *99.9%* der user selbiges Verhalten
wünschen.
es sind nicht nur *99.9%* der user die sich dieses Verhalten wünschen,
sogar der Syntaxhighlighter von MMA höchst persönlich scheint sich das
zu wünschen:
(*5*)Module[{x, y}, {a, b} /. {x_, y_} -> {y, x}]
x_, y_, x, y alle hellgrün !!!!!!!
Du selber schreibst ja: "Module[] sind etwas kranke Konstrukte".
Wenn nun MMA ein Verhalten zeigt das *99.9%* als "unvorteilhaft"
bezeichnen, so wird diese Verhalten schlicht und ergreifend von den
usern "unerwünscht" sein.
Bekanntlich liegen zwischen Genie und Wahnsinn unendlich viele
Schattierungen wahrscheinlich kann ich dir deshalb nicht folgen warum
man in einer Rule[] nur als Genie ein Pattern[] verwenden sollte, ohne
Pattern macht ein Rule[] doch nur in wenigen Fällen wirklichen Nutzen.
mit nicht ganz so genialen Grüssen
Robert
Jens-Peer Kuska schrieb:
Hallo,
was heisst bitte "funktioniert nicht" ? Es macht nicht das was *Du*
gerne willst.
Das heisst nicht dass es "nicht funktioniert" sondern nur dass Du
etwas falsch gemacht hast.
Module[] sind etwas kranke Konstrukte, weil Sie eine lexikalische
Variablenreferenz implementieren
die Mathematica eigentlich nicht hat. Damit das klappt werden bei
jedem Module[] Aufruf die
Variablen umbenannt beim ersten mal wird aus
Module[{x, y}, {a, b} /. {x_, y_} -> {y, x}]
also Block[{x$1,y$2}, {a,b} /. {x$1_,y$1_}-> ???]
bei zweiten mal
Block[{x$3,y$4}, {a,b} /. {x$3_,y$4_}-> ???]
beim dritten mal
Block[{x$5,y$6}, {a,b} /. {x$5_,y$6_}-> ???]
und so weiter und weiter. Die Fragezeichen habe ich da hin gemacht
weil es an der Stelle nicht eindeutig ist, was denn wohl gemeint ist,
schiesslich stand im Original Module[{x, y}, {a, b} /. {x_, y_} -> {y,
x}]
ist also das umbenannte "x" aus dem Module[] gemeint also
Block[{x$1,y$2}, {a,b} /. {x$1_,y$1_}-> {y$2,x$1}]
oder aber das Globale x
Block[{x$1,y$2}, {a,b} /. {x$1_,y$1_}-> {y,x}]
Die sind beide gleich gut und um die Mehrdeutigkeit aufzuloesen hat man
Block[{x$1,y$2}, {a,b} /. {x$1_,y$1_}-> {y,x}]
genommen. Da gibt es nix zu erklaeren, das ist so (!), genauso wir
Sqrt[4] eine 2 ergibt und keine -2.
Ansonsten ist jeder, der Rule[] mit einem Pattern[] verwendet entweder
ein Genie oder ein kompletter Idiot. Meiner Erfahrung nach, sind die
Genies sehr, *sehr*, SEHR selten. Erklaerungen sind in beiden Faellen
unmoeglich/unnoetig, dem Idioten kann man
nichts erklaeren, dem Genie braucht man nichts erklaeren. Es besteht
daher auch kein Grund nach einer Erklaerung zu suchen.
Gruss
Jens
Robert Nowak wrote:
Hallo Udo,
die Farbspiele habe ich mir auch angeschaut.
(*4*)Block[{x, y}, {a, b} /. {x_, y_} -> {y, x}]
x y überall dunkelgrün und "funktioniert"
(*5*)Module[{x, y}, {a, b} /. {x_, y_} -> {y, x}]
x y überall hellgrün und "funktioniert nicht"
Das bringt einen also nicht wirklich weiter.
Insbesondere das Fall 5 verhalten kann keinem MMA nicht user und auch
den meistem MMA schon usern plausibel erklärt werden.
meiner bescheidenden Meinung nach ein Fehlverhalten.
l.g. Robert
Udo und Susanne Krause schrieb:
Hallo Robert,
in der mma hilfe steht das patterns als lokale symbole behandelt
werden:
tutorial/VariablesInPureFunctionsAndRules
"
Mathematica has several "scoping constructs" in which certain names
are treated as local. When you mix these constructs in any way,
Mathematicadoes appropriate renamings to avoid conflicts.
"
kurz darauf steht im selben Tutorial (nach Out[17])
When you apply a rule such as f[x_]->rhs, or use adefinition such
as f[x_]:=rhs, Mathematica implicitlyhas to substitute for x
everywhere in the expression rhs.It effectively does this using the
/. operator. As a result,such substitution does not respect scoping
constructs.However, when the insides of a scoping construct are
modifiedby the substitution, the other variables in the scoping
constructare renamed.
Wenn man die Schriftfarben auf einem Farbdisplay anschaut,
dann sieht man schon beim Tippen, dass gleich etwas
nichttriviales passieren wird:
In[1]:= x = z;
(* x ist schwarz, z ist blau *)
(*2*) {a, b} /. {x_, y_} :> {y, x}
(* a, b blau, x_, y_, x, y grün *)
(*3*) {a, b} /. {x_, y_} -> {y, x}
(* a, b, y blau, x_, y_ grün, x schwarz (!) *)
Das Syntax Coloring (Edit->Preferences->Appearance) färbt
lokale Variable, Funktionsargumente und Patternnamen
grün (und Face italic), unbekannte Grössen blau, etwa
In[2]:= Fatzkerade[]
wird blau und NumberQ schwarz:
In[3]:= NumberQ[2]
Das x erscheint bei Rule[] schwarz, das y blau,
der Parser betrachtet diese beiden, x und y, schon
nicht als Inkarnation der Platzhalter des Patterns:
Es findet eine freie Ersetzung statt, nicht ein Vertauschen.
Für das Vertauschen braucht Mma ein RuleDelayed[] weil
dann die rechte Seite erst evaluiert wird, wenn die
Regel benutzt wird, d.h. nachdem die linke Seite gefunden wurde.
Die anderen Beispiele sind nicht verwunderlich wegen
In[31]:= x
Out[31]= z
Gruss
Udo.
--
Robert Nowak
IMS Nanofabrication AG
Phone: +43/12144894/32
Fax: +43/12144894/99
DMUG-Archiv, http://www.mathematica.ch/archiv.html