@NoPy: Wenn man sich an den Style Guide for Python Code halten würde bräuchte man nicht diese sinnfreien und deshalb in meinen Augen echt gruseligen `Mein*`-Präfixe bei den Namen. Das ist doch auch ziemlich willkürlich, denn warum heisst es `Teams` und nicht `MeineTeams`‽
Bei `Teams` wird der Datentyp Tupel ”falsch” verwendet. Das sollte eine Liste von Teams sein, denn jedes Element hat die gleiche Bedeutung: ein Team. Im Gegensatz zu den Tupeln für die einzelnen Teams wo die einzelnen Elemente unterschiedliche Bedeutungen haben (Teamname, Kurzname). An der Stelle hätte man dann auch schon das bereits erwähnte `collections.namedtuple` verwenden können um nicht mit ”magischen” Indexzugriffen hantieren zu müssen die den Code schwerer lesbar und änderbar machen. Oder gleich eine eigene Klasse für ein Team, denn einem Team werden ja noch mehr Attribute zugeordnet, beispielsweise die Punkte und Tore.
Was `SpielMatrix`, `Spieltage`, `Tabelle` jetzt konkret enthalten und ob man wirklich alle drei braucht ist aus dem Code nicht wirklich ablesbar.
Beim `Ergebnis` würde ich konkretere Objekte erwarten als Zeichenketten, also `Team`-Exemplare und mindestens ein Tupel für die Tore, denn diese Zeichenkette enthält *zwei* Werte die *Zahlen* sind.
@kodela: Das hatten wir in diesem Thema doch schon mal: Wenn jemand im Python-Forum fragt wie man so etwas in Python macht, dann wäre es komisch zu sagen gar nicht, nimm was anderes. Zumindest nicht wenn Python ein passendes Werkzeug ist, und das ist es hier IMHO eindeutig. Entweder der OP will Python lernen und das damit umsetzen oder nicht, dann sollte er aber irgendwie auch nicht hier fragen weil das dann die falsche Adresse ist.
Neuling in Python
-
kodela
- User
- Beiträge: 185
- Registriert: Montag 12. Oktober 2015, 21:24
- Wohnort: Landsberg am Lech
- Kontaktdaten:
Ja, das ist schon richtig. Ich frage mich nur, ob man auf diese Art und Weise einen Themenersteller, der vom Programmieren so gut wie keine Ahnung hat und von Python erst Recht nicht, worauf er ausdrücklich hingewiesen hat, nicht "erschlägt".BlackJack hat geschrieben:Das hatten wir in diesem Thema doch schon mal: Wenn jemand im Python-Forum fragt wie man so etwas in Python macht, dann wäre es komisch zu sagen gar nicht, nimm was anderes. Zumindest nicht wenn Python ein passendes Werkzeug ist, und das ist es hier IMHO eindeutig. Entweder der OP will Python lernen und das damit umsetzen oder nicht, dann sollte er aber irgendwie auch nicht hier fragen weil das dann die falsche Adresse ist.
Es geht hier doch schon längst nicht mehr um das Thema von doclektor. Darauf wollte ich hinweisen.
MfG, kodela
kodela du könntest recht haben.
Das ich erst ein paar Tage mit Python arbeite und keine Ahnung habe, hatte ich ja ausdrücklich gesagt.
Ich will kein großer Programmierer werden sondern es als Hobby betreiben.
Ich erwarte bestimmt nicht, dass man mir hier alles vormacht, aber man könnte es vernünftig und für einen Anfänger verständlich erklären mit welchen Funktionen es zu lösen ist.
Hatte es eigentlich von einem Forum erwartet. Ist auf jeden Fall in anderen Foren so.
Trotzdem danke allen.
Das ich erst ein paar Tage mit Python arbeite und keine Ahnung habe, hatte ich ja ausdrücklich gesagt.
Ich will kein großer Programmierer werden sondern es als Hobby betreiben.
Ich erwarte bestimmt nicht, dass man mir hier alles vormacht, aber man könnte es vernünftig und für einen Anfänger verständlich erklären mit welchen Funktionen es zu lösen ist.
Hatte es eigentlich von einem Forum erwartet. Ist auf jeden Fall in anderen Foren so.
Trotzdem danke allen.
@doclektor: In der Tat wirst Du eine Lösung für den praktischen Einsatz mit einer Tabellenkalkulation vermutlich schneller erreichen.
Die vermeintlich einfache Aufgabe der Programmierung einer Ligatabelle, welche die gesamt Spielzeit mit allen Ergebnissen und Begegnungen abbildet, ist keineswegs so trivial, wie es auf den ersten Eindruck erscheinen mag. Schließlich geht es hier direkt um Datenstrukturen und Algorithmen, was für einen Anfänger schon anspruchsvoll ist. Andererseits wäre dies auch ein schönes Thema für einen Einstieg in die Programmierung. Der Wunsch sich mit letzterem nicht ernsthaft befassen zu wollen, führt in der Hinsicht jedoch auch nicht zu leichteren Lösungen. Höchsten zu anderen: s.o.
Die vermeintlich einfache Aufgabe der Programmierung einer Ligatabelle, welche die gesamt Spielzeit mit allen Ergebnissen und Begegnungen abbildet, ist keineswegs so trivial, wie es auf den ersten Eindruck erscheinen mag. Schließlich geht es hier direkt um Datenstrukturen und Algorithmen, was für einen Anfänger schon anspruchsvoll ist. Andererseits wäre dies auch ein schönes Thema für einen Einstieg in die Programmierung. Der Wunsch sich mit letzterem nicht ernsthaft befassen zu wollen, führt in der Hinsicht jedoch auch nicht zu leichteren Lösungen. Höchsten zu anderen: s.o.
-
kodela
- User
- Beiträge: 185
- Registriert: Montag 12. Oktober 2015, 21:24
- Wohnort: Landsberg am Lech
- Kontaktdaten:
Ein Halllllo an alle Spezialisten,
genau das war vorherzusehen. Jetzt ist das Gegenteil von dem eingetreten, was eigentlich Ziel dieses Forums sein sollte, anderen bei ihren Problemen zu helfen. Zu diesen "anderen" gehören auch blutige Anfänger und nicht nur die Spezialisten.
Nun ich will keinen der User, die an diesem Desaster, ja es ist ein Desaster, mitgewirkt haben, dafür direkt und unmittelbar verantwortlich mchen, dass man hier einen Anfänger so vor den Kopf gestoßen hat, dass er sich wohl nicht weiter mit Python beschäftigen wird.
Es haben hier aber auch drei Moderatoren mitgewirkt, deren Rat und Hilfe ich durchaus schätze. Ich frage jedoch, warum sich keiner von Ihnen seiner Aufgabe als Moderator gestellt hat. Jeder hat diesen Thread so laufen lassen, wie er lief, keiner ist eingeschritten, als es es sich abzeichnete, dass hier alles aus dem Ruder läuft. Vielleicht liegt das Problem daran, dass es hier zu viele Moderatoren gibt. Damit fühlt sich dann keiner verantwortlich. Schade!
Vielleicht denkt der eine oder andere der Moderatoren darüber einmal nach. Vom Admin will ich gar nicht sprechen, der scheint hier ähnlich unsichtbar zu sein, wie ich es von dem Forum kenne, das ich moderiere. Er hat die Verantwortung übertragen und verlässt sich blind darauf, dass schon alles richtig laufen wird. Das war hier aber nun nicht so.
MfG, kodela
genau das war vorherzusehen. Jetzt ist das Gegenteil von dem eingetreten, was eigentlich Ziel dieses Forums sein sollte, anderen bei ihren Problemen zu helfen. Zu diesen "anderen" gehören auch blutige Anfänger und nicht nur die Spezialisten.
Nun ich will keinen der User, die an diesem Desaster, ja es ist ein Desaster, mitgewirkt haben, dafür direkt und unmittelbar verantwortlich mchen, dass man hier einen Anfänger so vor den Kopf gestoßen hat, dass er sich wohl nicht weiter mit Python beschäftigen wird.
Es haben hier aber auch drei Moderatoren mitgewirkt, deren Rat und Hilfe ich durchaus schätze. Ich frage jedoch, warum sich keiner von Ihnen seiner Aufgabe als Moderator gestellt hat. Jeder hat diesen Thread so laufen lassen, wie er lief, keiner ist eingeschritten, als es es sich abzeichnete, dass hier alles aus dem Ruder läuft. Vielleicht liegt das Problem daran, dass es hier zu viele Moderatoren gibt. Damit fühlt sich dann keiner verantwortlich. Schade!
Vielleicht denkt der eine oder andere der Moderatoren darüber einmal nach. Vom Admin will ich gar nicht sprechen, der scheint hier ähnlich unsichtbar zu sein, wie ich es von dem Forum kenne, das ich moderiere. Er hat die Verantwortung übertragen und verlässt sich blind darauf, dass schon alles richtig laufen wird. Das war hier aber nun nicht so.
MfG, kodela
-
kodela
- User
- Beiträge: 185
- Registriert: Montag 12. Oktober 2015, 21:24
- Wohnort: Landsberg am Lech
- Kontaktdaten:
Hallo,
hinsichtlich dessen, was ich über "den" Admin geschrieben habe, muss zurück rudern. Es gibt nicht nur einen, es gibt sogar zwei und beide sind im Forum sehr aktiv, wenn auch nicht gerade in den Unterforen, in denen es um die Probleme mit Python selbst geht.
Ich hätte mich vorher gründlicher informieren sollen. An der Sache selbst ändert sich dadurch allerdings nichts. Wir haben hier über den Kopf des Themenerstellers hinweg die Diskussion teilweise auf einer Ebene geführt, die für diesen keineswegs hilfreich, eher abschreckend war.
@doclektor:
Du möchtest für Euren Sportverein ein Program für ein Turnier schreiben. Damit müssten
- die Spieltage anzeigt,
- die Ergebnisse eingegeben und
- eine Tabelle ausgegeben werden.
Für diese im Grunde simple Aufgabe ist vielleicht Python, wenn man mit dem Programmieren noch nicht vertraut ist, nicht gerade der beste Einstieg. Mit einer vernünftige Tabellencalkulation wie Excel oder CALC kann man das im Prinzip schon erledigen und wenn man nun noch Makros einsetzt, kann man eine solche Anwendung noch deutlich komfortabler machen. Beide genannten Programme bringen dafür ihre eigene Basic-Programmiersprache mit. Das kostenlose CALC von Open Office bringt sogar Python mit.
Ein solches Vorgehen über eine Tabellenkalulation hat den großen Vorteil, dass bereits eine geeignete Oberfläche für alle Ein- und Ausgaben, sowie alle grundlegenden Funktionalitäten für die Auswertung der Tabelle vorhanden sind.
Solltest Du Dich, vielleicht nicht gleich von Anfang an, dafür entscheiden, auch Python unter CALC zu verwenden, dann wirst Du hier in diesem Forum sicher bei auftauchenden Problemen unterstützt werden. Versuche es einfach einmal. Bedenke aber, aller Anfang ist schwer.
MfG, kodela
hinsichtlich dessen, was ich über "den" Admin geschrieben habe, muss zurück rudern. Es gibt nicht nur einen, es gibt sogar zwei und beide sind im Forum sehr aktiv, wenn auch nicht gerade in den Unterforen, in denen es um die Probleme mit Python selbst geht.
Ich hätte mich vorher gründlicher informieren sollen. An der Sache selbst ändert sich dadurch allerdings nichts. Wir haben hier über den Kopf des Themenerstellers hinweg die Diskussion teilweise auf einer Ebene geführt, die für diesen keineswegs hilfreich, eher abschreckend war.
@doclektor:
Du möchtest für Euren Sportverein ein Program für ein Turnier schreiben. Damit müssten
- die Spieltage anzeigt,
- die Ergebnisse eingegeben und
- eine Tabelle ausgegeben werden.
Für diese im Grunde simple Aufgabe ist vielleicht Python, wenn man mit dem Programmieren noch nicht vertraut ist, nicht gerade der beste Einstieg. Mit einer vernünftige Tabellencalkulation wie Excel oder CALC kann man das im Prinzip schon erledigen und wenn man nun noch Makros einsetzt, kann man eine solche Anwendung noch deutlich komfortabler machen. Beide genannten Programme bringen dafür ihre eigene Basic-Programmiersprache mit. Das kostenlose CALC von Open Office bringt sogar Python mit.
Ein solches Vorgehen über eine Tabellenkalulation hat den großen Vorteil, dass bereits eine geeignete Oberfläche für alle Ein- und Ausgaben, sowie alle grundlegenden Funktionalitäten für die Auswertung der Tabelle vorhanden sind.
Solltest Du Dich, vielleicht nicht gleich von Anfang an, dafür entscheiden, auch Python unter CALC zu verwenden, dann wirst Du hier in diesem Forum sicher bei auftauchenden Problemen unterstützt werden. Versuche es einfach einmal. Bedenke aber, aller Anfang ist schwer.
MfG, kodela
Ich bleibe bei meiner Aussage:
Wenn python das Ziel, die Fußballabrechnung der Weg und kaum Vorkenntnisse die Voraussetzung ist, dann solltest Du
- Kompromisse machen bei der Eingabe der Ergebnisse (nicht graphisch oder Tabellenkalkulation benutzen und auslesen)
- nicht auf allzuviele "Fremdklassen" zurückgreifen, wie named tuple, sondern viel selbst tun, um zu lernen (ob Du Dir gleich Klassen reinziehst, was zwar grundsätzlich besser ist, aber für jemanden, der erst einmal erleben muss, wie Schleifen funktionieren und was typen sind, unnötig viel, ehe er etwas wirksames sieht)
Die eigentliche Logik ist in wenigen kurzen Funktionen mit einer Handvoll Schleifen implementiert und zählt sicher nicht zu den kompliziertesten Algorithmen. Das kannst Du Dir m.E. schon zutrauen, auch mit python. Du musst nur sehen, wie die Daten zu Dir hineinkommen.
@BlackJack:
Sicher entsprachen meine Bezeichner nicht dem PEP, aber darum ging es mir auch nicht einmal ansatzweise. Wenn ich einem Neuling etwas beibringen will, dann halte ich es gern plakativ. Und ein
team = Team()
ist es nicht. Ich muss dazu PEP kennen, um zu wissen, was da passiert. Und im Zweifelsfall kann der böse NoPy auch völlig anders benamst haben, also
Daher
MeinXXX = XXX()
Das liest auch ein Anfänger als "ich habe ein spezielles XXX, nämlich meins, das letztlich ein XXX ist, das schon Dinge kann, um die ich mich an dieser Stelle nicht kümmern musste"
Hinsichtlich des Teams hast Du recht, MeineTeams wäre besser gewesen.
Letztlich benötigt man nur die Spieltage, den Rest kann man in einer Tabelle unterbringen, die zu den Namen und Kurznamen der Teams noch die Ergebnisse der Spieltage enthalten. Aber für mich zumindest ist so eine Spielmatrix, wie sie in Turnieren verwendet wird, ein guter Zwischenschritt. einmal alle Teams oben, alle Teams links --> leicht. Um dann einen Turnierplan abzuleiten, kannst Du dann dort durchgehen.
Teams ist absichtlich ein Tupel von Tupeln, um zu zeigen, dass man auch mehr Eigenschaften, als den Namen dort unterbringen kann.
Natürlich hätte man named Tuple, Klassen oder Dictionaries nehmen können. Aber wir reden von einem Anfänger. Lass diesen erst einmal lernen, mit Tupeln und Schleifen umzugehen, ehe er die Tupel und Schleifen in Klassen einbetten muss.
Ist pure Didaktik, nicht mehr. Mein persönlicher Schritt 1: Implementiere dieses Programm ausschließlich unter Zuhilfenahme von Funktionen, Tupeln, Listen und Schleifen. Aber ich gebe DIr insofern recht, auf die Tupel hätte man auch noch verzichten können, Listen hätten es auch getan.
@kodela, Zur Manöverkritik:
- es mag sein, dass die Diskussion, die hier geführt wurde, nicht immer direkt an der Fragestellung blieb, aber eigentlich kam sie immer wieder zurück
- es liest nicht nur der Fragesteller diesen Thread, sondern mutmaßlich viele andere Menschen, mindestens auch die, die hier antworten. Daher sollte man deren Bedürfnissen auch gerecht werden dürfen
- der OP will offensichtlich tatsächlich python lernen, somit muss er da durch. Um mit python umgehen zu können, musst Du m.E. wesentlich mehr von der Sprache wissen, als in den meisten anderen Programmiersprachen. Ein Hallo Welt geht schnell, aber danach wird es m.E. sofort komplexer.
Wenn python das Ziel, die Fußballabrechnung der Weg und kaum Vorkenntnisse die Voraussetzung ist, dann solltest Du
- Kompromisse machen bei der Eingabe der Ergebnisse (nicht graphisch oder Tabellenkalkulation benutzen und auslesen)
- nicht auf allzuviele "Fremdklassen" zurückgreifen, wie named tuple, sondern viel selbst tun, um zu lernen (ob Du Dir gleich Klassen reinziehst, was zwar grundsätzlich besser ist, aber für jemanden, der erst einmal erleben muss, wie Schleifen funktionieren und was typen sind, unnötig viel, ehe er etwas wirksames sieht)
Die eigentliche Logik ist in wenigen kurzen Funktionen mit einer Handvoll Schleifen implementiert und zählt sicher nicht zu den kompliziertesten Algorithmen. Das kannst Du Dir m.E. schon zutrauen, auch mit python. Du musst nur sehen, wie die Daten zu Dir hineinkommen.
@BlackJack:
Sicher entsprachen meine Bezeichner nicht dem PEP, aber darum ging es mir auch nicht einmal ansatzweise. Wenn ich einem Neuling etwas beibringen will, dann halte ich es gern plakativ. Und ein
team = Team()
ist es nicht. Ich muss dazu PEP kennen, um zu wissen, was da passiert. Und im Zweifelsfall kann der böse NoPy auch völlig anders benamst haben, also
python lässt das zu und wenn der einzige Unterschied zwischen beiden das Glaubensbekenntnis zu PEP ist, dann ist mir das zu wenig.class team()
....
Team = team()
Daher
MeinXXX = XXX()
Das liest auch ein Anfänger als "ich habe ein spezielles XXX, nämlich meins, das letztlich ein XXX ist, das schon Dinge kann, um die ich mich an dieser Stelle nicht kümmern musste"
Hinsichtlich des Teams hast Du recht, MeineTeams wäre besser gewesen.
Letztlich benötigt man nur die Spieltage, den Rest kann man in einer Tabelle unterbringen, die zu den Namen und Kurznamen der Teams noch die Ergebnisse der Spieltage enthalten. Aber für mich zumindest ist so eine Spielmatrix, wie sie in Turnieren verwendet wird, ein guter Zwischenschritt. einmal alle Teams oben, alle Teams links --> leicht. Um dann einen Turnierplan abzuleiten, kannst Du dann dort durchgehen.
Teams ist absichtlich ein Tupel von Tupeln, um zu zeigen, dass man auch mehr Eigenschaften, als den Namen dort unterbringen kann.
Natürlich hätte man named Tuple, Klassen oder Dictionaries nehmen können. Aber wir reden von einem Anfänger. Lass diesen erst einmal lernen, mit Tupeln und Schleifen umzugehen, ehe er die Tupel und Schleifen in Klassen einbetten muss.
Ist pure Didaktik, nicht mehr. Mein persönlicher Schritt 1: Implementiere dieses Programm ausschließlich unter Zuhilfenahme von Funktionen, Tupeln, Listen und Schleifen. Aber ich gebe DIr insofern recht, auf die Tupel hätte man auch noch verzichten können, Listen hätten es auch getan.
@kodela, Zur Manöverkritik:
- es mag sein, dass die Diskussion, die hier geführt wurde, nicht immer direkt an der Fragestellung blieb, aber eigentlich kam sie immer wieder zurück
- es liest nicht nur der Fragesteller diesen Thread, sondern mutmaßlich viele andere Menschen, mindestens auch die, die hier antworten. Daher sollte man deren Bedürfnissen auch gerecht werden dürfen
- der OP will offensichtlich tatsächlich python lernen, somit muss er da durch. Um mit python umgehen zu können, musst Du m.E. wesentlich mehr von der Sprache wissen, als in den meisten anderen Programmiersprachen. Ein Hallo Welt geht schnell, aber danach wird es m.E. sofort komplexer.
@NoPy: PEP8 ist kein Glaubensbekenntnis sondern eine Sammlung von Konventionen, die wenn sie eingehalten werden, die Kommunikation erheblich vereinfachen. Gerade weil es einem Anfänger egal ist, wie irgendetwas geschrieben wird, ist es für Dich, der schon etwas weiter ist, Pflicht, immer die korrekte Schreibweise zu benutzen, damit sich der Anfänger gleich daran gewöhnt und nicht erst etwas falsches lernt und sich danach mühsam wieder umgewöhnen muß. Es ist wie mit dem Autofahren, erst lernen wir kuppeln und gasgeben, das Rechtsfahren kommt irgendwann später, vielleicht.
-
BlackJack
@NoPy: ``team = Team()`` sagt einem Anfänger genau das gleiche wie ``MeinTeam = Team()``, das was Du da an zusätzlicher Semantik erklärst ist IMHO micht selbsterklärend und ausserdem ist das IMHO eine nachträgliche Erklärung für etwas das sich aus einem ganz anderen Grund eingebürgert hat: Ich kenne dieses `My*`/`Mein*` nämlich so gut wie ausschliesslich aus Sprachen die keine Gross- und Kleinschreibung bei Bezeichnern kennen, wo also `team` und `Team` das gleiche sind. Ausserhalb von BASIC- und Pascal-Dialekten sieht man das sehr selten und wenn dann oft bei Programmierern die vorher BASIC oder Pascal & Co geschrieben haben.
Gross geschriebene Namen lese ich als Datentypen und es ist verwirrend wenn das nicht so ist. Es erschwert das lesen von Quelltext. Das ist als wenn Du sagst der Duden wäre nur ein Glaubensbekenntnis und es wäre Dir zuwenig das als Grundlage dafür zu nehmen korrekte Gross- und Kleinschreibung bei Texten zu verwenden, und das man das Anfängern nicht zumuten muss und erst mal alles gross schreiben kann und vor Verben dann beispielseise einen Präfix setzt, damit man sie als solche besser erkennt. Das mag für einen Anfänger tatsächlich egal sein, stört aber den Lesefluss und erschwert das erfassen des Sinns für Leute welche die Sprache schon können. Python lässt eine Menge zu, aber die Gemeinschaft nicht, denn es gibt dort Richtlinien an die man sich halten sollte wenn man „pythonischen“ Code schreiben will. Gerade wenn man Anfängern etwas zeigt sollte man das tun.
Ich persönlich habe bei längerem Quelltet der sich nicht an PEP8 hält auch schon das Antworten ganz sein gelassen weil es mir zu mühsam war das durchzuarbeiten. Das hat also auch ein bisschen damit zu tun ob man Hilfe möchte oder nicht. Ist letztlich nichts anderes als Beiträge die komplett klein und ohne jegliche Satzzeichen geschrieben sind — wenn das zu aufwändig wird das im Kopf zu ergänzen geben viele potentielle Helfer schon beim Versuch die Frage überhaupt zu verstehen auf.
Das man mehr in einem Team unterbringen kann als Name und Kürzel hätte man bei einer Liste von Listen auch gesehen, wobei ich ja nur das äussere Tupel meinte, bei den Elementen ist Tupel ja der richtige Typ.
Wenn man kein `namedtuple` oder keine eigene Klasse verwendet sondern bei Grunddatentypen bleiben will, dann wäre `dict` eher der passende Typ für ein Team, denn weder Anfänger noch Fortgeschrittene sollten mit magischen Indexwerten hantieren müssen. Das sorgt für schwer verständlichen, schwer wartbaren, und damit fehleranfälligen Code.
Gross geschriebene Namen lese ich als Datentypen und es ist verwirrend wenn das nicht so ist. Es erschwert das lesen von Quelltext. Das ist als wenn Du sagst der Duden wäre nur ein Glaubensbekenntnis und es wäre Dir zuwenig das als Grundlage dafür zu nehmen korrekte Gross- und Kleinschreibung bei Texten zu verwenden, und das man das Anfängern nicht zumuten muss und erst mal alles gross schreiben kann und vor Verben dann beispielseise einen Präfix setzt, damit man sie als solche besser erkennt. Das mag für einen Anfänger tatsächlich egal sein, stört aber den Lesefluss und erschwert das erfassen des Sinns für Leute welche die Sprache schon können. Python lässt eine Menge zu, aber die Gemeinschaft nicht, denn es gibt dort Richtlinien an die man sich halten sollte wenn man „pythonischen“ Code schreiben will. Gerade wenn man Anfängern etwas zeigt sollte man das tun.
Ich persönlich habe bei längerem Quelltet der sich nicht an PEP8 hält auch schon das Antworten ganz sein gelassen weil es mir zu mühsam war das durchzuarbeiten. Das hat also auch ein bisschen damit zu tun ob man Hilfe möchte oder nicht. Ist letztlich nichts anderes als Beiträge die komplett klein und ohne jegliche Satzzeichen geschrieben sind — wenn das zu aufwändig wird das im Kopf zu ergänzen geben viele potentielle Helfer schon beim Versuch die Frage überhaupt zu verstehen auf.
Das man mehr in einem Team unterbringen kann als Name und Kürzel hätte man bei einer Liste von Listen auch gesehen, wobei ich ja nur das äussere Tupel meinte, bei den Elementen ist Tupel ja der richtige Typ.
Wenn man kein `namedtuple` oder keine eigene Klasse verwendet sondern bei Grunddatentypen bleiben will, dann wäre `dict` eher der passende Typ für ein Team, denn weder Anfänger noch Fortgeschrittene sollten mit magischen Indexwerten hantieren müssen. Das sorgt für schwer verständlichen, schwer wartbaren, und damit fehleranfälligen Code.
Ich bin es noch mal
kann mir jemand sagen mit welcher Funktion man diesese löst
Es soll Automatisch gehen, dass jeder gegen jeden spielt in hin- und Rückspielen
Gegeben M1, M2 , M3, M4
Bitte nur mit welcher Funktion dieses zu lösen ist.
Vielen Dank
kann mir jemand sagen mit welcher Funktion man diesese löst
Es soll Automatisch gehen, dass jeder gegen jeden spielt in hin- und Rückspielen
Gegeben M1, M2 , M3, M4
Bitte nur mit welcher Funktion dieses zu lösen ist.
Vielen Dank
-
pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
itertools.permutations()doclektor hat geschrieben:[...] dass jeder gegen jeden spielt in hin- und Rückspielen [...]
Bitte nur mit welcher Funktion dieses zu lösen ist.
In specifications, Murphy's Law supersedes Ohm's.
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
@Pillmuncher: Ich glaube nicht, dass Permutationen dem OP hier helfen! Natürlich bekommt man so alle notwendigen Spiele (und "Rückspiele"), aber diese sind "ungeordnet". In der Realität will man idR. sowohl bei zeitlich kurzen Turnieren aber auch bei längeren Phasen (Bsp. Fußball Bundesliga immerhin ca. 9 Monate) Spiele parallel austragen. Dies ist aber schwierig, wenn man mittels Permutationen vorgeht...
Beispiel:
Wenn ich die erste Partie spielen will, dann finde ich "A gegen B". Ok. Wenn parallel eine andere Partie stattfinden soll, muss ich also gucken, wann als erstes Element ein "C" kommt. Oops... "C gegen A"... das geht aber nicht, weil A ja in dieser Runde schon spielt...
In der Praxis kann man die Durchgänge auf Papier für 4er Gruppen noch einfach aufschreiben, 6er Gruppen gehen vielleicht gerade noch so, aber ab Größe 8 geht das ohne System imho nicht mehr. Und genau solch ein System braucht der OP...
Ich werfe hier mal das Rutschsystem als Ansatz in den Raum! Ich hatte für die Generierung von Turnierspielplänen vor olims Zeiten einmal ein kleines Script dafür geschrieben, welches ich ausgekramt und auf die schnelle auf Python 3 portiert und an ein paar Stellen überarbeitet habe: Link
Beispiel:
Es fehlt dabei natürlich noch die Generierung der Rückspiele - diese lassen sich aber ja einfach aus den Hinspielen generieren; lediglich die Reihenfolge in den Tupeln ändert sich dabei ja.
Beispiel:
Code: Alles auswählen
In [9]: teams = list("ABCD")
In [11]: list(permutations(teams, 2))
Out[11]:
[('A', 'B'),
('A', 'C'),
('A', 'D'),
('B', 'A'),
('B', 'C'),
('B', 'D'),
('C', 'A'),
('C', 'B'),
('C', 'D'),
('D', 'A'),
('D', 'B'),
('D', 'C')]In der Praxis kann man die Durchgänge auf Papier für 4er Gruppen noch einfach aufschreiben, 6er Gruppen gehen vielleicht gerade noch so, aber ab Größe 8 geht das ohne System imho nicht mehr. Und genau solch ein System braucht der OP...
Ich werfe hier mal das Rutschsystem als Ansatz in den Raum! Ich hatte für die Generierung von Turnierspielplänen vor olims Zeiten einmal ein kleines Script dafür geschrieben, welches ich ausgekramt und auf die schnelle auf Python 3 portiert und an ein paar Stellen überarbeitet habe: Link
Beispiel:
Code: Alles auswählen
from round_robin import round_robin
teams = "ABCD"
for round, matches in enumerate(round_robin(teams), 1):
print(round, matches)
>
1 [('A', 'D'), ('B', 'C')]
2 [('A', 'C'), ('D', 'B')]
3 [('A', 'B'), ('C', 'D')]encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert