Diskussion:Primzahlen: Programmbeispiele

Visual Basic 3

Das Programm in Visual Basic 3 stammt von Benutzer:Rho und ist public domain. Es wurde von ihm selbst hierher kopiert.

extreme Überkommentierung

Das Basic und das Java Programme sind IMHO sehr stark überkommentiert. Besonders das Basic-Programm finde ich so sehr unleserlich. Man sieht vor lauter Kommentaren den Code nicht mehr. Auch im Java-Programm sind die Kommentare sehr 'trivial', also z.B. wenn eine Zuweisung nach modulo-Division mit 'ablegen' kommentiert wird.

Da die Algorithmen in einem Buch-Kapitel und in dem WP-Artikel erklärt sind, der Code der Beispiele sehr übersichtlich/kompakt ist und die Variablen sprechende Namen haben schlage ich vor, alle Kommentare aus den Beispielen zu entfernen. Würde IMHO die Lesbarkeit stark erhöhen und das Verständnis des Codes erleichtern. --Bgw 22:32, 13. Jun. 2008 (CEST)

Du magst für fortgeschrittene Anwender recht haben, für mich als blutiger Anfänger sind diese Kommentare jedoch essenziell. -- ‎79.214.232.15 13:04, 10. Okt. 2012 (Signatur nachgetragen von: Jürgen 13:34, 10. Okt. 2012 (CEST) -- bitte künftig mit 4 Tilden ~~~~ selbst erledigen)

Fehler im Java-Code

Ich kann zwar nicht evaluieren, wo der Fehler liegt, aber das Programm gibt diverse geraden Zahlen aus! -- 217.162.166.82 11:01, 4. Nov. 2008 (Signatur nachgetragen von: Jürgen 19:45, 11. Jun. 2014 (CEST) -- bitte künftig mit 4 Tilden ~~~~ selbst erledigen)

Beim ausführen des Codes schleicht sich eione 6 und eine zweite 9 in das Ergebniss der Ausgabe. -- 2a02:810d:1880:1198:e0de:7caf:5ed1:2cbe 19:00, 11. Juni 2014 (Signatur nachgetragen von: Jürgen 19:45, 11. Jun. 2014 (CEST) -- bitte künftig mit 4 Tilden ~~~~ selbst erledigen)

Also ich bekomme folgende richtig ausgabe:

2 ist eine Primzahl, da sie genau 2 Teiler hat 3 ist eine Primzahl, da sie genau 2 Teiler hat 5 ist eine Primzahl, da sie genau 2 Teiler hat 7 ist eine Primzahl, da sie genau 2 Teiler hat 11 ist eine Primzahl, da sie genau 2 Teiler hat 13 ist eine Primzahl, da sie genau 2 Teiler hat 17 ist eine Primzahl, da sie genau 2 Teiler hat 19 ist eine Primzahl, da sie genau 2 Teiler hat 23 ist eine Primzahl, da sie genau 2 Teiler hat 29 ist eine Primzahl, da sie genau 2 Teiler hat 31 ist eine Primzahl, da sie genau 2 Teiler hat 37 ist eine Primzahl, da sie genau 2 Teiler hat 41 ist eine Primzahl, da sie genau 2 Teiler hat 43 ist eine Primzahl, da sie genau 2 Teiler hat 47 ist eine Primzahl, da sie genau 2 Teiler hat 53 ist eine Primzahl, da sie genau 2 Teiler hat 59 ist eine Primzahl, da sie genau 2 Teiler hat 61 ist eine Primzahl, da sie genau 2 Teiler hat 67 ist eine Primzahl, da sie genau 2 Teiler hat 71 ist eine Primzahl, da sie genau 2 Teiler hat 73 ist eine Primzahl, da sie genau 2 Teiler hat 79 ist eine Primzahl, da sie genau 2 Teiler hat 83 ist eine Primzahl, da sie genau 2 Teiler hat 89 ist eine Primzahl, da sie genau 2 Teiler hat 97 ist eine Primzahl, da sie genau 2 Teiler hat Dirk Hünniger 20:04, 11. Jun. 2014 (CEST)

Habe gerade den Code überarbeitet und besser formatiert. Aktuelle Ausgabe sollte fehlerfrei sein. Stephan Kulla 20:47, 11. Jun. 2014 (CEST)

in Möglichkeit 2 sieht folgendes nach einer Endlosschleife aus

               while (index < kandidaten.size()) {
                   (kandidaten.get(index)).setValue(gestrichen);  // ArrayList.get in O(1)!
               }

-- 2001:16b8:2d86:8b00:b5b6:970a:9328:ebce 16:14, 05. Jan. 2020 (Signatur nachgetragen von: Jürgen 11:59, 6. Jan. 2020 (CET)-- bitte signiere deine künftigen Beiträge selbst mit 4 Tilden ~~~~)

Fehler im Python-Code

Ich hab das Python-Programm ausprobiert und das gibt mir bei einer Obergrenze von 10 auch 9 als Primzahl aus. Entweder ich hab was falsch abgetippt oder das Programm ist falsch. --BuZZdEE.BuzZ 11:55, 23. Okt. 2010 (CEST)

Ich habe keine Ahnung von Python, aber ich vermute, du hast recht. Wahrscheinlich ist der range-Befehl falsch. Versuche es einmal so:

for k in range(i+i,obergrenze+1,i):   # i plus i, nicht i mal i

Wahrscheinlich ist auch das "+1" hinter obergrenze falsch; das dürfte zu einem Überlauffehler für das zahlen-Array führen.

Wenn du beides ausprobiert hast und eine fehlerfreie Version hast, dann ändere bitte den Code auf der Hauptseite. -- Gruß Jürgen 12:38, 23. Okt. 2010 (CEST)

Also, dass 9 bei mir als Primzahl ausgegeben wurde lag wohl an der falschen Einrückung. Im Wikibook ist sie aber korrekt. Es wurden aber auch 0 und 1 als Primzahlen ausgeben. Das habe ich nun geändert. --BuZZdEE.BuzZ 14:27, 23. Okt. 2010 (CEST)

Und ich habe es wieder entfernt. Seit wann kann 0 durch 0 geteilt werden? Und ob 1 prim ist oder nicht, darüber haben sich Mathematiker über Jahrhunderte hinweg gestritten, bis man sich so geeinigt hat, wie es jetzt auf Primzahlen steht, nämlich "nicht prim". -- Jürgen 14:33, 23. Okt. 2010 (CEST)

Wieso "0 durch 0"? Weil 0 und 1 keine Primzahlen sind, habe ich sie ja rausgeschmissen oder was habe ich jetzt falsch verstanden? --BuZZdEE.BuzZ 14:46, 23. Okt. 2010 (CEST)

Juetho, lass den Kommentar noch mal auf dich wirken. Benutzer BuZZdEE has fixed it. Leider reicht der Patch nicht aus, um die Quadratzahlen 9, sicherlich auch 25 und 49, die dieser Algorithmus fehlerhaft als prim markiert zu korrigieren. Die Implementation des w:Sieb_des_Eratosthenes ist falsch. -- ThePacker 14:49, 23. Okt. 2010 (CEST)

Die Zahlen gibt der Algo nicht aus. --BuZZdEE.BuzZ 14:57, 23. Okt. 2010 (CEST)

Verstehe, dann habe ich den Python Code falsch verstanden. Ich ziehe meine Aussage zurück. Für mich sehen die ersten Zahlen korrekt aus. Vgl. mit der Liste der Primzahlen hier auf Wikibooks. -- ThePacker 14:59, 23. Okt. 2010 (CEST) Ich habe vorhin noch die variante mit i*i gesehen. Obwohl die optimierte Version erst dort anfangen müsste. Da i+i bereits mit der Primzahl 2 abgestrichen werden sollte genau wie i+i+i mit der 3. -- ThePacker 15:03, 23. Okt. 2010 (CEST)

Autsch, Entschuldigung. Ich habe gedacht: Wozu sollen 0 und 1 überhaupt untersucht werden? Das wäre überflüssig. Deshalb hatte ich es entfernt und nicht beachtet, dass Buzz die Werte gleich auf False gesetzt hat. Anscheinend fängt die Array-Initialisierung bei 0 an (wie heute ja üblich).

Aber was ist mit meinen beiden anderen Vorschlägen, vor allem "i plus i" (oder "2 mal i") statt "i mal i"? -- Gruß Jürgen 16:28, 23. Okt. 2010 (CEST)

Warum "i plus i" oder "2 mal i"? Wenn ich das richtig sehe, ist der Algorithmus Sieb des Eratosthenes eben so definiert. Ich hab mich damit jetzt nicht intensiv auseinander gesetzt, allerdings denke ich, dass es keinen Vorteil bringt. Es würde den Algorithmus sogar verlangsamen, wenn ich ihn richtig verstanden habe.

    i = 2   
    while i*i <= obergrenze:
        if zahlen[i] == True: # Die Zahl i ist als prim markiert
            # Streiche alle Vielfachen von i
            for k in range(i*i,obergrenze+1,i):
                zahlen[k] = False
        i = i+1

Wenn z.B. i=3 dann beginnt die for-schleife mit 9 bei der Multiplikation, bei der Addition dagegen bei 6. Die 6 fliegt bei der Multiplikation und auch bei der Addition aber schon bei i=2 raus. Das bedeutet bei der Addition würde in der for-schleife nochmal zahlen[6] = False gesetzt werden, was gar nicht mehr nötig ist, weil es schon im vorherigen Durchlauf geschehen ist. Ich hoffe, ich irre mich jetzt nicht.^^ --BuZZ-dEE 18:31, 23. Okt. 2010 (CEST)

Igitt, ich sollte mich zu Mathe-Fragen nur noch äußern, wenn ich mich im Detail damit befasse, und sollte mich nicht auf mein Gefühl verlassen; dazu ist mein Studium offensichtlich zu lange her. Also vergesst alles, was ich gesagt habe. -- Jürgen 18:54, 23. Okt. 2010 (CEST)

C++

Ich habe diese Änderung von 92.63.223.61 rückgängig gemacht und die letzte Version von Benutzer Diskussion:L47 weitgehend wiederhergestellt. Folgende Punkte von 92.63.223.61 sind IMHO Verschlimmbesserungen:

• Das Programm ist deutlich miserabler, wenn die Obergrenze im Quellcode vorgegeben ist und nicht abgefragt wird.
• Die Formatierungen des Codes sind grausam und entsprechen überhaupt nicht der Struktur (Einrückungen von Klammern und Befehlszeilen). Ich musste den Code ausdrucken, um ihn zu verstehen und mit der vorherigen Version vergleichen zu können.
• Es gibt keinen Grund, in der ersten Schleife (Initialisierung des Arrays) die Zählvariable als long zu deklarieren.
• Es gibt keinen Grund, in pow den Exponenten als Dezimalzahl anzugeben.
• Es gibt keinen Grund, an das Ende getchar zu setzen: Wenn alle Zahlen ausgegeben sind, stehen sie da. Wer in seiner Programmierumgebung die Console steuern muss, weiß, dass er eine solche Zeile am Ende eines Programms braucht; meistens kann man das aber in der IDE einstellen, oder (z.B. unter Win7) man kann im Ausgabefenster der Console blättern. Diese Zeile ist also in einem Beispielprogramm völlig deplatziert.

In den drei for-Schleifen habe ich die Zählvariable einheitlich als unsigned deklariert. Das passt zur Obergrenze limit und vermeidet damit einen theoretisch möglichen Speicherüberlauf (oder wie auch immer C++ reagiert).

Der Ordnung halber weise ich darauf, dass meine Änderungen mangels Compiler nur theoretisch begründet sind und nicht praktisch verwirklicht und geprüft. Bei diesem Programm sollten aber trotzdem alle meine Aussagen korrekt sein. -- Jürgen 13:52, 31. Mär. 2012 (CEST)

Fehler bei C#

// der Code gibt bei einer Zahl von 100000 eine Fehlermeldung aus. Gruß Fabi -- 217.6.11.28 08:19, 27. Mai 2014 (Signatur nachgetragen von: Jürgen 09:50, 27. Mai 2014 (CEST) -- bitte künftig mit 4 Tilden ~~~~ selbst erledigen)

Diesen Kommentar im Code habe ich entfernt und stattdessen hierher gesetzt: Zum einen gehören Anmerkungen grundsätzlich auf die Diskussionsseite. Zum andern ist das eine Anmerkung, wie sie auf Programmierer-Foren geliebt wird:   Sollen andere Leser raten, wie die Fehlermeldung lautet? Welchen Wert hast du für n festgelegt? Hast du mit Debugger gearbeitet? Wenn nein, warum nicht (für die Fehlersuche ist er schließlich da)? Wenn ja, an welcher Stelle des Codes tritt der Fehler auf? Welche Werte tragen die Variablen an dieser Stelle? So unvollständig kann niemand auf diesen Hinweis eingehen. -- Jürgen 09:50, 27. Mai 2014 (CEST)

Dafür, dass ein Leser(!) einen brauchbaren Hinweis auf einen Fehler liefert (C#, n=100000, Fehlermeldung kommt), sollte die Community dankbar sein, unabhängig von der suboptimalen Form, statt mit dieser Überheblichkeit zu reagieren. Es ist ja die Community, die meint, ein 10%-Buch, das Jahre verwaist ist, nicht zeitnah löschen zu müssen. Also muss man auch bereit sein, solche Bücher, die wesentlich zur "Müllhalde" (aktueller O-Ton eines Admin) beitragen, zu verwalten. Die zu 99% unfähigen Autoren verdienen vielleicht so einen Umgang (sind eh weg), aber kein Leser. (Sorry, Fabi, aber guck dich lieber woanders um.) --92.196.75.41 10:41, 27. Mai 2014 (CEST)

Unterabschnitte für Implementierungen

Moin,
hat jemand etwas dagegen, wenn ich die einzelnen Implementierungen eine Gliederungsebene tiefer schiebe, sprich eine Überschrift "Implementierungen" o.Ä. darüber setze? Das würde es erlauben, den entstehenden Abschnitt als ganzes in die Algorithmensammlung einzubinden. -- Pberndt 18:02, 11. Mär. 2016 (CET)