Funktionsgraphen laufzeitgünstig verändern

-Loco- shared this question 9 years ago
Answered

Hallo,

Ich möchte drei Graphen unterschiedlicher Funktionen laufzeitschonend in GGB darstellen,

dies soll möglichst in einem Grafikfenster möglich sein.

Ich möchte die Graphen verschieben, strecken/stauchen und vom Werte- und Definitionsbereich eingrenzen.


Bisher arbeite ich mit zwei Wenn-Bedingungen und manipuliere die Formeln.

Bsp.: (Funktion: f ; Definitionsbereich: [ax;bx] ; Wertebereich: [ay;by] ; Streckung: sx ; Stauchung: sy ; neuer "Nullpunkt": N )

    fx(x) = Wenn[ ( x(N) + ax * sx ) <= x <= ( x(N) + bx * sx ) , sy * f( ( x - x(N) ) / sx ) + y(N) ]

    fy(x) = Wenn[ ( y(N) + sy * ay ) <= fx(x) <= ( y(N) + sy * by ) , fx ]

Ich möchte für meine Seminararbeit drei von diesen manipulierbaren Graphen auf meinem Arbeitsblatt darstellen,

jedoch ist dann das Zoomen fast unmöglich (Updatezeit >1min. pro Zoomschritt).

Geht das laufzeitschonender?


Ich poste hier nur ein Preview, da die Datei selbst wahrscheinlich fast jeden anderen PC "erledigt".

55115b988339a503b2c8999f1242adbb

Gruß

Loco

Comments (24)

photo
1

Hallo,

Ich möchte drei Graphen unterschiedlicher Funktionen laufzeitschonend in GGB darstellen,

dies soll möglichst in einem Grafikfenster möglich sein.

Ich möchte die Graphen verschieben, strecken/stauchen und vom Werte- und Definitionsbereich eingrenzen.


Bisher arbeite ich mit zwei Wenn-Bedingungen und manipuliere die Formeln.

Bsp.: (Funktion: f ; Definitionsbereich: [ax;bx] ; Wertebereich: [ay;by] ; Streckung: sx ; Stauchung: sy ; neuer "Nullpunkt": N )

    fx(x) = Wenn[ ( x(N) + ax * sx ) <= x <= ( x(N) + bx * sx ) , sy * f( ( x - x(N) ) / sx ) + y(N) ]

    fy(x) = Wenn[ ( y(N) + sy * ay ) <= fx(x) <= ( y(N) + sy * by ) , fx ]

Ich möchte für meine Seminararbeit drei von diesen manipulierbaren Graphen auf meinem Arbeitsblatt darstellen,

jedoch ist dann das Zoomen fast unmöglich (Updatezeit >1min. pro Zoomschritt).

Geht das laufzeitschonender?


Ich poste hier nur ein Preview, da die Datei selbst wahrscheinlich fast jeden anderen PC "erledigt".

[attachment=0]Polarkurven.png[/attachment]

Gruß

Loco

Hallo,

mir fällt nur ein workaround ein. Wenn du deinen fertigen Komplett-Graphen als Bild speicherst, kannst du Streckungen durch Manipulationen der Eckpunkte dieses Bildes erreichen. Beschränkungen des Wertebereichs lassen sich durch Überdeckungen mit weißen Balken simulieren.

Gruß Abakus

photo
1

Hallo Loco,


Sieht ja richtig hübsch aus, es wäre zu schade wenn man die Farbverläufe aus Performance-Gründen entfernen müsste.


Bei weitem nicht so hübsch aber massiv rascher funktioniert der folgende Farbverlauf:

http://www.geogebratube.org...


Eine andere Idee dazu:

Ein Bild (mit entsprechenden Eckpunkten) kann man verschieben, stauchen/strecken (beide Achsen) und mit überlagerten Rechtecken beschneiden.


Raymond


Nachtrag:

abakus ist endlich wieder da :D !! Er war wieder einmal schneller, sodass sich unsere Antworten zeitlich überschneiden.

photo
1

Hallo abakus Hallo rami,

danke für die sehr raschen Antworten.


Der Lösungsansatz "Graph als Bild" kommt leider nicht in Frage.

Erklärung:

  • Das Arbeitsblatt ist so konzipiert, dass ich beliebige Parameterfunktionen eingebe und diese als Kurve ausgegeben werden.

    Ich kann Polarkurven, Zylinderkurven, Kugelkurven und kartesische Parameterkurven darstellen lassen.

    Die zugehörigen Parameterfunktionen werden nach Eingabe auf Wunsch in diesen "Zusatzkoordinatensystemen" angezeigt.

    Die Gesamtansicht würde ich dann als Bild speichern und für meine Arbeit verwenden.

    Übrigens vermute ich, dass dann die Spuren unter dem Bild verlaufen.


Die Ergänzungs-Idee von rami zu den Farbverläufen kannte ich bisher noch nicht und finde ich sehr interessant.

Jedoch würde ich gerne mit dem gesamten RGB-Farbspektrum arbeiten und der langsame Farbaufbau durch den Schieberegler

stört mich nicht so sehr wie die langen Zoom-Zeiten (die Kurven an sich sind ja schon da).


Ich hatte in der Zwischenzeit die vage Idee die Graphen nicht als Funktionsgraphen sondern als "Ortskurven" zu hinterlegen,

jedoch müssten diese an einigen Stellen "ausgespart" werden und ich bin mir nicht sicher ob ich die Laufzeit dadurch verbessern kann.


Ursprünglich wollte ich gnuplot für diese Aufgabe verwenden jedoch habe ich zu wenige Kenntnisse zu den jeweiligen Befehlen (und GGB kann ja fast alles). Das einzig Negative bei meiner Lösung ist, dass der Farbaufbau nicht wirklich "3D-Logisch-Deckend" ist.


Gruß

Loco


Hier noch ein Beispiel zu Zylinderkurven und Polarkurven:

d164375ded82225f0c54ce9a3dfaa8e0

photo
1

Hallo Loco


Daniel Mentrard hat sich intensiv mit 3D Umsetzungen (und noch mehr) beschäftigt.

Ich kenne mich in diesem Gebiet nicht sonderlich gut aus. Aber jene 3D Grafiken (von Daniel Mentrard), die ich bis jetzt betrachtet habe (es gibt zu viele als, dass ich alle sichten könnte) scheinen in der Performance akzeptabel zu sein. Vielleicht findest Du dort den richtigen "Dreh". Während einem gewissen Zeitraum hat er sich auch im englischen Forum zu diesem Thema mit viel Hintergrundinformationen geäussert.

http://www.geogebratube.org...


Raymond

photo
1

Hallo rami,

ja ich kannte einige seiner Dateien und nun kenne ich noch einige mehr.

Ich Denke du spielst auf den Nachteil an den ich im Vorpost erwähnt habe,

den werde ich wohl nicht aus der Welt schaffen können solange ich mit Spuren für die Farbverläufe arbeite

(wie verhalten sich eigtl. Spuren in GGB-3D?).


Die Probleme bezüglich des "pseudo-3D´s" welches er nutzt oder auch ich in meiner Datei verwende habe ich denke ich alle gelöst.

Denn wenn ich die "Zusatzgraphen" lösche (ich verwende sie nicht zum Aufbau der Kurve) kann ich (zumindest mit meinem Rechner)

erträgliche Updatezeiten erzielen.


Aber mich interessiert natürlich auch ob die Datei dann auch auf anderen Rechnern lauffähig ist.


Ich poste mal die unveränderte Datei:


https://ggbm.at/557965

Jedoch warne ich vor der Benutzung!

Der Prozess frisst bei mir zeitweilig bis zu über 550.000KB RAM.

Ach ja, die Datei im Browser zu öffnen ist eine ganz schlechte Idee.

Solange nicht gezoomt oder verschoben wird dürfte nichts Laggen.

Manchmal gibt GGB beim öffnen eine Fehlermeldung aus. Lösung: In einem geöffneten GGB-Fenster aufrufen.


Die "Laufzeit-Übeltäter" sind:

  • plot_{graph1} bis plot_{graph3}
  • plot_{graph1-cut} bis plot_{graph3-cut}


Dummerweise sind in dieser Datei die Folgende Elemente noch abhängig von den Übeltätern (aber das kann ich ändern):

  • point_{P-t-plot1} bis point_{P-t-plot3} abhängig von plot_{graph1} bis plot_{graph1}
  • point_{line-plot1-track} bis point_{line-plot3-track} abhängig von point_{P-t-plot1} bis point_{P-t-plot3}
  • plot_{color-value-line} abhängig von point_{P-t-plot1} bis point_{P-t-plot3}


In dieser Datei habe ich die genannten Objekte einfach mal gelöscht (man merkt den Unterschied).


https://ggbm.at/557969


Ich werde noch einige Änderungen an dieser Datei vornehmen.


Gruß

Loco

photo
1

Hi all,


Sorry but I don’t speak German.

I don’t know if that can help you but get a glance to this file: :D

http://tube.geogebra.org/st...

Perhaps you can adapt and improve it for your work, by modifying the system of equations (click on data). :confused:


Cheers, :wink:

Phil

photo
1

Hallo LPH,

and i'm not so good in english.

Thank you for your answer.

But my problem is more the manipulation of functions (move, scale x/y - direction, restrict),

without stressing the computer to much.

Cheers

Loco


Noch eine zusätzliche Frage:

Ist es möglich die Spuren über ein deckendes weißes Rechteck zu legen?

An additional question:

Is it possible to draw the traces over an white rectangle?

photo
1

Hallo Loco


Zur letzten Frage (Rechteck):

Ja, mit Verwendung der Ebenen. Diese kann man pro Objekt in den 'Eigenschaften/Erweitert ' setzen. Höhere Ebenen überdecken tiefere Ebenen.

Es ist möglich mehrere Objekte zu selektieren (Grafik, AlgebraFenster, Eigenschaften) und diesen gemeinsam eine Ebene zuordnen.


Eine kleine Unschönheit (nach meinem Geschmack): Alle neuen Objekte werden automatisch der höchsten vergebenen Ebene zugeordnet (besser wäre gewesen die 'letzte verwendete Ebene').


Aber möglicherweise verstehe ich die Frage nicht richtig, da Du diese Technik auch beim Anzeigen der Parameter anwendest. Allenfalls müsste das Rechteck auf eine Ebene gelegt werden, die zwischen den anzuzeigenden Spuren und den Objekten des abzudeckenden Teils liegt.


Einige Gedanken zu Polarkurven-faster:

Zunächst einmal meinen Respekt vor dieser umfassenden und sehr flexiblen Arbeit.


Ich habe das wage Gefühl, dass Deine Datei eventuell korrupt ist (ich hoffe mit Dir, dass dies nicht der Fall ist). Folgende Fakten (in meiner Umgebung) haben dieses Gefühl bei mir aufkeimen lassen:

- Gelegentlicher Absturz beim Starten

- Einige Objekte können nicht selektiert werden (in Algebra und Grafik)

- Einige Objekte können nicht gelöscht werden (in Algebra, Grafik, Eigenschaften)

(zB das AbdeckVieleck unter den Parametern liegend)

- Das Manipulieren des Codes ist in 4.2Beta praktisch nicht mehr möglich


Zu Vieles habe ich (in nützlicher Zeit) nicht verstanden. Darum sind alle Folgenden Punkte vage Thesen, Behauptungen und Gefühle:


- Geringe Abhängigkeiten, jedoch hohe Code-Redundanz

Ich vermute dass GGB umgekehrt bessere Laufzeiten hätte


- nicht notwendigerweise (?) generalisierte Objekte

Beispiel AbdeckVieleck für Parameter: Warum kein schlichtes, gross genuges Vieleck (allenfalls mit den dynamischen Eckpunkt[1]...Eckpunkt[4] des Grafik-Fensters]

Beispiel Gerade zwischen dem Urspung und dem animierten Punkt: warum nicht schlicht Strecke[(0,0), <animierterPunkt>]


- mit Wenn[] und Else-Fall verschachtelte Objekte.

Eventuell ist das (oder etwas verwandtes) im vorliegend Fall der Performance-Killer, da ich schon längere Zeit den Verdacht hege, dass GGB vorab die Funktionen auflöst und erst dann die Konditionen berücksichtigt. (Oder allgemeiner: erst die Blätter dann die Knoten)


Raymond

photo
1

Hallo rami,

dann erkläre ich mich mal.

Zum ersten Punkt "weißes Rechteck" da haben wir aneinander vorbeigeschrieben, die Spuren also die Farbverläufe sollen über ein deckendes Rechteck gezeichnet werden (aber das geht glaube ich überhaupt nicht). Ich wollte dieses Wissen verwenden um das Problem zu umgehen welches auftritt wenn z.B. eine Tangensfunktion gezeichnet wird (Rosette - tan).


Zum Lob, kurz und freudig: Danke.


Zum nächsten Punkt "korrupte Datei", mach mich nicht panisch! Ich habe nicht nur Stunden an dieser Datei gesessen.

Ich muss dir aber zustimmen, Abstürze und Fehlermeldungen hatte ich schon, jedoch waren das meist meines Wissens unverdächtige Objekte (ich werde mal Screenshots machen).

Das "nicht Selektieren" und "nicht-Löschen" kann ich nur durch mein bewusstes Deaktivieren/Aktivieren von "Auswahl erlauben" und "Objekt fixieren" erklären, wenn das nicht der Fall ist dann Poste bitte die genauen Objekte, denn es ist ja auch in meinem Interesse Fehler zu beseitigen.

Ich nutze prinzipiell keine Betasoftware im "Arbeitsbereich" da sich die Software und der Code manchmal zu sehr verändern und somit manche Arbeit zum Schluss für "die Katz war".


Was die "geringen Abhängigkeiten / hohe Code-Redundanz" betrifft, ich arbeite gerne mit möglichst wenigen "Konstruktionsebenen" und "klaren Strukturen".

Kernobjekte wie zum Beispiel die zentralen x-y-z - Vektoren verwende ich hingegen überall wo es möglich ist (übrigens ist diese Strecke bereits "schlicht" bestimmt).

Da die Datei noch nicht fertig ist, kann da natürlich noch viel getan werden und ich lasse mich gerne eines Besseren belehren.

Was den "potentiellen Verdächtigen" betrifft, ich bin hier eher einer anderen Ansicht.

Ich habe die "Pixel-pro-Einheit"-Objekte (habe ich übrigens bei dir gelernt) im Generalverdacht. Die Objekte PpUX1 und PpUY1 sind fast in jeder Liste und in ziemlich jedem Textobjekt vorhanden und demnach werden bei einer Veränderung der Ansicht sehr viele Objekte neu berechnet.

Zudem würde ich jetzt rein spekulativ sagen, dass das "in Reihe Schalten" der Wenn-Befehle nicht so große Laufzeitprobleme verursacht wie das "parallele Schalten" sehr vieler Wenn-Befehle (z.B.: y-Begrenzung von Funktionen) (habe jedoch keinen Beweis und nicht die lange Erfahrung mit GGB).


Nun poste ich hier noch eine neue Datei mit einigen Änderungen.

Das deckende Rechteck ist nun "simpler" Bestimmt, die Nebengraphen wurden gelöscht, die "lauf-Punkte" der Nebengraphen wurden unabhängig zu den Nebengraphen gemacht, die Farbformeln der farbigen Objekte habe ich in Farblisten ausgelagert.


https://ggbm.at/557973

Zudem habe ich den ersten Nebengraphen als Kurve bestimmt (Objekt : provisorium) ich finde diesen Befehl jedoch ungünstig, da im Kurvenbefehl keine Wenn-Befehle erlaubt sind.

Auch konnte ich den Ortslinienbefehl nicht auf die Laufpunkte der Nebengraphen anwenden.


Gruß

Loco


Edit-1:

Hier noch zwei der der 6 Befehle welche ich nutzte um die Nebengraphen zu zeichnen (um zu zeigen, wie die Nebengraphen die Rechenzeit erhöhten):

    plot_{graph1} = Wenn[x(plot_{fix.point1}) ≤ x ≤ x(plot_{fix.point1}) + PpUX1 plot_{pixel.amplitude}, def_{funct-IB.1}((x - x(plot_{fix.point1})) / plot_{t-scale.factor} + t_{a} π) plot_{var-scale.factor} + y(plot_{fix.point1})]

    plot_{graph1-cut} = Wenn[(y(plot_{fix.point1}) - Wenn[CB_{plot-positive}, 0, 0.5] plot_{pixel.altitude} PpUY1 ≤ plot_{graph1}(x)) ∧ (plot_{graph1}(x) ≤ y(plot_{fix.point1}) + Wenn[CB_{plot-positive}, 1, 0.5] plot_{pixel.altitude} PpUY1), plot_{graph1}]

Um die anderen Graphen zu zeichnen einfach entsprechend das graph1 , point1 und das IB.1 austauschen.


Edit-2:

Ich bin die Tage fort, dauert also bis ich antworte.

photo
1

Hallo Loco


Entwarnung :D


Sorry, das hätte mir auch auffallen können, dass diese Objekte fixiert resp. nicht selektierbar sind :flushed:


Zum Punkt "Pixel-pro-Einheit":

Ich habe diese Werte auf einen fixen Wert gesetzt. Das Resultat war ein Performance-Gewinn von ca. 15 bis 20 %


Dann habe ich für alle Objekte "fixieren" auf false gesetzt und Selektierbar auf true.

Dies um den folgenden Test durchzuführen:


Ich habe die vollständige 2D-Grafik resp. die 3D Grafik je einzeln und beide vollständig (?) gelöscht. Der Performance-Gewinn war nicht berauschend und im erwarteten Rahmen (je ca. 30 %, falls ich es richtig abgeschätzt habe, dann bliebe für die nicht sichtbaren Objekte ca. 40%, was in der groben Grössnordnung in etwa der Menge der Objekte entsprechen könnte). Allerdings habe ich auf die mögliche Frage, warum das Zooming für nicht sichtbare Objekte einen Einfluss haben soll keine Antwort (allenfalls Pixel pro Einheit könnte einen Einfluss gehabt haben)).

Vielleicht lohnt es sich diesen Test zu wiederholen und mit der Stoppuhr zu messen (mit und ohne fixen Wert pro Pixel-Einheit).


Dann habe ich untersucht, ob ein Hintergrund-Prozess in Java permanent läuft (zB ein animierter Punkt oder Zahl aus früheren Entwicklungsständen). Das scheint nicht der Fall zu sein.


Dann habe ich mich hinter die Farbgebung als potentiellen "Täter" gestürzt. Ich bin zwar nicht schlau geworden aber die Anzeige der "Nachfolger" (ctrl-shift-J) ist erwartungsgemäss nicht besonders gross (hätte ja sein können, dass Du auch noch die Farbe Schwarz parametrisiert oder dynamisch behandelt hättest :wink: ).


Ein kleiner Fehler ist mir noch aufgefallen: die Kurve in der 2D Grafik folgt in der y-Achse dem Zooming (in der x-Achse richtigerweise nicht).


Soviel vorab. Ich beabsichte noch meine These bezüglich Interpreter-Strategie (Wenn[ Kondition, true, false ]) zu überprüfen (mittels Zeitabfrage[] müsste das möglich sein). Falls ich zu handfesten Indizien komme (positiv oder negativ) , dann melde ich mich.


Raymond

photo
1

Hallo rami,

ein Glück ich war noch da, muss aber bald los, deshalb hier nur Anmerkungen.


Ich vermute du schaust dir die Dateistruktur an, löscht Objekte und vergleichst die Laufzeiten.

Dazu bräuchte es eine Entwicklerumgebung (vlt. sollte ich mir auch das Java-SDK holen?) da ja die Umgebung (hier der Speicher und Prozessablauf)

auf einem "normalen" PC nicht wirklich "Test-Normal" gehalten werden kann (zumindest macht das normalo Win.-System was es will).


Ich kann dir aber auf die schnelle eine Übersicht zu der Struktur meiner Datei geben (zumindest grob).

  • Grundstrucktur

    • CB-Objekte - Wahrheitswerte über die ich die Sichtbarkeiten, Farbwahl, Positionen, usw. steuere
    • grid-Objekte - sind alle Text-, und Gitterlinienfolgen für den Hauptgraphen (3D)
    • chart-Objekte - sind alle Objekte für das Farbdiagram nach Parameter t
    • plot_{grid}-Objekte - sind alle Gitter- und Textobjekte für die 3 Nebengraphen 2D
    • plot_{chart}-Ojekte - sind die Objekte für das Farbdiagramm nach [Funktion](t)
    • point-Objekte - sind alle animierten Laufpunkte und Strecken
    • color-Objekte - sind alle Farbfunktionen und Farblisten
    • def-Objekte - sind die hinterlegten Funktionen als Text und Funktion (ohne Begrenzung)

  • Kernelemente (orientieren sich auch am Fenster - hier evtl. Abhängigkeiten auflösen)

    • t - einziger und allmächtiger Parameter begrenzt durch t_{a} und t_{b}
    • plot_{graph-fixpoints} und plot_{fix.point1}... (1 bis 3) - Fixierpunkte für die Nebenkoordinatensysteme
    • V_{x-point}... (x,y,z) - Hauptvektoren die die 3D-Rotation simulieren über Parameter angle_{x-rotate} und angle_{z-rotate}
    • chart_{color-position} und plot_{color-chart-position} - positionieren die Farbgraphen

  • zus. Laufzeitverdächtige (meinerseits)

    • point_{x-P-angle} und point_{z-P-angle} - sind Vielecke mit integrierter Folge zum 3D-darstellen der Höhen- und Breitenwinkel


Zur Farbgebung (neue Datei) ich habe 4 verschiedene Kolorierungsmöglichkeiten eingebaut:

  • null - Farblos aber nicht Schwarz, parameterunabhängige Farbe für Spurelemente
  • def-t - direkt von Parameter t abhängige Farbe
  • def-graph - vom Graphenwert(wählbar) abhängige Farbe untere und obere Grenzen werden über den Zoom festgelgt (2D-y-Graphen-Grenzen)
  • def-graph-p.m - auch vom Graphenwert abhängig nur noch eine zus. pos. neg. Unterscheidung

Der vierte Farbmodus ist noch nicht ganz Fehlerfrei da er noch nicht nach "oben" begrenzt ist (Rosette - tan).


Zum Zoom... ich habe die Datei erstellt und leide deshalb evtl. unter der "Schöpferblindheit", den Zoom in die x-Achse habe ich willentlich "blockiert"

den Zoom in die y-Achse nicht, da es ja ein "Eingabe-Arbeitsblatt" werden soll und ich demnach nicht festlegen kann wie die Graphen auszusehen haben.

Die Graphen können sehr Flach oder auch sehr "bergig"(?) sein je nachdem wie sie aussehen verändert sich das Hauptbild (3D-Graph).

Ich habe jedoch einen Schieberegler mit eingebaut welcher den Skalierungsfaktor manipuliert und die Graphen je nach Wunsch in y-Richtung streckt oder staucht

(zudem ist bei einem hohen Zoomfaktor links meist auch ein hoher Zoomfaktor rechts erwünscht).


Zum "Wenn-Befehl-Test" wie wäre es wenn du in den true-Zweig eine sehr laufzeitintensive Definition packst und in den false Zweig eine ganz einfache?

Wenn das Arbeitsblatt sowohl im true- als auch im false-Modus "bockt" dann hast du deinen Beweis, dass GGB immer beide Möglichkeiten berechnet aber nur eine "aktiviert".


Noch eine Kleinigkeit zu den "nicht sichtbaren Objekten" ich glaube, dass die unsichtbaren Objekte trotzdem immer mit berechnet werden

(eine Möglichkeit die Berechnung einzufrieren wäre da nützlich).


Was die 2D - Graphen betrifft ich werde sie wohl je nach Bedarf über Skripte definieren und wieder löschen, das scheint mir zumindest die beste Lösung zu sein.


Gruß

Loco

photo
1

Hier der Performance Test zur Überprüfung meiner These (False wird immer durchlaufen).

Ob richtig oder nicht richtig, weiss ich immer noch nicht. Statt dessen habe ich

eine neue These, die diese Fragestellung obsolet macht.


Siehe Beilage


Raymond


PS: ich klinke mich für ca. 2 Wochen ferienhalber aus.

https://ggbm.at/557989

photo
1

Hallo rami,

schöne Ferien.


Ich habe mit 'entsetzen' realisiert, dass meine Dateien bei dir noch längere Laufzeiten verursachen müssten,

da ich in deiner Perfomance-Datei nie über 5ms gekommen bin (aber auch komischerweise nie unter 1ms).


Was du mit mit "heap" meinst erschließt sich mir nicht, da ich keine tieferen Programmiererfahrungen habe.


Ich selbst hatte, in Hinblick auf mein Ziel, auch eine Datei erstellt.


https://ggbm.at/558029

Diese zeigt mir, dass sich die Laufzeit (beim Zoom) durch Änderung einer Wahrheitsvariablen verbessert, wenn die Definition "einfacher" wird.


Jedoch möchte ich in Hinblick auf meine Datei die Definition nicht vereinfachen sondern komplett einfrieren oder auf "undefiniert" setzen.

Das hat mich wiederum auf eine Merkwürdigkeit von GGB und die "Zusammenarbeit" von Wenn-Befehlen und begrenzten Funktionen stoßen lassen.

GGB kann einen Graphen (f(x)) über einen Wahrheitswert (a) auf undefiniert setzen.

    Wenn[ a , f ]

Wenn ich jedoch die Funktion im Wertebereich ([y(A),y(B)]) einschränke funktioniert das nicht mehr!

    Wenn[ a , Wenn[ y(A) <= f(x) <= y(B) , f] ]

Der Graph bleibt einfach definiert/unverändert egal wie ich den Wahrheitswert ändere (auch wenn ich die Ursprungsfunktion auf undefiniert setze), ist das ein Bug?

Übrigens wenn ich den Graphen ausblende verbessert sich die Laufzeit (was meine Ausblend-These wiederlegt?).


https://ggbm.at/558031

Wenn ich versuche diese Änderung über ein Skript zu realisieren, gibt es mehrere weitere Probleme (falsche Darstellung / Fehlermeldung / ...).

Eine andere Möglichkeit die rechenaufwendigen Elemente meiner Datei abzuschalten um "flüssiger" zu Zoomen fällt mir z.Z. nicht ein.


Ich werde weiter an meiner Datei basteln, muss nun aber nebenher auch das schriftliche zu meiner Arbeit erstellen.


Gruß

Loco


1. Nachtrag:

Wenn ich einen unbegrenzten Graphen (g) mit einem begrenzten Graphen (in y begrenzt) (h) über eine Wenn-Bedingung (Wahrheitswert : a) wechselnd austausche wird der Graph am Ende falsch angezeigt

(an undefinierten Stellen werden Bildpunkte bei y=0 eingezeichnet). Ist dies auch ein Bug?

    Wenn[ a , h , g ]

https://ggbm.at/558035


2. Nachtrag:

Ich habe nun eine Möglichkeit gefunden die Funktionskurven über Skripte so zu definieren, dass das Zoomen nicht mehr so zeitraubend ist (zumindest bei mir).

Ich Definiere sie einfach je nach Bedarf komplett neu, d.h. ich nutze nicht den "Setze-Wert"-Befehl sondern ich nutze das "=" in Verbindung mit dem Ausführen-Befehl.

Weiterhin vermute ich, dass die Pixelabhängigkeit der beschränkten Funktionen an der überhöhten Laufzeit schuld ist.

photo
1

Hallo hallo,

ich habe ein wenig an meiner Datei weitergearbeitet.

Das Ergebnis ist folgende Datei:


https://ggbm.at/558463

Jetzt ist meine Frage: Ist die Lösung welche ich für die radiale Begrenzung verwende eine sinvolle oder eher ungünstig?

Ich möchte deshalb nochmal nachfragen, da ich in einem Thread hier erfahren habe, dass die Neudefinition von Funktionen über die Eingabezeile ungünstig ist.

Ich wollte dies klären bevor ich mein AB neu aufbaue um es zu verbessern.


Parallel habe ich begonnen eine weitere Datei zu erzeugen welche primär auf die Berechnung von polaren Kurven im zweidimensionalen abzielt.

[attachment=0]Polarkurven - 2D -protot.8.ggb[/attachment]Hier bin ich auf einen Fehler gestoßen welchen ich nicht lokalisieren kann.

Das AB lässt sich nicht direkt (per doppelklick) öffnen und eine Prüfung mit GGB 4.2 weist mich auf einen Fehler in meinem Text hin.

Jedoch kann ich mir nicht logisch erklären wo dieser sein sollte.

Ich habe alle anderen Elemente gelöscht, um diesen Fehler einzukreisen, aber der Fehler verschwindet einfach obwohl keines der gelöschten Elemente einen Einfluss auf diesen hat.

[attachment=1]Polarkurven - 2D -protot.8 gelöscht.ggb[/attachment]

Über erfahrene Hilfe, unterstützende Hinweise oder hilfreiche Gedanken würde ich mich sehr freuen.

Gruß

Loco

https://ggbm.at/558467

https://ggbm.at/558469

photo
1


Parallel habe ich begonnen eine weitere Datei zu erzeugen welche primär auf die Berechnung von polaren Kurven im zweidimensionalen abzielt.

Hier bin ich auf einen Fehler gestoßen welchen ich nicht lokalisieren kann.

Das AB lässt sich nicht direkt (per doppelklick) öffnen und eine Prüfung mit GGB 4.2 weist mich auf einen Fehler in meinem Text hin.


Da ich einen ähnlichen Fehler in einer meiner Dateien gehabt habe (ich habe damals meine Datei neu erstellt) habe ich mich Stunden mit "Polarkurven - 2D -protot.8.ggb" erfolglos herumgeschlagen. Irgendwann machte ich mir einen Kaffee, während dem das Oeffnen der Datei immer noch loopte(?). Als ich zurück kam war das Arbeitsblatt geöffnet.

Ich habe es unter einem neuen Namen abgespeichert. Diese Version öffnet auf meinem Computer in 11 sec (mit GGB40). Das Oeffnen in GGB42 führt allerdings immer noch auf eine Fehlermeldung.

[attachment=0]Polarkurven - 2D -protot.8B.ggb[/attachment]

Ich habe eigentlich keine Ahnung warum es nun läuft. Aber ich vermute, dass dieser Fehler dann auftreten kann, wenn eine GGB40-Datei in GGB42 geöffnet und dann gespeichert wird um diese gespeicherte Version dann in GGB40 zu öffnen. Reproduzieren kann ich meine Vermutung nicht.

Warum der Fehler in GGB42 bezüglich dem Textfeld auftritt, habe ich nicht weiter verfolgt. Ich tippe mal ganz vorsichtig auf einen Bug in GGB42.

------------------------

Bezüglich Deinen inhaltlichen Fragen zum Arbeitsblatt fühle ich mich überfordert. Dein Arbeitsblatt hat einen Komplexitätsgrad, der es schier unmöglich macht sich in nützlicher Frist darin zurecht zu finden. Sich in eine komplexes (fremdes) Arbeitsblatt einzuarbeiten benötigt vermutlich um Faktoren mehr Zeit, als der Entwickler für dessen Erstellung benötigt hat. Und ich denke das waren Tage.

Da wären zusätzliche Features hilfreich: ausgiebige Kommentare, individuelle strukturierungs Möglichkeiten, erweiterte Abhängigkeits Abfragen (Ctrl-J) und die Anzeige von verschachtelten Befehlen in einer Baumstruktur.


Raymond

https://ggbm.at/558509

photo
1

Hallo rami,

danke dafür, dass du dir die Mühe gemacht hast den Fehler in meiner Datei zu suchen.

Ich konnte mich leider nicht so bald melden, da ich ein wenig Zeit reservieren musste und mich erst wieder einarbeiten musste.


Darauf, dass der "Fehler" sich in Wohlgefallen auflösen könnte wäre ich nie gekommen.

Ich hätte aber noch eine Frage zur Sicherheit: Hast du in der Datei Elemente, wie z.B. das kartesische Gitter gelöscht oder wurden sie automatisch Entfernt?

Auch möchte ich noch anmerken, dass ich die Datei erst zur Fehlersuche mit der Beta-Version GGB´s geöffnet habe.


Bezüglich der inhaltlichen Fragen, ja darauf sollte ich künftig mehr achten. Ich selbst brauche nach ein paar Wochen Pause schon mind. eine halbe Stunde um mich in dem Dschungel an Elementen, Verknüpfungen und Bedingungen zurechtzufinden.

Ich stelle daher drei Fragen welche mich im Zusammenhang mit dieser Datei beschäftigten und beschäftigen nochmal gezielter.

  • Ruckelt die Datei sehr? In dieser Hinsicht der "Zoom-Modus" laufzeitschonend oder kann ich mir dieses Feature sparen? (Anwendungsfrage)
  • Ich habe meinen Lösungsansatz für den "Zoom-Modus" (Graphenbeschränkung an/aus) extrahiert und ohne Extras in die folgende Datei gepackt:


    https://ggbm.at/558585

    Ist dieser Ansatz sinnvoll oder ungeschickt? Ich beziehe mich hier auf eine deiner Antworten in einem anderem Thread (Fehler durch "="-Neudefinition) und einen meiner vor-Posts.

  • Mir ist der Gedanke gekommen viele gleiche Elemente, wie z.B. die durch Folgen erzeugten Gitterlinien der Koordinatensysteme, in Listen zu packen (direkt über Befehle in den Listen) um sie leichter zu verwalten. Ist dies ungeschickt?


Mit dankbaren Grüßen

Loco

photo
1

Hallo rami,

Hast du in der Datei Elemente, wie z.B. das kartesische Gitter gelöscht oder wurden sie automatisch Entfernt?

Sie wurden "automatisch", also von GGB selbst entfernt.


Raymond


PS:

Die drei Fragen beantworte ich im Anschluss

photo
1

Zur Frage1 und Frage2:


Bezüglich "Polarkurven - 2D -protot.8.ggb" gibt es ja nichts zum ruckeln (ich habe wenigstens keinen Gleiter entdeckt), wenn man vom Zoom mit dem Scroll-Rad absieht. Das empfinde ich aber noch im erträglichen Rahmen. Was mehr stört: dass die Spur verloren geht. Da sehe ich aber keinen Lösungsansatz (ausser man würde das Zoomen blockieren, was sich machen liesse).


Bezüglich der Datei "Frage01":

Die Verzögerung bei den Gleitern A B C sind für mein Empfinden sehr störend. Ein sauberes Positionieren ist nur bedingt möglich.

Hier ein Lösungsansatz dazu.


https://ggbm.at/558589


Mathematisch nicht sehr hübsch aber performancemässig völlig unproblematisch:

Rechtecke mit dynamischer Grösse (abhängig von A, B, C) decken "das Abgeschnittene" opak oder halbtransparent ab.

In Kombination mit Ebenen könnte man aber mit nur einem Rechteck arbeiten, dessen Füllung auf invers gesetzt ist.


Ubrigens anstelle von A, B, C würden eigentlich zwei Punkte genügen: oben links und unten rechts.


Frage3:

Ich weiss es nicht, aber ich würde schätzen, dass diese starren Objekte in Listen nicht nur übersichtlicher sondern auch Laufzeit-günstiger sind.


Gruss

Raymond


PS:

Das Extrahieren der eigentlichen Problemstellung in eine separate Datei macht die Beantwortung Deiner Fragen extrem leichter.


Nachtrag zum Zoomen in der Datei "Frage001" (Lösungs-Idee):

Ob Ortslinie oder Kurve oder Funktion: das Zoomen wird immer ein Problem sein, solange die kritischen Funktionen/Kurven angezeigt werden.

Wenn das Zoomen nur per Schieberegler möglich wäre, dann könnte man bei Veränderung des Schieberglers die kritischen Objekte automatisch aus und dann wieder einblenden. Anstelle der Funktion/Kurve könnte man dann einen Platzhalter (Rechteck) einblenden.

photo
1

Eine andere Variante für die Lösung des Zoom-Problems:

Per Schaltfläche kann in den Modus Zoom oder Show gewechselt werden.

Im Zoom Modus werden anstelle der Funktionen Rechtecke angezeigt.

Im Show-Modus ist das Zoomen und Scrollen blockiert.


Raymond

https://ggbm.at/558591

photo
1

Hallo rami,

von deiner Lösung in der ersten Datei bin ich sehr angetan.

Ich werde diese Datei analysieren und die Lösung angepasst übernehmen.

Die Lösung mit den Rechtecken im Zoom-Modus behagt mir eher nicht, da ich es wichtig finde zu sehen wie weit man zoomt.


Den anderen Vorschlag mit den weißen Rechtecken habe ich bereits angedacht (wie bekomme ich eine weiße Fläche mit 3 dynamischen Fenstern hin?) und werde ihn evtl. nochmal aufgreifen.

Bei diesem Vorschlag müsste ich dann die Graphen fest positionieren und die Deckfläche über mehrere dynamische Rechtecke konstruieren.


Das Zoomen aus und einzuschalten oder und über Regler zu kontrollieren möchte ich evtl. auch ins Auge fassen, es werden sich aber denke ich dadurch eher mehr "Probleme" oder Einschränkungen ergeben.


Zu den drei Punkten in der "Frage 001.ggb"-Datei, die drei Punkte symbolisieren die Schieberegler welche das kartesische Koordinatensystem in den Abmessungen festlegen

und sind in den Projektdateien zusätzlich noch an die Pixel-pro-Einheit - Werte gebunden (verändern ihre y-Werte beim Zoom).

Diese Verzögerung macht sich in diesen Dateien also beim Zoom bemerkbar.


Das Gitter in "Polarkurven - 2D -protot.8.ggb" ist ein Beispiel des "Elemente in eine Liste packen´s", die Gitterlinien und die Umrandungen sind zusammen über eine Liste definiert (und dynamisch abhängig von mehreren Faktoren).

Auch die Skalenbeschriftung und die Achsen werden in Listen definiert. Deshalb macht mich das auch stutzig, dass GGB die Gitter gelöscht hat und ist für mich ein Indiz, dass diese Elemente für GGB "unbequem" sein könnten.


Die Frage nach dem Ruckeln war eigentlich auf die "Polarkurven - 3D v2.0.ggb"-Datei bezogen da sich die "Polarkurven - 2D -protot.8.ggb"-Datei noch im Aufbau befindet und gerade einmal ein Drittel des angedachten Inhalts enthält.


Trotz allem möchte ich mich für den genialen Lösungsansatz bedanken, ich kann ihn gebrauchen.


Mit dankbaren Grüßen

Loco

photo
1

(wie bekomme ich eine weiße Fläche mit 3 dynamischen Fenstern hin?)

Mit Ungleichungen.

Weitere Erläuterungen sowie eine Funktions-Lupe findet sich in:

http://www.geogebratube.org/material/show/id/20166


https://ggbm.at/558597


================================================

Die Lösung mit den Rechtecken im Zoom-Modus behagt mir eher nicht

Eigentlich geht es eher darum das Zoomen und Scrollen einzufrieren.

Aber: im Zoom-Modus sollten nur Objekte sichtbar sein, die nicht zeitkritisch sind.

Das könnte zB. auch die nicht abgeschnittene Sinus-Kurve sein, die mit einem Rechteck, das die Grenzen der Wenn[] Konditionen der Funktion aufzeigt, ergänzt ist.

================================================


Die Frage nach dem Ruckeln war eigentlich auf die "Polarkurven - 3D v2.0.ggb"-Datei bezogen

Die ruckelt beim Zoomen nach meinem Empfinden noch innerhalb der erträglichen Grenzen.

Als "unvoreingenommener, naiver" Betrachter irritiert mich beim Zoomen , dass die Gerade in der rechten Grafik optisch die Steilheit verändert (obwohl, oder besser gesagt: gerade weil mir klar ist, dass nur wenige in der Lage sind diese Raffinesse überhaupt zu würdigen :smiley_cat: )

photo
1

Hallo rami,

das mit den Ungleichungen war mir noch nicht bekannt, danke dafür.

Ich werde es mal analysieren und gegebenenfalls in meine Datei übernehmen.


Wie du das mit dem Rechteck meinst ist mir jetzt klar geworden und ich will

so etwas in der Art eventuell verwirklichen. Wie genau muss ich noch austesten und

hängt ganz davon ab wie ich die Datei weiter aufbaue

(Zoom-Modus-Schaltfläche / mit oder ohne Zoom-Sperrung, verzögerte Werteübernahme (deine Lösung 1) oder evtl. automatische Zoom-Erkennung ).


Ja wie ich nun mit dem zweitem Graphen umgehe werde ich mir auch noch überlegen müssen.

Die jetzige Lösung genügt mir selbst voll und ganz. Es gibt hier denke ich unterschiedliche Ansätze welche alle ihre

positiven und negativen (in meinen Augen) Seiten haben. Einer wäre die Gitter fest im Bild zu verankern und nur die Kurven "zoombar" zu machen (ähnlich einem Fernglas),

eine weiterer ist den Zoom zu verbieten und die Graphen über Schieberegler zu "zoomen".

Ich selbst bin eher dem erstem Ansatz zugetan sehe aber einige Probleme/Schwierigkeiten auf dem Weg zur Realisierung.

Im Grunde möchte ich einfach nur Kurven welche ihre Besonderheiten eher im oberen Bereichen oder in unteren Bereichen deutlicher im Koordinatensystem darstellen.


Ich denke ich werde diese Datei weiter aufbauen und dann noch eine und die Struktur so immer weiter vereinfachen (oder verkomplizieren durch mehr Features).


Mit freundlichen Grüßen

Loco

photo
1

In der Zwischenzeit habe ich (zu meinem Vergnügen) das Arbeitsblatt mit den Abdeck-Masken überarbeitet und mit einer "Funktions-Lupe" ergänzt.


Möglicherweise ist die "Funktions-Lupe" auch für Deine Zwecke hilfreich.


Raymond

https://ggbm.at/558625

photo
1

Hallo rami,

es dauerte mal wieder länger um zu Antworten.


Ich finde diese Datei hochinteressant, werde sie sozusagen auseinandernehmen und genau unter die Lupe nehmen.

Ich denke ich werde deinen Ansatz hier als Lösungansatz, für meine am Anfang gestellte Problemstellung, aufgreifen und weiterverfolgen.


Mit freundlichen Grüßen

Loco

© 2022 International GeoGebra Institute