Zufallenzahlen sollen nicht doppelt vorkommen

[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.

[Reintun sortiere]

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.

[Menschenkenner]

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.