Verwirrung im Solver

Engywuck · 1 Jan. 2009

Moin moin,
damit's im neuen Jahr gleich frisch weiter geht, hier eine "Besonderheit" des Lösers, die mir vor ein paar Tagen aufgefallen ist, als ein Rechenergebnis überhaupt keinen Sinn machte. Gebe ich folgendes ein:
p=55
q(p)
q=66
q(q)
erhalte ich:
10
6666

Ich kann also Funktionen dadurch "überladen" dass ich ihrem Funktionsnamen einfach einen Wert zuweise. Im Normalfall sollte das unproblematisch sein (wer macht schon "encode=7" ?), aber grad bei "q" könnte es zu Missverständnissen kommen, denen man evtl. nicht auf die Schliche kommt.

Wie man das Problem sinnvoll entschärfen könnte, weiß ich allerdings auch nicht ;-)

Grüße,
Engywuck

Robin888 · 3 Jan. 2009

Engywuck schrieb:
Ich kann also Funktionen dadurch "überladen" dass ich ihrem Funktionsnamen einfach einen Wert zuweise.

In der Tat. Deutlicher wird das an dem Beispiel:

Code:

q=11
quer(q)
quer=22
q(q)
q(quer)
quer(q)
quer(quer)

Engywuck schrieb:
Wie man das Problem sinnvoll entschärfen könnte, weiß ich allerdings auch nicht

1.) Immer möglich lange Funktionsaufrufe benutzen.

Ich benutze zum Beispiel "quer()" statt "q()".
2.) Großbuchstaben für Variablen
Ich benutze fast ausschließlich Großbuchstaben für Variablen und Kleinbuchstaben für Funktionen. Damit wäre das auch nicht passiert.

(Das ändert natürlich nichts daran, daß dieses Verhalten verhindert werden sollte.)

Robin(888)

Engywuck · 4 Jan. 2009

Robin888 schrieb:
Engywuck schrieb:

Wie man das Problem sinnvoll entschärfen könnte, weiß ich allerdings auch nicht

Zum Vergrößern anklicken....

1.) Immer möglich lange Funktionsaufrufe benutzen.
Ich benutze zum Beispiel "quer()" statt "q()".

Das "sinnvoll entschärfen" bezog sich eher auf die Frage "Wie kann man das Programm so stricken, dass es diese Falle nicht mehr gibt."
Wie man seine Formeln so umformulieren kann, dass man das Problem nicht hat, weiß ich ja auch

Robin888 schrieb:
2.) Großbuchstaben für Variablen
Ich benutze fast ausschließlich Großbuchstaben für Variablen und Kleinbuchstaben für Funktionen. Damit wäre das auch nicht passiert.

Das stimmt zwar. Ich nutze aber in der Regel die Formeln, die im Cachelisting angegeben sind, und übertrage sie per Copy & Paste in den Löser. Und wenn sie im Listing in Kleinbuchstaben stehen, dann bleibt das halt auch so

Gruß,
E.

salzkammergut · 9 Jan. 2009

Ich habe gerade einen Fix eingestellt, der das Problem beheben sollte. Im Beispiel

Code:

q=11
q(q)

wurde das erste q von "q(q)" fälschlicherweise als Variable interpretiert weil nicht geprüft wurde ob das nächste Token eine öffnende Klammer ist (die aus der Variablen einen Funktionsaufruf macht). Dadurch wurde der Ausdruck als Variable "q" gefolgt vom Ausdruck "(q)" geparst, wodurch die Verdoppelung der Argumente zustande kam.

Grüße
skg

Robin888 · 9 Jan. 2009

salzkammergut schrieb:
Ich habe gerade einen Fix eingestellt, der das Problem beheben sollte.

Mal ganz blöde gefragt: Diese Fixes helfen doch nur bei Selberkompilieren, richtig?

Robin(888)

MiK · 9 Jan. 2009

Da er es auch in den noch-EWE-Trunk commitet hat, sollte es auch in den NBs landen.

Robin888 · 9 Jan. 2009

:-o Es gibt noch Nightly Builds? Ich dachte, die wurden auf Eis gelegt, bis zum EVE-Umstieg!?

Robin(888)

MiK · 9 Jan. 2009

Soweit ich weiß, werden die noch automatisch erzeugt
und solange der Trunk nicht EVE wird funktioniert das auch noch.

Siehe:
http://pub.naturalnet.de/~hawks/own/cw-nightly.php

Verwirrung im Solver

Engywuck

Geowizard

Robin888

Geomaster

Engywuck

Geowizard

salzkammergut

Geomaster

Robin888

Geomaster

MiK

Geoguru

Robin888

Geomaster

MiK

Geoguru