Benutzer:B. M., CH-Riehen/Lonpos-Diskussion

Hinweis: Du darfst diese Seite editieren!

Ja, wirklich. Es ist schön, wenn jemand vorbeikommt und Fehler oder Links korrigiert und diese Seite verbessert. Sollten deine Änderungen aber dem Inhaber dieser Benutzerseite nicht gefallen, sei bitte nicht traurig oder verärgert, wenn sie rückgängig gemacht werden.
Wikipedia ist ein Wiki, sei mutig!

Vorgeschichte

Am 01.11.2012 schrieb Puzzler~dewiki die folgenden Lösungszahlen in den Lonpos-Artikel: «Rechteck 92755, Dreieck 16144, Pyramide 5x5 306, Pyramide 4x4 23». Bereits am nächsten Tag löschte Anka Friedrich diesen Eintrag (Selbstdarstellung: «Anka, die Hundespezialistin»). Gut zwölf Monate später bin ich in der Versionsgeschichte zum Lonpos-Artikel auf dieses eintägige Intermezzo gestossen, und in der Folge habe ich in einer vergnüglichen Programmierübung drei der vier unterdrückten Zahlen überprüft und für richtig befunden. Das damals entwickelte Java-Programm habe ich in diesen Tagen an das Dreiecksproblem angepasst und damit auch die vierte von Puzzler~dewiki genannte Zahl bestätigen können.

Die Diskussionsbeiträge von Dominik Vilsmeier und Cmuelle8

Da ich unabhängig von Puzzler~dewiki zu den gleichen Zahlen gekommen bin wie er, halte ich sie für gesichert. Für das Dreieck hat als «Dritter im Bunde» auch Cmuelle8 die gleiche Anzahl errechnet. Für die Viererpyramide stelle ich mein Programm und die 23 Lösungen unter ‹cl.ly/3P2R0n443x3U› zur Verfügung, und die gleichen Belege für das Dreiecksproblem findet man unter ‹cl.ly/1U2H240U383m› , hier allerdings in der Liste der gefundenen Lösungen nur jede tausendste.

In der Vormittags-Version vom 03.01.2016 des Lonpos-Artikels wird behauptet, das Dreiecksproblem habe 13568 Lösungen. Am Abend des gleichen Tages ist diese Aussage ersetzt durch «… gibt es laut Spielanleitung 22.469 verschiedene Lösungen», und die Zahl 13568 hat sich in eine Fussnote verkrochen. So liest man es bis heute. Damit aber nicht genug: Mit seinem JavaScript-Programm (Version vom 21.03.2016) findet Cmuelle8 16144 Lösungen. Das ist die Zahl, die Puzzler~dewiki 2012 nannte und die mir in diesen Tagen auch mein Programm geliefert hat. Diese verwirrenden Angaben müssen geklärt werden.

Cmuelle8 berichtet, dass sein Programm für das vollständige Lösen des Dreiecksfalls «auf einer modernen Maschine unter 10.000 s benötigt». In einem ersten Anlauf lese ich die angegebene Rechenzeit als «auf ein halbes Tausendstel genau zehn Sekunden». Das würde mir imponieren; denn mein Programm braucht auf einer sechs Jahre alten Maschine für die gleiche Arbeit 36 Sekunden. Im zweiten Anlauf indessen kommt mir die Vermutung, dass der Punkt zwischen den Ziffern diese gruppieren soll und gar kein Dezimalpunkt ist. Also zehntausend Sekunden? Dann wäre es vielleicht besser, das Programm nicht zu publizieren. Jetzt interessiert mich natürlich, wie schnell Dominik Vilsmeiers C++-Programm rechnet. Über seine vier Zahlen berichtete Puzzler~dewiki am 02.11.2012: «Die gesamte Berechnung nahm ca. 6 Monate in Anspruch!»

Zu Dezimaltrennzeichen und Tausendertrennzeichen Folgendes: «Das Dezimaltrennzeichen (beispielsweise der Dezimalpunkt oder das Dezimalkomma) ist im Dezimalsystem ein Zeichen, das die Grenze zwischen dem ganzzahligen Teil und dem gebrochenen Teil einer Zahl angibt» und «Neben dem Dezimaltrennzeichen gibt es auch das Tausendertrennzeichen (in Deutschland ein nicht umbrechendes „Geschütztes Leerzeichen“), das die Lesbarkeit großer Zahlen verbessert, indem die Ziffern in Dreiergruppen zusammengefasst werden». Für die Zifferngruppierung gilt aber auch: «Abweichend von den Tausenderblöcken gruppiert man lange Ziffernreihen auch in Fünferblöcken»; daran orientiert sich meine Praxis.

Streiten könnte man auch über die Zählung der Lösungen. Folgendes halte ich für selbstverständlich: Ein und dieselbe pyramidenförmige Anordnung der Puzzleteile ist als Lösung einfach zu zählen und nicht achtfach, nur weil man sie von Norden, Osten, Süden und Westen sowohl direkt als auch im Rückspiegel sehen kann. Im Gegensatz zu Dominik Vilsmeier halte ich es nicht für nötig, extra zu erwähnen, dass in der Liste aller Lösungen jede Äquivalenzklasse kongruenter Konfigurationen mit einem ihrer Repräsentanten dargestellt ist und somit als eine und nur eine Lösung zählt. Aus dem gleichen Grund halbieren Puzzler~dewiki und ich die Zahl 32288 von Cmuelle8.

Beurteilung des bestehenden Lonpos-Artikels

Es scheint mir wünschenswert, dass der Lonpos-Artikel mit sanften Änderungen verbessert wird. Wer in einer Enzyklopädie eine Begriffserklärung sucht, verfügt zwar meist über ein minimales Vorwissen; aber er wird sich dieses gerne durch eine explizite Begriffsdefinition bestätigen lassen, und der Unwissende darf eine solche erst recht erwarten. Wenigstens sollte gezeigt werden, wie die Puzzleteile aussehen, und es sollte deutlich gemacht werden, dass es die spezielle Gestalt der Puzzeteile ist, die Lonpos so attraktiv macht. Die Teile sind zusammengesetzt aus 3, 4 oder 5 durch Berührung zusammenhängenden Kugeln, deren Mittelpunkte in Gitterpunkten eines quadratischen Gitters liegen. Das ermöglicht es, mit den Puzzleteilen ausser ebenen auch räumliche einfach zusammenhängende Gebiete zu füllen. Dabei müssen die Ebenen der Mittelpunkte nicht alle untereinander parallel sein, sie können auch zu zweien zu einander seknkrecht stehen. Die vierseitigen Vierer- und Fünferpyramiden sind optimale Kugelpackungen. Für wenig attraktiv halte ich die umfangreiche Tabelle, in der von 88 Kästchen 50 leer sind und die anderen zur Charakterisierung von Lonpos überhaupt nichts beitragen. Dass der Kommerz Varianten zur Aufgabenstellung produziert, versteht sich von selbst.

Schlussfolgerung

Hiermit ist die von Dominik Vilsmeier («Ist es möglich den Quellcode …?») und Cmuelle8 («Gibt es Gegenstimmen, …?») angestossene Diskussion eröffnet. Ich schlage vor, dass wir sie hier auf meiner Benutzerseite unter «Diskussion» austragen. – B. M., CH-Riehen (Diskussion) 19:40, 31. Mär. 2016 (CEST)

Die obigen Abschnitte sind informativ, aber es ist zumindest für mich nicht erkennbar, was nun Diskussionsgegenstand sein soll. Wenn Du mit dem Artikel unzufrieden bist, dann schreibe doch einfach direkt Vorschläge, was du wie ändern möchtest.

Deine Ansicht, kongruente Lösungen sollten nicht erwähnt werden, musst du für Wikipedia ad acta legen, denn du solltest keine Annahmen über deine Leserschaft treffen - oder anders: Wikipedia ist für alle da, nicht nur für mathematisch begeisterte Menschen. Das heißt, wenn durch Spiegelung erzielbare Lösungen nicht gezählt werden, muss/sollte der Artikel die Symmetrien des Spielfelds erklären und dann angeben, ob solche Lösungen bei der Zählung aller möglichen Lösungen berücksichtigt werden, oder nicht. Das Ziel von Wikipedia ist nicht, dem Leser eine Weltformel an die Hand zu geben, sondern explizite, einfach(st) verständliche Information zu einem geg. Lemma bereitzuhalten. Gerade die Mathematik vergnügt sich dem entgegen häufig mit der Übung Zwischenrechnungen durch Symbole zu chiffrieren, die dem fachkundigen Leser bekannt sind, aber Gelegenheitslesern i.d.R. unergründlich sind und unnötigerweise abstoßen.

Zum "Dezimalpunkt": Im deutschen Sprachraum ist das Komma Trennzeichen der Dezimalstellen. Wenn also nicht gerade Programmcode zitiert wird, bist du in der deutschen Wikipedia gut beraten, einen Punkt als Tausender-Trennzeichen zu interpretieren und ein Komma als Dezimaltrennzeichen.

Falls dein Java-Code 32.288 (resp. 16.144) Lösungen in 36 Sekunden errechnet, beglückwünsche ich Dich. Allerdings ist das kein Grund, übermütig zu werden und andere Lösungsansätze zu unterdrücken ("sollte nicht publiziert werden"). Selbst dann nicht, wenn sie unrichtig wären, aber einen erkennbar richtigen Ansatz verfolgen und selbst dann nicht, wenn sie weniger performant sind. U.U. gibt es Einsatzgebiete oder Randbedingungen unter denen der schnellste Weg untauglich ist oder gar nicht funktioniert (evtl. wird die Performance durch eine hohe Speicherausnutzung erkauft und der Code kann auf schmalen Maschinen nicht ausgeführt werden - oder umgekehrt, der Code kommt zwar mit wenig Arbeitsspeicher aus, verlangt aber eine hohe Rechenperformance - oder aber eine Implementation des Interpreters steht auf System xyz nicht zur Verfügung, bedingt durch technische, rechtliche, oder richtlinienerfüllende Gründe). Java ist m.W. in vielen Browsern deaktiviert, Javascript weniger, erreicht also breitere Anwendbarkeit. Häufig mangelt es performanten Lösungen zusätzlich an durchdachten Ein-/Ausgabemöglichkeiten an der Schnittstelle zwischen Mensch und Maschine, weil manche Menschen nur für die Maschine programmieren. Das nur als Denkansatz.

Zudem gibt es (ständig) den Fall, dass sich ein einziger, optimierter Lösungsansatz Neulingen evtl. schlechter erschließt, als eine naive oder naivere, weniger optimierte Methode/Herangehensweise an ein Problem. Salopp (und in Analogie) gesprochen: Streichen wir alle Zwischenschritte, sollte e=mc² o.ä. im Fachgebiet der Physik eigentlich ausreichen, nicht? Mit dieser stark optimierten Formel ist es dann aber doch nicht getan, vergegenwärtigt man sich das verfügbare Material an Büchern, Online-Ressourcen, Kursen, Hochschul- und Universitätsangeboten zum Studium der Physik. Oder vielleicht noch einfacher: Wir verwenden heute weitestgehend das arabische Ziffern(-notations-)system - aber wird die Leistungsfähigkeit dieses Systems nicht erst dadurch deutlich, dass ein Anwender es mit dem römischen System und dessen Eigenschaften vergleicht? .. Gruß --Cmuelle8 (Diskussion) 17:43, 4. Apr. 2016 (CEST)

@B. M., CH-Riehen: Vielen Dank für die Veröffentlichung des Quellcodes und der zugehörigen Lösungsmengen. Durch einen Vergleich habe ich einen Fehler in meinem Programm entdeckt (die Konfigurationen zweier Puzzleteile waren fehlerhaft eingegeben) und nun findet auch mein Programm die 23 Lösungen für die 4x4-Pyramide und ebenso die 306 Lösungen für die 5x5-Pyramide.

Die Erwähnung vorhandener Symmetrien (und deren Einfluss auf die angegebenen Lösungsmengen) halte ich nach wie vor für unabdingbar und schließe mich der Begründung von Cmuelle8 an.

Auch erachte ich die Rechenzeit der Programme in diesem Fall als nicht wichtig solange sie im Rahmen der Reproduzierbarkeit bleibt (wo genau das Limit ist kann natürlich jeder für sich selbst entscheiden). Natürlich kann eine geringere Rechenzeit von Vorteil sein, eine Optimierung ist m.E. aber keinesfalls notwendig, da die Programme keine regelmäßig auszuführenden Aufgaben erledigen, sondern im Idealfall nur ein einziges Mal ausgeführt werden müssen.

Eine Angabe der Lösungszahlen im Artikel mit entsprechenden Einzelnachweisen halte ich für sinnvoll, andere Verbesserungsvorschläge wie z.B. das Hinzufügen von Bildern begrüße ich selbstverständlich auch. Gruß --Dominik Vilsmeier (Diskussion) 11:57, 14. Apr. 2016 (CEST)

Berichtigung

Ich habe meinen mehr als zwei Jahre alten Code überprüft und Fehler gefunden: 23 und 306 halte ich für falsch und 46 bzw. 379 für richtig. Die Lösungen stelle ich heute unter ‹cl.ly/1d131c3e0E0W› ins Web, das berichtigte Programm nach einer weiteren Überprüfung später auch. Wer bestätigt meine neuen Zahlen oder findet vielleicht noch «richtigere»? B. M., CH-Riehen (Diskussion) 22:12, 15. Apr. 2016 (CEST)

2013 habe ich offenbar sorgfältiger gearbeitet als heute: Die alten Werte 23 und 306 sind und bleiben richtig. B. M., CH-Riehen (Diskussion) 10:09, 16. Apr. 2016 (CEST)

Mach Dir nichts draus, ich musste meinen Code vom Dezember ja auch überarbeiten. Wir haben hier nun aber zu dritt eine relativ solide Basis, um den Artikel Lonpos zu überarbeiten, was diese Zahlen, die Symmetrie im Problem, die Weblinks zu Beispielcode, etc. betrifft. Falls du ihn verbessern willst, "sei mutig" (wie es zu Beginn dieser Seite heißt). Wem deine Änderungen dann nicht passen, der kann ja selbst den Edit-Button bemühen oder hier mitdiskutieren. Gruß --Cmuelle8 (Diskussion) 14:13, 23. Apr. 2016 (CEST)

Die Anregung, einen besseren Lonpos-Artikel zu verfassen, werde ich überdenken. B. M., CH-Riehen (Diskussion) 21:42, 25. Apr. 2016 (CEST)

Neue Aufgaben

In der Erwartung, damit die Zuverlässigkeit der Lösungsprogramme zu erhärten, habe ich zwei weitere 3D-Probleme zusammen mit meinen Lösungen unter ‹cl.ly/2F2v1G2N241T› ins Web gestellt. B. M., CH-Riehen (Diskussion) 14:25, 27. Apr. 2016 (CEST)