JMP Expr() seltsam, kann mir das jemand erklären?Dies ist größtenteils nur ein frustrierender Beitrag über die folgende Inkonsistenz beim Einfügen von „IF“-Ausdrücken in einen „IF“-Ausdruck.Nach meinem Verständnis sollten Programmiersprachen nichts anderes als konsistent sein (und mir sind viele andere JMP-Inkonsistenzen bekannt – nur diese hier ergibt für mich überhaupt keinen Sinn).
/*
What I want is to generate an expression such as the one below programmatically. There of course is a straight-forward work around, I just don't like dealing with special cases especially when they make no sense.
Expr( If( a, If( b, c) ) )<BR />
*/
expr = Expr( If( a ) );
Insert Into( expr, Expr( If( b, c ) ) );
Show( Name Expr( expr ) );
/*
If( a, b, c)
*/
expr = Expr( not an If( a ) );
Insert Into( expr, Expr( If( b, c ) ) );
Show( Name Expr( expr ) );
/*
not an If( a, If( b, c) )
*/
Wenn jemand irgendwelche Erkenntnisse hat oder insbesondere, wenn Sie eine Möglichkeit kennen, jeden Ausdruck zuverlässig in einen anderen Ausdruck einzufügen (nicht durch Verwendung von „Eval Insert“ oder Zeichenfolgen), wäre das großartig!Danke!
Erweiterte statistische ModellierungBetreff: JMP Expr() seltsam, kann mir das jemand erklären?Es gibt eine Problemumgehung, um die angeforderte Aufgabe zu erfüllen – aber die eigentliche Frage: WARUM?!? ist noch nicht beantwortet.
hinzugefügt zu Winzige Fallen in Jmp und JSL
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Weitere Beispiele, die einige der Hypothesen leicht widerlegen – und weitere Erkenntnisse hinzufügen:
expr = Expr( If( a, x ) );
Insert Into( expr, Expr(If( b,c )) );
Show( Name Expr( expr ) ); // if(a,x,b,c)
expr = Expr( If( a ) );
Insert Into( expr, Expr(If( b )) );
Show( Name Expr( expr ) ); // if(a,b)
expr = Expr( List( a ) );
Insert Into( expr, Expr(List( b )) );
Show( Name Expr( expr ) ); // List(a,b)
expr = Expr( Graph Builder( a ) );
Insert Into( expr, Expr(Graph Builder ( b )) );
Show( Name Expr( expr ) ); // Graph Builder(a,b)
expr = Expr( Head( a ) );
Insert Into( expr, Expr(Head( b )) );
Show( Name Expr( expr ) ); // Head(a,b) (!)
expr = Expr( Not( a ) );
Insert Into( expr, Expr(Not( b )) );
Show( Name Expr( expr ) ); // Not(a) (!!)
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Hallo,
Obwohl ich mir nicht sicher bin, frage ich mich, ob dieses Verhalten darauf zurückzuführen ist, dass das Snippet „IF ( a )“ kein wohlgeformter JSL-Ausdruck ist. Das heißt, die Funktion IF benötigt zwei Argumente, nicht eines. JMP hat keine Möglichkeit zu wissen, ob „notAnIf( a )“ ein wohlgeformter Ausdruck ist, also zuckt es vielleicht mit den Schultern und fährt fort ( ? ). Totale Vermutung meinerseits.
Die Tatsache, dass das Folgende so funktioniert, wie Sie es beabsichtigen, scheint diese Idee etwas zu unterstützen, erklärt aber nicht, warum @ben_ph Die Idee von funktioniert, da sie REPLACE_ME erfolgreich dort einfügt, wo mir ein fehlt.
expr = Expr( If( a, . ) );
Substitute Into( expr, expr(.), expr( If( b, c ) ) );
Show( Name Expr( expr ) );
Prost,
Brady
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Um dieses Problem zu umgehen, ohne Zeichenfolgen zu verwenden, können Sie Folgendes tun:
expr = Expr( If( a ) );
Insert Into( expr, Expr( REPLACE_ME ) );
Substitute Into( expr, Expr( REPLACE_ME ), Expr( If( b, c ) ) );
Name Expr( expr );
// If( a, If( b, c ) )
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Das ist eng verwandt mit das Gleiche wie So fügen Sie eine Liste in eine andere Liste ein . Aufgrund Ihrer Frage vermute ich nun, dass es eine spezielle Ausnahme für integrierte Funktionsnamen gibt, die dieses Verhalten zeigt.
expr = Expr( not an If( a ) );
ist das gleiche wie
expr = Expr( NotAnIf( a ) );
NotAnIf (oder kein If) zu einem Funktionsnamen machen, den JMP nicht als integriert erkennt. Im Beispiel {list} ist {...} dasselbe wie List(...) und Ist ein integrierter Funktionsname.
expr = Expr( sum( a ) );
Einfügen in( expr, Expr( sum( b, c ) ) );
Show( Name Expr( expr ) );
/*:
Name Expr(expr) = Sum(a, b, c);
//:*/
expr = Expr( sum1( a ) );
Einfügen in( expr, Expr( sum1( b, c ) ) );
Show( Name Expr( expr ) );
/*:
Name Expr(expr) = sum1(a, sum1(b, c));
Mir gefällt es auch nicht.
@XanGregg
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Auch die Konsistenz von Release zu Release ist wichtig. Jede Sprache weist einige Designfehler auf, die frühzeitig erkannt werden. Jemand (normalerweise ein Entwickler und ein Spezialist für technischen Support oder Vertriebsingenieur) entscheidet, ob
LongTermGainFromFixing – CostsOfFixing > CostOfDoingNothing
CostsOfFixing ist wirklich kompliziert: Entwicklerzeit + Testzeit + Dokumentationszeit + kurzfristige technische Supportzeit + Kundenverärgerung darüber, dass JSL, das zuvor funktioniert hat, jetzt ausfällt + verpasste Chancen + das Risiko, dass es noch schlimmer wird.
CostOfDoingNothing ist auch kompliziert: Wie viel technischer Support ist für immer in der Zukunft erforderlich, wie viele Benutzer werden jemals auf das Problem stoßen und wie schwierig ist es, es zu verstehen und zu umgehen? Mehr Vermutungen.
Dieses Forum, das Wunschlistenforum, Ihr JMP-Vertreter und Benutzergruppentreffen helfen alle bei der Entscheidungsfindung. Danke @hogi fürs Helfen beim Lenken!
@julianisch
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Das ist ein interessantes Problem.Sie könnten Ihre eigene Funktion erstellen, um die Einfügung durchzuführen, die wie erwartet funktioniert [glaube ich], in allen Fällen außer dem letzten von @hogi .In diesem Fall gibt die Funktion jedoch das gleiche Ergebnis zurück wie beim direkten Aufruf dieses Ausdrucks mit „Name Expr“, sodass man argumentieren könnte, dass dies das „richtige“ Ergebnis ist.
Names default to here(1);
// Make a new function to show each step of Insert Into:
New Insert Into = function( {exp, newarg, debug = 0 }, local({hd, ar, ne},
//Get the outermost function
hd = Head(exp);
if(debug, show(name expr( hd ) ) );
//Replace that function with a list so insert into works as expected
ar = substitute(name expr( exp ), name expr( hd ), {});
if(debug, show(name expr( ar ) ) );
//Now add the new argument
Insert Into( ar, name expr( newarg ) );
if(debug, show(name expr( ar ) ) );
//and put the orignial function back
ne = substitute(name expr( ar ), {}, name expr( hd ));
if(debug, show(name expr( ne ) ) );
Name expr( ne );
) );
// Test with the examples in the original post, note that they match:
Show( New Insert Into( Expr( If( a ) ), Expr( If( b, c ) ) ) ); // If(a, If(b, c))
Show( New Insert Into( Expr( Not an If( a ) ), Expr( If( b, c ) ) ) ); // Not an If(a, If(b, c))
// Additional examples from hogi post
Show( New Insert Into( Expr( If( a, x ) ), Expr( If( b, c ) ) ) ); // If(a, x, If(b, c))
Show( New Insert Into( Expr( If( a ) ), Expr( If( b ) ) ) ); // If(a, If
Show( New Insert Into( Expr( List( a ) ), Expr( List( b ) ) ) ); // List(a, b)
Show( New Insert Into( Expr( Graph Builder( a ) ), Expr( Graph Builder( b ) ) ) ); // Graph Builder(a, Graph Builder(b))
Show( New Insert Into( Expr( Head( a ) ), Expr( Head( b ) ) ) ); // Head(a, Head(b))
Show( New Insert Into( Expr( Not( a ) ), Expr( Not( b ) ) ) ); // !a
// The last one doesn't seem right but that it is actually being 'fixed' after as it is created:
Show( New Insert Into( Expr( Not( a ) ), Expr( Not( b ) ), debug = 1 ) ); // !a
// This is the same result as if you just call that directly, so I think this is the 'correct' result
Name Expr( Not(a, !b) ); // !a
// This function replaces all the Head expressions, which I think is okay, note this line:
// Name Expr(ar) = {a, {b, c}}
Show( New Insert Into( Expr( If( a, If( b, c ) ) ), Expr( If( d, e ) ), 1 ) ); // If(a, If(b, c), If(d, e))
Hier ist die gleiche Funktion ohne Debug-Zeug:
New Insert Into = function( {exp, newarg }, local({hd, ar, ne},
hd = Head(exp);
ar = substitute(name expr( exp ), name expr( hd ), {});
Insert Into( ar, name expr( newarg ) );
ne = substitute(name expr( ar ), {}, name expr( hd ));
name expr( ne );
) );
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Dies behebt das Problem mit zweimal demselben Ausdruckstyp. Ja.
Aber ich fürchte, es ist kein so universeller Ersatz Einfügen in wie man es sich wünschen könnte.
Show( New Insert Into( Expr( If( a )), Expr( List( b,c )) ) ); // If(a,b,c)
Betreff: JMP Expr() seltsam, kann mir das jemand erklären?Dennoch ist meine Hauptintention hier:
Verstehen WARUM Einfügen in glättet die Struktur – sodass ich bei jeder zukünftigen Verwendung der Funktion sicher und zuversichtlich sein kann, dass sie das Richtige tut.
Für 2 Listen scheint es eine hilfreiche Funktion zu sein: Sie generiert automatisch eine abgeflachte Liste.
Hm, genauso hilfreich wie die automatische Bereichsanpassung im Graph Builder – sprich: in 93 % der Fälle hilft es, in den anderen Fällen ...
Heatmap – Option: fester Tick-Abstand (Aggregationsbereich)
Steckt mehr dahinter als der Versuch, „hilfsbereit“ zu sein?
Neu für mich war, dass es nicht nur darum geht, mit der Liste hilfreich zu sein ...
Bezüglich „Lösungen“ für Einfügen in mit dem Sonderfall von 2x der gleichen Ausdrucksart:
- Vielleicht gibt es eine versteckte Option: nicht abflachen(0|1) ?
expr = Expr( If( a ) );
Insert Into( expr, Expr( REPLACE_ME ) );
Substitute Into( expr, Expr( REPLACE_ME ), Expr( If( b, c ) ) );
Name Expr( expr );
ist wunderbar 
Hinweis:
@ich h schrieb:
... nur die erste Instanz sollte ersetzt werden.
Ich hatte vor ein paar Tagen ein ähnliches Problem und kam auf die Idee: Ausdrucksindizierung: Lese- und Schreibzugriff.
Es könnte die Ausdrucksverarbeitung in Jmp/JSL auf eine neue Ebene heben. Wenn Sie es nützlich finden, könnten Sie dafür stimmen ...
[Ich habe einen Kommentar mit einem Link zu diesem Beitrag hinzugefügt.]
Betreff: Merkwürdigkeiten bei JMP Expr(), kann das jemand erklären?
@hogi schrieb:
Bezüglich „Lösungen“ für „ Insert Into “ mit dem Sonderfall von 2x demselben Ausdruckstyp:
- Vielleicht gibt es eine versteckte Option: flatten(0|1) ?
Scheint nicht so zu sein...
Hier ist der Wunsch, eine solche Option zu erhalten: Einfügen in: Flatten(0|1)
