gleichen Drehsinn von 2 Dreiecken erkennen

rami shared this question 2 months ago
Answered

Frage: wie erkenne ich in GGB möglichst einfach, dass zwei kongruente Dreiecke denselben Drehsinn haben.

Was ich meine ist optisch aus dem Anhang ersichtlich.

Hintergrund:

Ich möchte den Schüler eine Dreieckskonstruktion estellen lassen.

Dabei sind 3 Elemente des gesuchten Dreiecks vorgegeben.

Die Bezeichnungen der 3 Elemente folgen der Standardbezeichnung von Dreiecken (A,c,B,a,C,b gegen den Uhrzeigersinn)

In der Konstruktion (inklusive Benennung der Objekte) ist der Schüler in keiner Art und Weise eingeschränkt. Am Schluss muss ein entsprechendes Dreieck in beliebiger Lage aber im richtigen Drehsinn der vorgegebenen Dreieckselemente vorliegen.

Das funktioniert schon ganz gut (siehe hier) unter anderem unter zuhilfename des Befehls SindKongruent().

Damit sind (richtigerweise) aber auch gespiegelte Lösungen kongruent. Ich möchte aber nur ungespiegelte Lösungen (beliebige Lage aber im richtigen Drehsinn der vorgegegebenen Dreieckselemente) als gültige Lösung zulassen.

Uebrigens:

Der Befehl SindGleich() bringt keine Lösung (komisch, wozu wurde dieser Befehl kreiert)

Ich habe irgendwo im Hinterkopf, dass es eine Notation für Dreiecke gibt, die unabhängig von der Lage (inkl Drehung) ist. (Der Name dazu ist mir entfallen sonst würde ich das Thema in Wikipeda finden).

Comments (13)

photo
1

Salut rami! :)


Hmm, hier mal meine Gedanken:

Es wäre ja schön und hinreichend, wenn es gelingen würde zu garantieren, dass die Eckpunkte der beiden Dreiecke jeweils im gleichen Drehsinn aufgelistet werden würden, denn dann könnte man auch die Seitenlängen als Differenz der Eckpunkte jeweils im gleichen Drehsinn auflisten.

Wenn die Seitenlängen des Schülerdreiecks in einer der drei zyklischen Vertauschungen - also (a,b,c) oder (b,c,a) oder (c,a,b) - des Musterdreiecks auftauchen, dann sind das Schüler- und das Musterdreieck auch im gleichen Drehsinn kongruent zueinander.


Lösungsidee:


Wenn man den Umkreis des Dreiecks mit dem Dreieck schneidet, dann sind das selbstverständlich die Eckpunkte des Dreiecks.

Ich vermute/hoffe aber nun, dass die Eck- bzw. Schnittpunkte immer entsprechend einem bestimmten Drehsinn, also mit oder gegen den Uhrzeigersinn aufgelistet werden und dann wäre ja das zuvor geschilderte Problem mit der Reihenfolge der Punkte gelöst.


Um den Umkreis schnell und bequem angeben zu können, braucht man den Umkreismittelpunkt nicht erst aufwändig zu konstruieren, sondern man kann den Befehl Dreieckspunkt(<Punkt>, <Punkt>, <Punkt>, 3) verwenden, denn die Punkte der Dreiecke sollten ja bekannt sein und da kommt es auch nicht auf die Reihenfolge an..

Guckst Du hier: https://wiki.geogebra.org/d...

Na ja, und dann habe ich vom gesuchten Umkreis den Mittelpunkt und weiß ja, dass er noch durch alle drei Eckpunkte geht und kann ihn so explizit angeben.


Ergänzung:


Ich habe gerade mal ein wenig damit rumgespielt und es scheint im Prinzip zu funktionieren.

Die Schnittpunkte werden, wie es scheint, entgegen dem Uhrzeigersinn aufgelistet und zwar beginnend bei dem Punkt, den ich als Referenzpunkt neben dem Umkreismittelpunkt für den Umkreis angegeben habe.

So weit, so gut.

Leider werden aber die Punkte dopppelt angegeben und zwar, wenn A mein Referenzpunkt für den Umkreis ist, in der Reihenfolge A,B,B,C,C,A.

Hmm, das doppelte Auftauchen der Punkte liegt vermutlich daran, dass der Kreis einmal mit dem kompletten Dreieck und dann nochmal separat mit der Menge der Eckpunkte geschnitten wird.

Da gibt es doch bestimmt auch eine nicht allzu aufwändige Lösung, um diese Liste dann zu reduzieren ohne die Reihenfolge zu zerstören ...


Ich hoffe, das reicht als Ideen-Input und hilft wirklich weiter.


Gruß

mire2

photo
1

Hallo mire2

Herzlichen Dank für Deinen Input.

Entscheidend scheint mir: "die Punkte müssen im gleichen Drehsinn vorliegen."

Ich mache mich mal mit diesen Ideen auf den Weg und melde mich wieder.

Gruss

Raymond


PS:

Einzigartig(<liste>) ist vermutlich eine Lösung für die doppelten Punkte

Und dann könnte/sollte/müsste man die Punkte auf dem Kreis noch nach dem Pfadparameter sortieren, dann bräuchte man bezüglich dem Drehsinn der Punkte nicht zu "vermuten/hoffen".

photo
1

Es scheint zu funktionieren.

Für die Lösung habe ich ein CustomTool erstellt, das pro Dreieck aufgerufen wird. Das Tool gibt eine Liste von Winkeln zurück. Damit kann für zwei Dreiecke und deren Winkel-Listen auf Ähnlichkeit und Drehsinn getestet werden. Das CustomTool is so ausgelegt, dass es auch für Polygone (konvex, nicht überschlagen) genutzt werden könnte (ungetestet!)

Das ist der Grund warum ich mit dem Schwerpunkt und einem dazugehörigen Einheitskreis arbeite (anstelle des Umkreises). Ich hege die leise Hoffnung, dass damit auch konkave Dreiecke abgedeckt sind (wie gesagt: ungetestet)

Das CustomTool ist im Anhang InAng02.ggb resp InAng02.ggt (zum Einbinden, ohne Kommentar)

Für das Testen von InAng02 habe ich das im Thread Kopf gezeigte Beispiel ausgebaut, sodass alle (?) Konstellationen getestet werden können. Alle von GGB vorgesehenen Automatismen um die Reihenfolge der Eckpunkt (und deren Innenwinkel) sinngemäss zu erhalten habe ich mit Mischen() umgangen, sodass auch exotisch erzeugte Transformationen funktionieren sollten. Dieses Applet hat praktisch nichts mit der Lösung zu tun. Der ganze Code den man benötigt steckt in InAng02 sowie den drei Wahrheitswerten in der Testumgebung alle Hilfsobjekte brauchen nicht zu interessieren.

Die Testumgebung ist im Anhang unter SindGleichdrehend03.ggb

photo
1

Und im Anhang noch eine Variante, die das macht, was "SindGleich()" bereits von Haus aus machen müsste.

Noch besser wäre ein zusätzlicher Befehl SindÄhnlich() sodass die Rücktransformation bezüglich "Strecken" in SindGleich() entfallen würde.


Damit lassen sich konkave und/oder überschlagene Polygone analysieren.

"SindKongruent() && SindGleich()" entspricht dann "Gleichdrehend"

photo
1

Meldung in SindGleichPolyg01.ggb: "Streckenzentrisch UND drehen leider zu ungenau!!" (berechnet)

Stimmt nicht: es ist ein Vorzeichenfehler beim zurückdrehen

Als Anhang eine Version ohne diesen Fehler und einigen Verbesserungen/Detaillierungen (ohne das Prinzip zu ändern)

.

PS1: bei Gelgenheit werde in ein CustomTool in mein public GGTube stellen.

PS2: Was, um alles in der Welt, hat "SindGleichdrehend" (usw) mit "Handelsreisenden" zu tun?

Dieser Befehl findet in einer PunkteWolke unabhängig von PunkteReihenfolge, Lage und Transormation immer (?) denselben Pfad mit demselben Start- und Endpunkt. Damit kann an den beiden Figuren v1 und v2

sinngemäss an derselben Stelle ein Vektor kreiert werden, der die Rücktransformation ermöglicht.

.

PS3: Feedback jeglicher Art erwünscht (zB. Vereinfachungen, Fehler, Zusatzfeatures)

photo
1

Hallo Raymond!


Es macht mir wirklich große Freude, das zu lesen.

Ich bin jetzt erst einmal noch bei dem Problem mit dem Dreieck und musste feststellen, dass die Angabe der Schnittpunkte von Umkreis und Dreieck in Wirklichkeit gar nicht immer gegen den Uhrzeigersinn geschieht.

In Wirklichkeit werden Punkte in der Reihenfolge des Dreiecks angegeben, d. h. wenn ich das Dreieck durch A, B, C mal in der Reihenfolge A, C, B angebe, dann kommen auch in der Reihenfolge die Schnittpunkte. Damit ist natürlich auch die Idee mit dem gleichen Drehsinn obsolet.

Deshalb ist Deine Idee, das durch den Pfadparameter des Kreises zu ersetzen, wirklich super, denn der sorgt dafür, dass der Kreis immer gegen den Uhrzeigersinn durchlaufen wird.

Dass Du jetzt sogar darüber hinaus gedacht hast und dann gleich allgemeine Vielecke auf den Richtungssinn prüfen willst, finde ich klasse.

Das habe ich mir allerdings noch nicht genau angeschaut, allerdings ist mir schon bei den Dreiecken, als Du den Pfadparameter ins Spiel gebracht hast, eine noch etwas unausgegorene Idee gekommen, die das Ganze evtl. vereinfachen könnte.

Ich werf die jetzt mal in den Raum und die veredelst das dann wieder zu Gold. :smile:


Idee:


Damit zwei Vielecke mit der Eckenanzahl n kongruent zueinander sind, müssen 2n-3 "Bestimmungsstücke" übereinstimmen. ( https://de.wikipedia.org/wiki/Kongruenz_(Geometrie)#Kongruenz_von_n-Ecken )


(Bei Dreiecken genügen deshalb bereits drei Winkel oder drei Seitenlängen alleine.)

"Nicht nur Seitenlänge oder Winkelmaß können Bestimmungsstücke sein, sondern auch Inkreisradius, Umkreisradius, Höhe, Länge einer Seitenhalbierenden, Fläche etc." (Wikipedia im Abschnitt oberhalb des angegebenen Links)


Wenn man nun vom Schwerpunkt eines Polygons ausgeht, der ja quasi von GeoGebra frei Haus geliefert wird, und dann von den Abständen der Eckpunkte zu diesem Schwerpunkt das Minimum (oder auch das Maximum) bestimmt, dann hätte ich einen Startpunkt für das Aufzählen der Eckpunkte des Polygons.

Du sortierst also Deine Liste Scheitel(Vieleck) so, dass sie bei dem Punkt mit dem maximalen/minimalen Abstand startet.


Die Aufzählung kann nun mit oder gegen den Uhrzeigersinn geschehen, je nachdem, in welcher Reihenfolge die Eckpunkte des Polygons bei der ursprünglichen Konstruktion durchlaufen wurden.

Nehme ich jetzt mein "Original-Polygon", dann kann ich damit eine Liste der Innenwinkel und der Polygonzüge beginnend vom Eckpunkt mit dem extremalen Abstand zum Schwerpunkt erstellen und hätte damit schon mal die ausreichende Anzahl an Bestimmungsgrößen, um die Kongruenz zu einem weiteren Polygon zu überprüfen.


Dann nehme ich jetzt mein "Prüf-Polygon" und weiß auch hier, bei welchem Eckpunkt ich starte und erstelle ebenfalls eine Liste der Innenwinkel und eine Liste der Polygonzüge.

Wenn diese beiden Listen nun direkt oder in umgekehrter Reihenfolge mit den beiden Listen des "Original-Polygon" übereinstimmen, dann sollten diese schon einmal kongruent sein.


Nun zum Drehsinn.

Wenn Du einen Kreis mit dem Schwerpunkt als Mittelpunkt nimmst, die durch den Eckpunkt mit maximalen Abstand zum Schwerpunkt nimmst und es irgendwie hinbekommen würdest, dass dort der Pfadparameter = 0 ist, dann starten Deine "Umkreise durch den Schwerpunkt" an derselben Stelle und haben denselben Drehsinn, nämlich halt gegen den Uhrzeigersinn.


Damit sollte es Dir möglich sein, eine Folge von Pfadparametern Deiner Eckpunkte zu bekommen, die Du bei der Ecke mit dem maximalen Abstand starten lässt, also auf jeden Fall mit Null anfängt, Wenn diese Folgen identisch sind, dann sollten die Polygone es auch sein.


Hmm, das liest sich jetzt vielleicht etwas wirr und aufwändig an, aber ich glaube, dass das in Wirklichkeit gar nicht so schwer in GeoGebra zu realisieren sein sollte, jedenfalls für Dich, Raymond. :smile:

Über so "exotische" Fälle wie die Nichteindeutigkeit des Eckpunkts mit minimalem oder maximalem Abstand habe ich mir noch keine weitere Gedanken gemacht.


Sonntägliche Grüße

Michael

photo
1

Hallo Michael

Ich meine ich habe Deine Idee fast genau so in diesem Post realisiert (oder ich habe Dich falsch verstanden)

InAng02.ggt enthält die Drehsinn-Logik (besser erkennbar, da mit Kommentar in InAng02.ggb)

.

l1=) Als Input erhält das Custom-Tool eine Liste mit den Eckpunkten eines der beiden Dreiecke (Vielecke). Die Reihenfolge der Eckpunkte ist beliebig.

.

l2=) Um den Schwerpunkt des Vielecks wird ein Einheitskreis erstellt. Die Eckpunkte werden mit NächsterPunkt() auf diesen Kreis "projiziert". Das ergibt eine Liste mit den Pfadparametern der Eckpunkt. Diese Liste wird in den folgenden Schritten als Sortierkriterium beigezogen. (Anmerkung: damit ist zwar die Reihenfolge bestimmt aber es ist noch nicht bestimmt welches der erste Wert in der Output-Liste sein wird)

.

l3=) Die Eckpunkte aus l1 werden in die Reihenfolge der Pfadparameter aus l2 gebracht.

.

l4=) Erstellt ein (nicht benanntes) Vieleck aus l3 und davon eine Liste der Innenwinkel dieses (neuen) Vielecks

Diese Innenwinkel liegen zwar in der gewünschten Reihenfolge vor (gegen Uhrzeiger, entsprechend der Pfadparameter) aber der erste Eintrag in dieser Liste ist noch unbestimmt.

.

l5=) Das Kriterium um den ersten Eintrag in der Liste zu bestimmen sei die kleinste Grösse aller Winkel. Diese wird mit

l4MinInd = IndexVon(Min(l4), l4)

als Wert (Min(l4)) und anschliessend mit IndexVon() als Index in die Liste l4 zeigend ermittelt. Damit ist es möglich eine Rotation der Liste l4 vorzunehmen, sodass der kleinste Winkel an erster Stelle steht UND die Reihenfolge gegen den Uhrzeigersinn immer noch erhalten bleibt.

l5 bildet sich mit Teilliste(l4, l4MinInd) ab dem kleinsten Winkel bis ans Ende von l4 und daran anschliessend der wegrotierte Teil vom Beginn von l4 bis ein Element VOR dem kleinsten Winkel mit dem Teilbefehl: Erstes(l4, l4MinInd - 1)

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

Wie gesagt obiges CustomTool wird mit beiden Polygonen (t1, t2) aufgerufen, sodass zwei listen vorliegen die beide die Innenwikel, gegen den Uhrzeiger und beginnend mit dem Kleinsten enthalten. Sind beide Listen gleich so sind die beiden Polygone gleich drehend (also nicht gegenseitig gespiegelt). Diese Aussage gilt aber nur dann, wenn gleichzeitig die beiden Vielecke ähnlich sind. Das lässt sich bestimmen indem man vergleicht: Sortiere(l4 von t1) == Sortiere(l5 vom t2) bei Gleichheit sind die Dreiecke (oder Vielecke ?) ähnlich. Sind die beiden Vielecke nicht ähnlich so kann man keine Aussage über den gemeinsamen Drehsinn treffen.

.

Ich bin recht optimistisch, dass die obige Realisierung für Dreiecke in allen Fällen funktioniert.

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

Beim Testen von obigem Konzept bin ich über konkave und überschlagene Vielecke gestolpert. Dafür habe ich auf Anhieb mit dem Pfadparameter-Konzept keine Lösung gefunden (Diesen Faden werde ich aber nochmal aufnehmen). Deshalb habe ich nach einem neuen Konzept gesucht, das die Reihenfolge der Eckpunkte nicht berücksichtigen muss und stattdesen immer das ganze Vieleck als Figur im Fokus hat. Lese dazu diesen und diesen Post und betrachte anschliessend das Testapplet "SindGleichPolyg02.ggb" (die Testumgebung und die Ermittlung von Gleichsinnig ist hier noch nicht in ein CustomTool ausgelagert. Die Tests dazu sind aus meiner Sicht auch noch nicht ganz vollständig [Grenzwerte mit 3- und 5-Eck sowie nicht ähnliche Vielecke. eine weitere Frage ist, welche Transformations-Typen zusätzlich berücksichtigt werden sollen und warum ja resp warum nein. zB.: gescherte Vielecke sind nicht (?) ähnlich, der Vergleich des Drehsinnes ist nicht sinnvoll/möglich (?)])

.

Ich neige dazu, dass dieses zweite Konzept sich als übersichtlicher und robuster als das erste Konzept herausstellen wird.

.

Gruss

Raymond

photo
1

Hallo Raymond!


Oh Mann, Du haust Dich ja echt rein.

Super!


Leider kann ich das jetzt gerade nicht in der Art und Weise würdigen, wie Du das verdient hättest, aber dennoch ein paar kurze Bemerkungen und ich hoffe, dass der Ansatz halt für beliebige Polygone, sei es nun überschlagend oder sonstwie, funktioniert.


Das Kriterium "Pfadparameter" und danach sortieren reicht nicht, um überhaupt Kongruenz von Vielecken zu gewährleisten.

Wenn Du das folgende Bild anschaust, dann erkennst Du, dass bei den beiden Vielecken alle Ecken bei der Projektion auf den Einheitskreis denselben "Pfadparameter" haben und das sogar noch bei Bedarf in der selben Reihenfolge.

(Ok, der Schwerpunkt ist zwar nicht derselbe, aber das kann man theoretisch organisieren, indem man eine einzige Ecke entsprechend weiter nach innen oder außen schiebt)

28e5b6fceb0a1b73d1222bafb396909a

Dadurch, dass Du die Eckpunkte beim Überprüfen "nur" permutierst, hast Du natürlich immer die gleichen Winkel und Seitenlängen, aber das kannst Du bei zwei beliebigen Vielecken nicht voraussetzen, sondern sollte für das Testen auf Kongruenz als erstes geprüft werden, denke ich.


Wenn ein n-Eck lediglich maximal 2n-3 freie "Bestimmungsgrößen" hat, dann ist es durch die Angabe von 2n-2 Größen schon bis auf Kongruenz eindeutig bestimmt.

Beim Dreieck ist also dieses durch vier Größen bestimmt, drei können, müssen aber nicht reichen. Zum Beispiel reicht die Angabe von drei Seitenlängen, aber nicht die Angabe der drei Winkel.


Wenn Du nun die Listen der n Innenwinkel und Seitenlängen miteinander vergleichst, weißt Du schon, ob sie kongruent sind oder nicht.

Da ist dann auch keine Sortierung nach Pfadparametern nötig und es ist auch egal, ob das n-Eck konkav oder konvex ist.


Das macht es doch für das ausstehende Problem schon einmal ganz interessant, denke ich. :smile:


Wenn man nun geprüft hat, dass die n-Ecke kongruent zueinander sind, na dann geht es "nur noch" um die Frage nach dem gleichen Drehsinn - ja oder nein.


Gehen wir nun über zu dem Kreis mit dem Schwerpunkt als Mittelpunkt.

Starten wir nun die Kreise beim original n-Eck und dem zu prüfenden n-Eck an derselben Stelle - also dass dort dann der Pfadparameter Null ist, beispielsweise indem wir die minimal oder maximal entfernte Ecke nehmen (in dem Glauben, dass die eindeutig ist).

Dann beginnen wir genau dort mit der Aufzählung der Ecken des n-Ecks und erstellen die beiden dazugehörigen Pfadparameterlisten.

Sollten diese identisch sein, dann wären die n-Ecke auch dem Drehsinn nach gleich.

Da muss man, denke ich, gar nicht mal die Innenwinkel oder sonstiges mehr umsortieren.

Die einzige technische Schwierigkeit besteht jetzt darin, zu gewährleisten, dass der Pfadparameter an der entsprechenden Stelle des Kreises auch wirklich auf Null liegt.

Meines Wissens nach liegt der Pfadparameter bei Null für den Punkt, der links vom Mittelpunkt liegt und denselben y-Wert wie dieser hat. Dann müsste man diesen Wert immer nur entsprechend verschieben.


Gruß

Michael

photo
1

Guten Morgen!


Kann es sein, dass wir das Ganze nicht viel zu kompliziert angehen?

Reicht es nicht, die zwei Vielecke zur Deckung zu bringen und dann zu prüfen, ob sie gleich sind?


Also wenn wir Vieleck1 und Vieleck2 haben, dann verschieben wir den Schwerpunkt von Vieleck2 auf den Schwerpunkt von Vieleck1.

Anschließend drehen wir dann das verschobene Vieleck2 so, dass die Ecke mit extremalen Abstand vom Schwerpunkt auf die Ecke mit extremalen Abstand vom Schwerpunkt von Vieleck1 liegt.

Das so verschobene und gedrehte Vieleck2 prüfen wir nun auf Gleichheit mit Vieleck1.

Das klingt doch wesentlich plausibler und handlicher.


Gruß

mire2

photo
1

Hallo Michael

Sorry, ich war gerade intensiv in einem anderen Thread und habe Deinen vorletzten Post übersehen.

Zum Post "viel zu kompliziert"

Ja, diese Idee habe ich ebenfalls verfolgt, allerdings mit dem Vektor, der aus Handelsreisender hervorgeht.

Deine Idee vom längsten Abstand (Schwerpunkt, Ecke; als Alternative zum Handelsreisenden) gefällt mir. Es kann ja ein beliebiger Eckpunkt sein, er muss nur bei beiden Vielecken "derselbe" Stelle sein. Was ich noch prüfen will: gibt es Situation wo es für beide Vielecke nicht eindeutig ist (gespiegelt, gleichseitig usw).

Und ja, man könnte es vereinfachen indem man zB die Frage nach "gespiegelt" nicht untersucht (in diesem Fall ist ja der gleiche Drehsinn nicht gegeben.). Aber eigentlich habe ich mir vorgenommen alle (was immer auch das heissen möge) abzudecken.

Zum Post "Das Kriterium "Pfadparameter" und danach sortieren reicht nicht"

Das ist eine heisse Frage / Entdeckung.

Ich weiss (noch) nicht ob sie zutrifft oder nicht. Das muss ich mir genauer überlegen. Ich melde mich wieder dazu (eher morgen, denn heute).

Falls ja wäre das ein wirklich wertvoller Beitrag Deinerseits. Falls nein, ebenfalls da ich gedanklich tiefer rein komme.

.

Gruss

Raymond

photo
1

Ok, das klappt schon wirklich gut, so wie das angedeutet wurde.

Ich würde daraus gerne ein Tool basteln, das für beliebige n-Ecke funktioniert, aber das bekomme ich leider nicht hin, sondern immer nur etwas für eine ganz bestimmte Eckenanzahl.


Was das Tool machen soll:


- den Schwerpunkt des n-Ecks Vieleck in den Ursprung verschieben: Vieleck1 = Verschiebe(Vieleck, -Vektor(Schwerpunkt(Vieleck)))


- danach dann das Vieleck so ausrichten, dass die Ecke mit minimalem Abstand vom Ursprung auf der positiven x-Achse liegt.


Dazu bestimmen wir die Liste der Eckpunkte des verschobenen n-Ecks mit: Eck={Scheitel(Vieleck1)}

Von dieser Liste bestimmen wir die Abstände zum Ursprung mit: Dist=Folge(Länge(Vektor(Eck(k))), k ,1, Länge(Eck))


Dann suchen wir den minimalen Abstand und lassen uns dessen Index geben: m = IndexVon(Min(Dist),Dist)


Nun drehen wir das Vieleck1 so, dass die dazugehörige Ecke auf der positiven Seite der x-Achse liegt mit: Vieleck2 = Drehe(Vieleck1, Winkel(Eck(m)))


Wenn ich nun zwei verschiedene Vielecke V und W miteinander vergleichen will, dann wende ich auf jedes einzeln diese Befehlsfolge an und frage anschließend: SindGleich(V2, W2) = ???

Der SindGleich-Befehl prüft dann wohl numerisch, ob die Eckenliste und die Längenliste oder Winkelliste identisch sind, um dann zu dem Ergebnis zu kommen, ob denn die Vielecke wirklich identisch sind.

Deshalb gibt er auch beispielsweise bei zwei verschiedenen Quadraten der Kantenlänge 1 Q1 und Q2 SindGleich(Q1,Q2) = false.


Das funktioniert auch bei, soweit ich das geprüft habe, bei sich überlappenden Vielecken, wobei da der Schwerpunkt an einer ganz merkwürdigen Stelle zu liegen scheint.


Nun würde ich das Ganze gerne als Tool für beliebige n-Ecke haben wollen, aber das bekomme ich einfach nicht hin.


Als Eingabe könnte ich mir eine Liste von Punkten, nämlich die Liste der Scheitel eines Vielecks, vorstellen oder auch die Angabe der Eckenzahl und dann die Ecken, aber wie gesagt, da fehlt mir irgendwie eine Idee zu, dass das für beliebige n klappt.


Gruß

mire2


PS: Wenn es zum minimalen/maximalen Abstand einen Punkt gäbe, der bei jedem n-Eck eindeutig von der Lage unabhängig ist, also wie z. B. der Schwerpunkt, dann würde ich diesen natürlich bevorzugen, denn es kann ja durchaus mehrere Punkte mit demselben minimalen/maximalen Abstand geben.

photo
1

Wenn ich da frei assoziierend was dazu sagen soll (oder besser nicht?):

Ein kleines Kind, das geometrische Figuren (Kreis, Dreieck, Stern usw) durch/in entsprechende Schablonen stecken soll, sodass sie im Kasten (Schublade) verschwinden, dann macht es (so vermute ich) genau das nicht, was Du da vorschlägst. Ich denke es versucht das Objekt als ganzes, unabhängig von seiner Lage (ja sogar Perspektive) zu "erkennen", dann ist es ein kleiner Schritt das Objekt am richtigen Ort einzupassen.

Etwas konkreter: es bräuchte eine Notation, die ein Polygon unabhängig von seiner Lage (Verschiebung, Drehung Spiegelung und zentrischer Streckung) beschreiben könnte. Und eine Notation die ohne Anfang und Ende auskommt und vermutlich (eher sicher ?) sich nicht der euklidischen Geometrie bedienen würde. Vektoren ist das Beste was mir dazu einfällt, aber vermutlich immer noch ungenügend.

photo
photo
1

Vielleicht hast Du ebenfalls Probleme mit diesem Bug.

https://help.geogebra.org/t...

© 2019 International GeoGebra Institute