betrifft https://www.geogebra.org/m/bm7veryu
userfunction of berstein polynom
(1) B_{poly}(t,nn):= ({Sequence(nCr(nn, i) t^i (1-t)^(nn-i) ,i,0 ,nn)})
Für Grad nn=2 bekomme ich
(2)S(t):=Sum(B_{poly}(t,2)* ({A, B, C} ))
eine schöne Parameter-Kurve
um dann schon beim Grad nn=3 zu scheitern
(3) Sum(B_{poly}(t,3)*({A,B,C,D}))
Das sind jeweils zwei Listen, die multipliziert werden,
da sollte man doch erwarten, dass die zu einem vergleichbaren Ergebnis kommen?
{{((-t) + 1)^(2), ((2 * t) * ((-t) + 1)), t^(2)}} * ({A, B, C} )
===> ((6 * t^(2)) + (4 * t) + 2, (-10 * t^(2)) + (16 * t) - 2)
{{((-t) + 1)^(3), ((3 * t) * ((-t) + 1)^(2)), ((3 * t^(2)) * ((-t) + 1)), t^(3)}} * ({A,B,C,D})
===> {((-12 + (6 * ί)) * t^(3)) + ((18 - (30 * ί)) * t^(2)) + ((6 + (24 * ί)) * t) + 2 - (2 * ί)}
plötzlich sind wir im complexen?
BTW: 5.0 und 6.0 sind sich auch NICHT einig was das Ergebnis sein soll!
Und ja es gibt einen Workaround
Sum(Zip(L1*L2, L1,Flatten(B_{poly}(t,3)), L2, {A,B,C,D} ))
aber was spricht dagegen, daß die Listen-Multiplikation auch das tut was sie soll?
The same problem 
Der CAS scheint jedes "i" als die imaginäre Einheit zu interpretieren (EDIT: zumindest in der Web-Version), auch die Laufvariable in der "B_{poly}"-Definition. Keine Ahnung, ob das ein Bug ist oder gewollt, aber vermeide einfach "i" als Laufvariable. (Ob das Dein Problem komplett behebt, weiß ich nicht; ich kriege den CAS gerade überhaupt nicht dazu solche Art Funktion zu definieren.)
Nein, das ist nicht das Problem, weil
user-function müssen mit "Behalte Eingabe" abgeschlossen werden, dann klappt das auch mit user-functions.
das i wird dann erst zur Laufzeit definiert!
@Michael
Ach, noch was....
Die Kurve S(t) ist nur auf ganzzahligen Gitterpunkten A,B,C bestimmt, auf Zwischenwerten undefinert:
Move C to real numbers C
Übrigens passen die Definitionen von B_{poly} und S auch syntaktisch gar nicht so recht zusammen, und ich weiß nicht mal, warum Geogebra das so interpretiert wie es das tut.
Durch die geschweiften Klammern um die Sequence bei B_{poly} wird der Funktionswert ja dann eine Liste, die eine einzige Liste als Element erhält, also für Geogebra eine Matrix mit einer Zeile bzw. ein Zeilenvektor. (Und die runden Klammern drumherum sind überflüssig, wenn ich das richtig sehe.) Multipliziert wird das dann in der Def. von S mit einer einfachen Liste von Punkten. An der Stelle wär ich mir ohne Testen schon gar nicht mehr sicher, was Geogebra dann eigentlich macht, denn die Operanden sind keine zwei Listen gleicher Länge und auch keine zwei passende Matrizen. Ich hätte eigentlich erwartet, dass Geogebra das ablehnt, aber Geogebra macht da trotzdem etwas. Mein Test in Geogebra 5 legt nahe, dass Geogebra die Liste der Punkte wie einen Spaltenvektor von Punkten behandelt und eine Matrix-Multiplikation macht, allerdings ist das Ergebnis keine einelementige Matrix (also keine Liste von Listen) sondern eine einelementige einfache Liste. Keine Ahnung, nach welcher Logik das eigentlich passiert. (In S wird dann noch die Summe dieser einelementigen Liste gebildet, wodurch nur noch das Element, also der Punkt, übrig bleibt.)
EDIT: Was passiert denn bei Dir, wenn Du bei der Def. von B_{poly} mal die geschweiften Klammern drumherum weg lässt? Dann wäre es wirklich eine ordentliche Multiplikation von Listen gleicher Länge.
EDIT2: Jetzt hab Dein Ding auch in meinem Geogebra 5 komplett hinbekommen. (Hatte einen Vertipper drin.) Gibt auch diesen Term mit den komplexen Zahlen und scheint wirklich an der unpassenden Multiplikation zu liegen, die Geogebra wer-weiß-wie interpretiert. Ohne die geschweiften Klammern bei B_{poly} haut es aber ordentlich hin.
Wie vermutet ist die falsche Syntax das eigentliche Problem:
(Antwort aus einem anderen Thread, in dem ich das mal generell angesprochen hatte.)
Mit
(1) B_{poly}(t,nn):= Sequence(nCr(nn, i) t^i (1-t)^(nn-i), i, 0, nn) (2) S(t):=Sum(B_{poly}(t, 2) * {A, B, C})ist es eine wohl-definierte Listenmultiplikation und alles klappt wie erwartet.
Ja, der eigentliche Grund war ein Variablenkonflikt t als Slider und t als Functionparameter und deshalb hat die ursprüngliche Listen-Version nicht funktioniert - so wie es aussieht wurde in der Listenversion der Funktionsparameter B_{poly}(t,..) durch den Sliderwert t überschrieben - in der Matrixversion dagegen nicht. Deshalb hat sich bei unterschiedlichen Versuchen dann ein Durcheinander entwickelt....
Jetzt hab ich nur noch das Problem, dass die Parabelkurven als Conic erkannt werden und nur auf ganzzahligen Punkten definiert werden - Curve scheint im CAS nicht angenommen zu werden?
@Keep Input
in der Online version ist die Symbolleiste doch die gleiche? Wo ist der Haken, im wörtlchen Sinn ;-)
Und ein weiteres Problem. Die CAS Function S_{ABCD} wird im CAS und Grafikfenster beim Verschieben von A,B,C,D angepasst und im Algebrafenster NICHT! Neben dem Problem, dass S_{ABC} Conic ist und nicht Parametric Curve
Ich bin noch recht neu in Geogebra, und das Zusammenspiel von Algebra und CAS verwirrt mich generell noch komplett.
Soweit ich das bisher einschätzen kann, kennt CAS prinzipiell keine geometrischen Objekte, lediglich Terme, Gleichungen, u.s.w., aber der Algebra Modus versucht immer automatisch das CAS-Zeug zu interpretieren und passende Objekte definiert (was auch oft genug gelingt), nur dass man als Nutzer anscheinend überhaupt keinen Einfluss darauf hat, wie etwas interpretiert wird. Man kann im Algebra-Modus nicht mal "per Hand" etwas definieren, das Funktionen aus dem CAS benutzt.
Für Dein Problem mit der unterschiedlichen Interpretation von S_{ABC} (als Conic) und S_{ABCD} (als Curve) würde ich Dir empfehlen, Funktionen für die x- und y-Koordinate unabhängig zu definieren, denn solche "einfachen" Funktionen kann auch der Algebra-Teil übernehmen, ohne irgendwas interpretieren zu müssen. (Und soweit ich das bisher testen konnte, scheint auch das Aktualisieren beim Verschieben der Punkte dabei ohne Probleme zu funktionieren.) Kurven zur Darstellung kann man dann ja immer noch draus machen. Also z.B.
Sx_{ABC}(t):=Sum(B_{poly}(t, 2) * {x(A), x(B), x(C)}) Sy_{ABC}(t):=Sum(B_{poly}(t, 2) * {y(A), y(B), y(C)})(Interessanterweise produzieren x(...) und y(...) im CAS-Modus an der Stelle irgendwas unerwartetes, wenn es in dem Ausdruck auf die ganze Liste {A,B,C} anzuwenden versucht oder auf die Produktliste. Hab noch nicht verstanden warum, aber mit der einzelnen Anwendung auf A, B, C klappt es.)Comments have been locked on this page!