Zufallenzahlen sollen nicht doppelt vorkommen

SideWinder

@codetagger: Man sollte als Informatiker schon in der Lage sein die beste Datenstruktur und den schnellsten Algorithmus für ein gegebenes Problem zu finden bzw. einzusetzen. Das hat noch nichts mit "premature optimization" zu tun. Wenn du dann hergehst und einen in O-Notation optimalen Algorithmus verschnellerst in dem du zwei Zeilen Assembler hier und eine unleserliche Umstellung anderswo verwendest um zwei Ticks in genau deinem Fall und sonst in keinem Fall einzusparen, dann befindest du dich dort. Wenn du aber statt O(n) einfach mal ein O(n^4) hinnimmst und das als "mini" bezeichnest...

MfG SideWinder

Jester schrieb:

codetagger schrieb:

Wenn ihr euch mal Gedanken über kompiliziertere und sinnvollere Sachen, wie Softwaredesign und Architektur, machen würdet, dann würde man vlt. weniger scheußlichen Code in Firmen finden. Aber hier gibts immer nur Gedanken über mini Probleme.

Aber irgendjemand muß sich auch Gedanken darüber machen, wie man am allerbesten nicht wiederholende Zufallszahlen zieht und wie man am besten was sortiert und und und... Wie kommst Du drauf, dass das alles weniger "kompiliziert" sei als Softwaredesign und Architektur.

Weil es sogar hier im Forum Unmengen an Beiträge über das ziehen von solchen Zahlen gibt.

hustbaer schrieb:

codetagger schrieb:

Wenn ihr euch mal Gedanken über kompiliziertere und sinnvollere Sachen, wie Softwaredesign und Architektur, machen würdet, dann würde man vlt. weniger scheußlichen Code in Firmen finden. Aber hier gibts immer nur Gedanken über mini Probleme.

Ich sehe jetzt keinen grossen Vorteil darin, wenn das Design bzw. die Architektur gut ist, dafür aber die Implementierung Mist.

Ne schlechte Implementierung läßt sich bei einer guten Architektur schnell austauschen, aber ne schlechte Architektur austauschen ist viel aufwendiger. Außerdem ist mir noch keiner begegnet, der gute Architektur designt, aber schlecht ziemlich implementiert, aber schon viele die nen schnellen Algo implementieren können, aber keine gute Architektur hinbekommen.

SideWinder schrieb:

@codetagger: Man sollte als Informatiker schon in der Lage sein die beste Datenstruktur und den schnellsten Algorithmus für ein gegebenes Problem zu finden bzw. einzusetzen. Das hat noch nichts mit "premature optimization" zu tun. Wenn du dann hergehst und einen in O-Notation optimalen Algorithmus verschnellerst in dem du zwei Zeilen Assembler hier und eine unleserliche Umstellung anderswo verwendest um zwei Ticks in genau deinem Fall und sonst in keinem Fall einzusparen, dann befindest du dich dort. Wenn du aber statt O(n) einfach mal ein O(n^4) hinnimmst und das als "mini" bezeichnest...

Ja, ja, ganz billiger Versuch mir die Worte im Mund umzudrehen oder bist wirklich so dumm den Zusammenhang zu verstehen. Ich habe dieses Lottospiel als "mini" bezeichnet, O(n^4) hast du gerade hergezaubert. Premature Optimization ist das Optimieren von Programmteilen die keinen messbaren Unterschied bringen. Und irgendwas mit Assembler besser an eine Hardware anzupassen, muss auch nicht immer Premature Optimization sein, wenn man es zum richtigen Zeitpunkt an der richtigen Stelle macht.

EXDW

hustbaer schrieb:

David W schrieb:

Wieso wird über die Laufzeit geredet?

Weil hier Informatiker/Programmierer verkehren?

Und? Die Laufzeit und Komplexität ist für die Aufgabenstellung völlig irrelevant.
-> Fällt schon unter YAGNI. Über die Aspekte der Laufzeit kann geredet werden sofern es erforderlich ist.

Und nur weil es Langsamer ist als anderer Code den man ausgearbeitet hat heißt das noch lange nicht das es Schrecklicher Code ist.

Die Aufgabenstellung besagte ja "Lottozahlen Ziehen", das kann man schon einmal sauber aufziehen mit ersten Focus auf Sauberkeit und Funktionalität. Wenn dann gemerkt wird das es von der Performance her nicht aus reicht, also nachgewiesen mit einem Profiler, kann man dieses Modul (Klasse oder Methode) neu implementieren und in der eigentlichen Applikation austauschen.

List<int> lottoNumbers = GetLottoNumbers();

public List<int> GetLottoNumbers()
{
    List<int> numbers = new List<int>();
    for (int i = 1; i < 49; ++i)
        numbers.Add(i);
    numbers .OrderBy(a => Guid.NewGuid());
    return numbers.GetRange(0, 6);
}

Kurz, knapp, funktioniert.

Walli

SideWinder schrieb:

Wenn du aber statt O(n) einfach mal ein O(n^4) hinnimmst und das als "mini" bezeichnest...

Ergänzend und mal ganz vom konkreten Problem hier losgelöst: Bei begrenztem n kann es durchaus Sinn machen den asymptotisch langsameren Algorithmus herzunehmen. Wer einfach nur blind die asymptotischen Laufzeitkomplexitäten vergleicht, der hat die O-Notation nicht verstanden. Ich sehe leider viel zu oft die Pauschalaussage, dass O(n) besser als O(n^2) ist.

David W schrieb:

Über die Aspekte der Laufzeit kann geredet werden sofern es erforderlich ist.

Nachdenken kann nie schaden, besonders bei Übungsaufgaben.

EXDW

Walli schrieb:

Nachdenken kann nie schaden, besonders bei Übungsaufgaben.

Korrekt, und zwar wie man es sauber auf zieht das andere es auch verstehen und Maintainen können, das ist viel wichtiger als Optimierungen die in den Mikro bereich fallen.

Jester

Mit der Aufgabe hat sich hier im Prinzip ja kaum einer beschäftigt. Es gibt nämlich zwei Lager, die einen Sagen das ist ja total einfach, lass uns ne möglichst simple Lösung machen die für 6 Zahlen aus 49 funktioniert. Die meisten haben aber sofort gesagt, okay wir haben N Zahlen und wir wollen K stück ziehen, ohne doppelte und haben sich auf dieses neue Problem gestürzt, weil es interessanter ist -- zumindest für viele Informatiker.

Und hier kommt es zu sehr interessanten Effekten, während Du mir verkaufst, dass eine Laufzeit von O(N) toll sei mit dem random shuffle und mir dafür sogar noch eine Implementierung mit O(N log N) Laufzeit verkaufst (und O(N) Speicher) und behauptest man müsse sich nun auf die Architektur konzentrieren, denken sich andere dass das ja doof wäre, weil N viel viel größer sein könnte als K und überlegen, wie sie das N aus der Laufzeit rauskriegen, fokussieren also eher auf algorithmische Aspekte und stellen fest, dass auch O(K log K) geht.

Es war eine simple Übungsaufgabe, es ist weder Architektur und Wartbarkeit noch eine theoretische Überlegung für N Zahlen ohne Wiederholung aus K gefragt. Wir verallgemeinern die Übungsaufgabe also in unterschiedliche Richtungen. Nur Du scheinst als einziger genau zu wissen, dass das eine Quatsch ist und das andere total wichtig. Warum? -- Mir scheint nur aus Gewohnheit; willkommen am Tellerrand! Wallis Einwand gilt hier nicht so wirklich, weil die Konstanten der Algorithmen vernachlässigbar klein sein dürften so dass der theoretisch bessere hier auch ziemlich bald der praktisch bessere ist.

David W schrieb:

Korrekt, und zwar wie man es sauber auf zieht das andere es auch verstehen und Maintainen können, das ist viel wichtiger als Optimierungen die in den Mikro bereich fallen.

Und was ist daran falsch darüber zu reden? Das Reden über Komplexität und Effizienz hat doch erstmal gar nichts damit zu tun. Nur weil jemand über das Thema diskutiert, heißt das noch nicht, dass er auch blind die "schnellste" Lösung wählt ohne auf Lesbarkeit zu achten. Es heißt nur, dass er die Alternativen kennen möchte. Das ist nie verkehrt.

Antoras

Wie kann man darauf rumkauen ob man bei der Implementierung eines Algos nur Premature Optimierungen erreicht oder nicht. Es geht hier in erster Linie um den Lerneffekt - eine geringere Laufzeit ist ein Nebeneffekt der zwar schön ist aber nicht erwartet wird. Zumindest ist das bei mir so. Ich mach mir um die Laufzeit dann Gedanken wenn ich einen schnellen Algo wirklich benötige und wenn ich verstanden habe wo man optimieren kann.

Wenn ich Hausaufgaben erledigen muss, auf die ich kein Bock habe, dann wähle ich die primitive Variante bei der so lange Zufallszahlen gezogen werden bis ich genug Unterschiedliche zusammen hab. Wenn ich meine Hausaufgaben gut machen will, dann wähle ich einen Shuffle. Und wenn ich was lernen will, dann implementiere ich z.B. den von mir genannten Algo.

Premature Optimization mach ich nur dann wenn mich ein Thema wirklich interessiert und mir die Zeit, die ich zum optimieren brauche, egal ist. Hier ist mir der Lerneffekt und das Wissen, dass ich einen Algo noch weiter verbessert hab, wichtiger.

Es gibt genug Informatiker, die meinen, dass wenn sie ihre Hausaufgaben auf einfachste Weise erledigt haben, sie alles wichtige gelernt haben und es nichts mehr zu lernen gibt. Das sind dann auch die gleichen Leute, die behaupten, dass premature Optimierungen überhaupt nicht beachtet werden sollen, weil der Zeitaufwand sie zu implementieren zu groß ist. Diese Leute haben aber nicht verstanden, dass es nicht nur um die Zeit und finanzielle Interessen gehen kann, sonder auch um den Lerneffekt. Aber solche Leute sind selbst schuld wenn sie irgendwann auf dem Abstellgleis versauern müssen.

Antoras schrieb:

Wie kann man darauf rumkauen ob man bei der Implementierung eines Algos nur Premature Optimierungen erreicht oder nicht. Es geht hier in erster Linie um den Lerneffekt - eine geringere Laufzeit ist ein Nebeneffekt der zwar schön ist aber nicht erwartet wird. Zumindest ist das bei mir so. Ich mach mir um die Laufzeit dann Gedanken wenn ich einen schnellen Algo wirklich benötige und wenn ich verstanden habe wo man optimieren kann.

Wenn ich Hausaufgaben erledigen muss, auf die ich kein Bock habe, dann wähle ich die primitive Variante bei der so lange Zufallszahlen gezogen werden bis ich genug Unterschiedliche zusammen hab. Wenn ich meine Hausaufgaben gut machen will, dann wähle ich einen Shuffle. Und wenn ich was lernen will, dann implementiere ich z.B. den von mir genannten Algo.

Premature Optimization mach ich nur dann wenn mich ein Thema wirklich interessiert und mir die Zeit, die ich zum optimieren brauche, egal ist. Hier ist mir der Lerneffekt und das Wissen, dass ich einen Algo noch weiter verbessert hab, wichtiger.

Es gibt genug Informatiker, die meinen, dass wenn sie ihre Hausaufgaben auf einfachste Weise erledigt haben, sie alles wichtige gelernt haben und es nichts mehr zu lernen gibt. Das sind dann auch die gleichen Leute, die behaupten, dass premature Optimierungen überhaupt nicht beachtet werden sollen, weil der Zeitaufwand sie zu implementieren zu groß ist. Diese Leute haben aber nicht verstanden, dass es nicht nur um die Zeit und finanzielle Interessen gehen kann, sonder auch um den Lerneffekt. Aber solche Leute sind selbst schuld wenn sie irgendwann auf dem Abstellgleis versauern müssen.

Benutzerprofil
Beruf: Schüler

Da sieht man halt wer Erfahrung hat.

Übrigens: Wie implementiert man premature Optimierungen?

EXDW

Reintun sortiere schrieb:

David W schrieb:

Korrekt, und zwar wie man es sauber auf zieht das andere es auch verstehen und Maintainen können, das ist viel wichtiger als Optimierungen die in den Mikro bereich fallen.

Und was ist daran falsch darüber zu reden? Das Reden über Komplexität und Effizienz hat doch erstmal gar nichts damit zu tun. Nur weil jemand über das Thema diskutiert, heißt das noch nicht, dass er auch blind die "schnellste" Lösung wählt ohne auf Lesbarkeit zu achten. Es heißt nur, dass er die Alternativen kennen möchte. Das ist nie verkehrt.

Der Thread wurde gekapert.
Den OP ging es nur darum sein Denkfehler zu finden, und zwar 6 verschiedene Zahlen aus 49 zu Ziehen. Um Laufzeit und ähnliches ging es gar nicht, der Thread verwirrt den OP am ende nur als das er ihn etwas bringt.
Er schrieb es ja selber bereits.

-> Es steht jeden frei ein Thread auf zu machen "Performance von nicht doppelten Zufallszahlen"

Jester

Es hat übrigens nicht per se etwas mit premature optimization zu tun, wenn man sich ein Problem vornimmt und versucht die beste(n) Lösung(en) für dieses Problem rauszufinden.

hustbaer

Ja, der Thread wurde gekapert.
Nachdem dem OP mit der 2. Antwort seine Frage beantwortet wurde, nämlich dass der Fehler ist dass er "m" nirgends initialisiert.
Krass schlimm wenn danach über andere, für viele hier interessantere Dinge weiterdiskutiert wurde.

Ich sag jetzt erstmal nix zu den restlichen Dingen die seit meinem letzten Beitrag gekommen sind, das wird mir echt zu drollig.