Ich habe gerade einen Code analysiert, der von einer weniger beliebten KI erstellt wurde:
dt = Open("$SAMPLE_DATA/Big Class.jmp");
kd = dt << KDTable("hello");
result = kd << K Nearest Rows(1, 3);<BR />print("finished");
Im Protokoll stand:
Object 'Data Table' does not recognize the message 'K Nearest Rows'; perhaps you mean one of these: <
<<<<<<<<
finished
Sure: if a scriptable object doesn't understand a message, it shows such a warning message in the log.
And a Data Table doesn't understand the the message K nearest Rows().
But wait, why is kd a data table?!
This is easy to answer: In the previous line of code, the data table doesn't understand the command << KDTable("hello");
And therefore, instead of returning a KD table, it returns a reference to itself.
Unfortunately, here is NO warning message:
Object 'Data Table' does not recognize the message 'KD Table("hello")'
A JSL scripter will spot the error within seconds : KD Table("hello") , tztztz!
But you’d probably agree—it’s hard to find the error from the information JMP provides!
How to escape this issue? Is there a general rule or trick?
Can JMP / the JSL interpreter be improved to help AI and the users understand the errors?
Users with paranoia could add If (type(name Expr(returned object) == ...) after every message sent to a scriptable object. Hm ...
JMP ist so konzipiert. Ich wünschte, es wäre anders. Die Gründe dafür sind: (1) Objekte ignorieren Nachrichten, die sie nicht verstehen, und (2) Nachrichten können verkettet werden. Vor einigen Versionen hat JMP eine Option eingeführt, mit der bestimmte Objekte nicht erkannte Nachrichten melden können. Ob das funktioniert, hängt vom jeweiligen Objekt ab; ich glaube, die Anzeigefelder verwenden alle gemeinsamen Code, um damit umzugehen.
Nachrichten verketten, wie tb<
Nach diesen Regeln erfüllt Zeile 2 Ihres Beispiels ihren Zweck.
Ich denke, das stillschweigende Ignorieren nicht erkannter Nachrichten stammt wahrscheinlich aus der Untersuchung der Nachrichtenverarbeitung von MS-Windows (vorletztes Jahrhundert). Es gibt unglaublich viele Nachrichten, die stillschweigend ignoriert werden (z. B. wenn sich der Mauszeiger über Sie bewegt , Sie aber nicht die Absicht haben, darauf zu reagieren). In JMP könnte man das so verwenden: `{ textBox, outlineBox } << setcolor("red") << close(1);`, wobei jedes Feld in der Liste, das < versteht, <<>
Der Unterschied zwischen den beiden Nachrichten, die Ihre Beispiele an die Datentabelle senden, besteht darin, dass kdtable() eine globale, plattformähnliche Funktion ist, während < < m> ist eine Nachricht, die nur einem kdtable-Objekt bekannt ist. Die Datentabelle selbst sieht gerne Nachrichten, die wie Plattformstarts aussehen, dt< Zum Beispiel. Hier liegt ein Fehler vor. Ich vermute, dass kdtable die Ursache ist, da es kein Problem mit dem Argument „hello“ meldet, und die Datentabelle möglicherweise annimmt, dass eine Plattform gestartet wurde. Vielleicht die leere Plattform (Entschuldigung, so etwas gibt es nicht).
kdtable("hello")
/*:
Empty()
Hallo
@Craige_Hales , vielen Dank für die ausführlichen Hintergrundinformationen – Klar, ich verstehe,
warum JSL damals so konzipiert wurde (stilles Ignorieren unbekannter Nachrichten + Verkettung, die das linke Objekt zurückgibt).
Ich hoffe jedoch auch, dass die JSL-Entwickler erkennen, dass dieses Muster mit der heutigen KI-gestützten Stimmungscodierung etwas „inkompatibel“ geworden ist:
LLMs erfinden bereitwillig Meldungen , Plattformaufrufe und Argumente, die im aktuellen Verhalten oft einfach stillschweigend ignoriert werden. Das verwirrt nicht nur, sondern kann die Fehlersuche auch zur Hölle machen – man bekämpft am Ende nur noch die Symptome anstatt der eigentlichen Ursache.
Vielleicht können die Entwickler einen Schalter auf JSL-Ebene für den „KI-Debug-/Chat-Modus“ bereitstellen:
bewusst laute, aber unglaublich hilfreiche Diagnosen für ausgewählte Objektklassen (z. B. Anzeigeobjekte, Plattformen, allgemeine skriptfähige Objekte) zu aktivieren.
Die Idee ist, dass JMP, wenn das Endergebnis merkwürdig aussieht, diesen Modus aktiviert und genau dort Fehler meldet, wo sie auftreten, anstatt stillschweigend zu scheitern und erst viel später eine Fehlermeldung auszugeben. Ich habe dies hier als Wunschpunkt zur Abstimmung hinzugefügt:
„Chatty mode() for AI debugging“ (Chat-Modus für KI-Debugging).
Nochmals vielen Dank für die Einblicke und die Bestätigung, dass dies ein Bereich ist, in dem das Verhalten verbessert werden kann.
