Integralfläche reagiert nicht auf sich ändernde Parameter

Ruben Stachowitz shared this problem 2 years ago
Solved

Hallo!


Ich entwickle gerade eine Datei zum Thema "Riemann-Integral" und habe folgendes Problem:

Ich möchte bei einer gegebenen Rechteck-Approximation nach Bedarf lediglich die Fläche zwischen dem Graphen und der Oberkante der approximierenden Rechtecke anzeigen lassen. (Die Rechtecke werden von der Liste lstRechtecke erzeugt.) Wenn ich die entsprechende Liste für die "Differenzflächen" durch Eingabe in der Eingabezeile erzeuge – sie heißt lstFlächenDiff -, so klappt auch alles wie intendiert. Die Differenzflächen werden allen Parametern entsprechend korrekt angezeigt. Die erzeugte Liste aktualisiert sich zudem, wie gewünscht, wenn ich die Anzahl der Rechtecke n oder die Integrationsgrenzen verändere. Das Problem ist nur, dass die angezeigten Flächen darauf nicht reagieren! Erst, wenn ich die Definition der Liste verändere, beispielsweise durch Einfügen (oder Weglassen) der nicht benötigten Schrittweite oder dadurch, dass ich statt des Parameters n für die Anzahl der Rechtecke eine konkrete Zahl einsetze, etc. etc., aktualisiert sich auch (genau dies eine mal) die Zeichnung. Könnt ihr mir da weiterhelfen? Ich sitze gerade an der Vorbereitung eines Workshops, und wäre total dankbar, wenn sich das Problem lösen ließe.


Viele Grüße, Ruben


P.S. Statt die native Funktion Rechtecksumme zu verwenden, habe ich meine eigene Funktion rsRechteck geschrieben, um auch die zufällige Auswahl der Stützstellen zu implementieren.

Comments (5)

photo
1

Wenn die Integralwerte nicht gebraucht werden dann wird empfohlen auf Ungleichungen zurückzugreifen.

photo
1

Hallo Loco,


hab ganz vielen lieben Dank für den Support und die Lösung meines Problems! Die Werte der Differenzflächen brauche ich tatsächlich nicht und selbst wenn, könnte man sie sich ja leicht errechnen ...

Lieber Gruß, Ruben

P.S. Eins habe ich noch rausgefunden und ist für die Entwickler vielleicht von Interesse: Die Verwendung der Funktion IntegralZwischen innerhalb des Befehls Folge funktioniert nicht nur nicht, sondern scheint darüber hinaus auch die GeoGebra-Datei zu korrumpieren. Denn unmittelbar nach dem Erzeugen dieser Liste funktioniert der Befehl Integral nicht mehr. Gibt man in der Eingabezeile nun zum Beispiel "Integral(f,3,5)" ein, so kommt die Fehlermeldung, dass für "f" eine Zahl erwartet wird. Gibt man jetzt tatsächlich eine Zahl für „f“ ein, so wird ein Vektor mit drei Koordinaten erzeugt! Ändert man hingegen die Eingabe in "Integral(f(x),3,5)" ab, so wird dies zwar syntaktisch akzeptiert, doch wird auch jetzt kein Integral erzeugt, sondern eine (nicht sichtbare) "Kurve" mit folgender Darstellung im Algebra-Fenster:

a: Integral(f,x(A),x(B)) (f(x),3,5), (-10<=x<=10)

Sehr kryptisch ...

photo
1

Ja das klingt nach einem Bug.

photo
1

Ich bin mit diesem Post etwas spät dran, insbesondere als dieses und ein weiteres Thema in einem andern Thread abschliessend behandelt wurde.

.

Falls IntegralZwischen der ideale Befehl ist und es nur um das Zeichnen der Flächen geht (und somit keine Abhängigkeiten zu den zu zeichnenden Flächen besteht), dann könnte folgender Workaround zum Bug weiterhelfen:

.

Jene liste (l3 im Beispiel), die die notwendigen Punkte für die zu zeichnenden Flächen (l4 im Beispiel) enthält, bekommt einen Skript onUpdate. Dieser löscht die zu zeichnenden Flächen (l4) und erstellt die Liste vollständig neu. Da keine Abhängigkeiten (zu l4 im Beispiel) bestehen, entsteht dadurch kein Folgeproblem (Abhängigkeiten würden gelöscht). Der Vorteil dieses Workaroundes: Die Neu-Berechnung von (je nach Benutzerwahl) nicht benötigten (ausgeblendeten) Listen kann (im Skript in l3) unterdrückt werden. Der Skript selbst ist kein leuchtendes Beispiel aber einer der wenigen Fällen, wo mit "=" anstelle von SetzeWert() gearbeitet werden muss.

.

Ich gehe davon aus, dass vielleicht 10 listen a 20 Elemente berechnet und angezeigt werden, das ergibt vermutlich keine Performance-Probleme (ich vermute bei so ca 500 Elementen dürfte dann die Performance-Schmerzgrenze erreicht sein). Bei dieser Schätzung gehe ich davon aus, dass die Applikation auf einem normalen, anständigen (Wärme produzierenden) Computer läuft (also kein Telefon und auch kein Telefon mit grossem Bildschirm)

.

Alternativ habe ich anstelle von l4 die Tabellenkalkulation erkundet. Dort hat es ebenfalls einen Bug mit IntegralZwischen.

Dazu habe ich aber keinen Workaround gefunden. Rein Informativ noch das entsprechende File für die Entwickler, die sich möglicherweise dafür interessieren.

photo
1

Nachtrag: Diese Bugmeldung gilt als "gelöst"

Frage: Seit wann ist in der Informatik ein Workaround zu einem nach wie vor bestehenden Bug eine Lösung ???

(Ja ich weiss, das ist allgemein gang und gäbe (leider). ABER doch nicht in dieser Art schrifltlich verbrieft ! Ueblicherweise werden diese Bugs auf einer hochoffiziellen, "transparent" einsehbaren Liste unter "Pendent Priorität 3" eingetragen).

Ernst gemeinter, vereinfachender Vorschlag: neuer (zusätzlicher) Status für Bugs: "Umstufung zu Einschränkung".

© 2021 International GeoGebra Institute