C++ Primzahlen suchen
-
Dann ist Zeile 20 ja obsolet. Ok danke
-
Tryharder schrieb:
Dann ist Zeile 20 ja obsolet. Ok danke
sie ist ziemlich sinnlos ehrlich gesagt. schau dir mal an was die bedingung ist dass diese zeile aufgerufen wird. und vergleiche es mit der zeile selbst.
-
Ich frage aus Interesse, und das hat nur bedingt mit dem Topic zu tun.
Passiert es später auch auf einem höheren C++ level, dass solche groben Logikfehler gemacht werden und das z.B. ein Projekt immens verlangsamt?
Oder werden diese Fehler mit viel Übungen kaum begangen?
-
Jo, wieso 0 zuweisen, wenn sie schon 0 ist haha.
-
Tryharder schrieb:
Passiert es später auch auf einem höheren C++ level, dass solche groben Logikfehler gemacht werden und das z.B. ein Projekt immens verlangsamt?
Oder werden diese Fehler mit viel Übungen kaum begangen?Kommt drauf an, welche Art von Logikfehler. Fehler in der Programmlogik hat man auf hohem C++-Niveau eher selten, da man C++ so programmieren kann, dass Logikfehler zu Compilerfehlern werden. Logikfehler in dem Sinne, dass man die falsche Vorgehensweise für etwas wählt kann man hingegen auf jedem Niveau haben und hat nichts direkt mit der Sprache zu tun. Aber ein erfahrener Programmierer macht diese Art von Fehler trotzdem seltener, weil er eben mehr Erfahrung hat und viele Probleme schon einmal gelöst hat und die beste Lösung kennt. 99% vieler Problemlösungen sind neu zusammen gesetzte bekannte Lösungen alter Probleme und dann noch 1% Anpassung auf das aktuelle Problem. Du wirst gut im Programmieren, wenn du viele der üblichen Probleme und ihre Lösungen kennst, dann kannst du dich mehr auf das wesentliche konzentrieren.
-
Ok danke für die Klarstellung
.
-
Tryharder schrieb:
Passiert es später auch auf einem höheren C++ level, dass solche groben Logikfehler gemacht werden und das z.B. ein Projekt immens verlangsamt?
Viel viel seltener.
Tryharder schrieb:
Oder werden diese Fehler mit viel Übungen kaum begangen?
So ist es.
Aber man wagt sich auch an immer schwierigere Probleme, es bleibt spannend, und daß man mal ein bis zwei Tage hängt, und die Lösung nicht erzwingen kann, kommt halt vor. Leider kann man später nicht mehr im Forum fragen.
Typisch, daß einem die Lösung beim Duschen einfällt, oder wenn man nachts den Kühlschrank plündert.
Hängt aber auch stark davon ab, was man so programmiert. Den lieben langen Tag Oberflächen stricken, und Du hast gar keine Probleme. Wenn der Verkäufer regelmäßig vollkommen ahnungslos Sachen verkauft, die gar nicht gehen können, oder wenn Mathematiker keine Lust haben, ihre Hausaufgaben selber zu machen und es programmieren lassen wollen, kanns ganz schön nichtamüsierend sein.
-
volkard schrieb:
Aber man wagt sich auch an immer schwierigere Probleme, es bleibt spannend, und daß man mal ein bis zwei Tage hängt, und die Lösung nicht erzwingen kann, kommt halt vor. Leider kann man später nicht mehr im Forum fragen.
Sicherlich, aber man hat bestimmt Kollegen die gerne mal rüber gucken.
-
Tryharder schrieb:
Ich frage aus Interesse, und das hat nur bedingt mit dem Topic zu tun.
Passiert es später auch auf einem höheren C++ level, dass solche groben Logikfehler gemacht werden und das z.B. ein Projekt immens verlangsamt?
Oder werden diese Fehler mit viel Übungen kaum begangen?Fehler können jedem passieren. Aber es ist klar, daß es immer weniger werden, je mehr Erfahrung man/frau hat. Aber auch mit viel Erfahrung kann man/frau mal 'nen schlechten Tag erwischen. Allerdings kennt man halt seine Werkzeuge. Spätestens mit einem Debugger hättest auch Du den Fehler schnell gefunden. Daher frage ich mich auch immer wieder, warum so viele Anfänger, bevor sie den Debugger anwerfen, hier im Forum nachfragen.
Darüber hinaus schreit Dein Code nach Optimierung. Wenn ich sowas sehe, frage ich mich, ob Ihr von Intel bezahlt werdet, möglich ineffiient zu programmieren, damnit Eure Anwender möglichst schnelle CPUs brauchen.
1. Für die Bestimmung ob x eine Primzahl ist, brauchst Du nicht die Anzahl der Teiler sondern es genügt, beim ersten Treffer die Suche abzubrechen. Dann ist nämlich x keine Primzahl.
2. Ebenso ist es nicht notwendig teiler > sqrt( x) zu untersuchen. Denn wenn Du bei teiler <= sqrt( x ) nicht fündig warst, findest Du auch in diesem Bereich keinen.
3. Da Du eh schon eine Liste aller Primzahlen kleiner x hast, genügt es auch sich auf Teiler in Primzahlen zu beschränken. Denn wenn eine Zahl y kein Teiler von x ist sind das auch alle vielfache von y nicht. Da alle Zahlen, die nicht in Deiner Primahlenliste sind ein Vielfaches von mindestens einer Zahl in Deiner Primzahlenliste ist kannst Du die die POrüfung sparen.
4. Gerade Zahlen brauchst Du auch nicht untersuchen also beschränke dich auf ungerade Zahlen:for( x=3; n<max; x+=2 )
mfg Martin
-
mgaeckler schrieb:
Darüber hinaus schreit Dein Code nach Optimierung. Wenn ich sowas sehe, frage ich mich, ob Ihr von Intel bezahlt werdet, möglich ineffiient zu programmieren, damnit Eure Anwender möglichst schnelle CPUs brauchen.
ich glaube, er hat nirgends gefragt wie man den code laufzeittechnisch optimieren kann, da gäbe es auch wesentlich bessere methoden (zumal du das vermutliche bottleneck bei der probedivision-implementierung - das stückweise allozieren im vector - nicht nanntest): siebe.
-
mgaeckler schrieb:
Darüber hinaus schreit Dein Code nach Optimierung. Wenn ich sowas sehe, frage ich mich, ob Ihr von Intel bezahlt werdet, möglich ineffiient zu programmieren, damnit Eure Anwender möglichst schnelle CPUs brauchen.
Offtopic: Gerade CPU-Hersteller sind unter den besten Anlaufstellen, wenn es um Optimierung geht. Der entscheidende Verkaufspunkt von CPUs ist, dass Software möglichst schnell auf ihnen läuft. Die Hersteller verwenden daher reichlich Energie darauf, dass möglichst viel Software möglichst schnell auf ihren CPU läuft.
-
asfdlol schrieb:
(zumal du das vermutliche bottleneck bei der probedivision-implementierung - das stückweise allozieren im vector - nicht nanntest): siebe.
Das Stückweise vergrößern eines std::vector mit push_back ist NICHT lahm.
-
asfdlol schrieb:
ich glaube, er hat nirgends gefragt wie man den code laufzeittechnisch optimieren kann, da gäbe es auch wesentlich bessere methoden (zumal du das vermutliche bottleneck bei der probedivision-implementierung - das stückweise allozieren im vector - nicht nanntest): siebe.
Richtig, aber der Code schrie gerade zu nach Optimierung. Die Punkte, die ich nannte, waren auch die offensichtlichen. Ob es noch mehr Verbesserungspotential gibt, habe ich nicht analysiert.
mfg Martin
-
SeppJ schrieb:
Offtopic: Gerade CPU-Hersteller sind unter den besten Anlaufstellen, wenn es um Optimierung geht. Der entscheidende Verkaufspunkt von CPUs ist, dass Software möglichst schnell auf ihnen läuft. Die Hersteller verwenden daher reichlich Energie darauf, dass möglichst viel Software möglichst schnell auf ihren CPU läuft.
Korrekt, war auch mehr als kleiner Joke und Denkanstoß gedacht.
mfg Martin
-
Mir ist klar, dass das Programm nicht effizient ist und es Optimierungsbedarf gibt. Aber Effizienz spielt für mich erstmal keine Rolle, da ich will, dass das Programm überhaupt läuft. Danach kann man natürlich optimieren. Trotzdem danke für die Vorschläge, das werde ich berücksichtigen.
asfdlol: Bei der nächsten Aufgabe werde ich versuchen, das Sieb von Eratosthenes zu benutzen.
mgaeckler: Der Compiler hat ja keinen Fehler ausgespuckt(deswegen kam ich ja
). Wenn du den Code aus dem TA nimmst, wird dein Compiler sicherlich auch keinen Fehler ausgeben. Ich benutze Visual C++ 2010 express
-
tryharder schrieb:
Der Compiler hat ja keinen Fehler ausgespuckt(deswegen kam ich ja
). Wenn du den Code aus dem TA nimmst, wird dein Compiler sicherlich auch keinen Fehler ausgeben. Ich benutze Visual C++ 2010 express
So lange Du keine syntaktischen Fehler machst oder irgendwelche anderen Fehler, die der Compiler bemerken kann, wird er Dir auch nix sagen. Ich meinte ja auch, daß Du den Debugger hättest bemühen müssen.
mfg Martin
-
Dieser Code
teilt / sammelt alle Primzahlen verdammt schnell, kann man es vielleicht noch einwenig verbessern??? Retorische frage! eine zeile? oder .. nein ... ja?int c=0; int zr=50; for(int i=zr;i>0;i--) { c=0; for(int z=1;z<=zr;z++){ if(i%z==0){ // wenn i durch z rest 0 ist könnte es eine primzahl sein c++; } if(c<=2&&z==i){ // wenn die zahl nur 2 mal teilbar ist, wo rest 0 ergibt ist es eine // primzahl printf(" (%d) ",i); break; } } }
-
Re: C++ Primzahlen suchen, diese ist eine der schnellsten kann man sie noch optimieren, (retorische frage)
int c=0; int zr=50; for(int i=zr;i>0;i--) { c=0; for(int z=1;z<=zr;z++){ if(i%z==0){ // wenn i durch z rest 0 ist könnte es eine primzahl sein c++; } if(c<=2&&z==i){ // wenn die zahl nur 2 mal teilbar ist, wo rest 0 ergibt ist es eine // primzahl printf(" (%d) ",i); break; } } }
Tryharder schrieb:
Hallo Leute,
Ich habe ein Problem mit diesem Code
cout << "n angeben.\n"; // die ersten n Primzahlen finden int n; cin >> n; int count = 0; int x = 0; vector<int> primzahlen; for(int zahl = 3; x<=n; ++zahl){ // Wenn x kleiner oder gleich n ist wird mit dem suchen aufgehört for(int probe = 2; probe < zahl; ++probe){ // jede Zahl wird durch eine "probezahl" geteilt if(zahl%probe == 0) // Kein Rest, dann Primzahl ++count; } if(count == 0){ // Wenn count unverändert, dann zahl in vector gespeichert primzahlen.push_back(zahl); count = 0; // Initialwert zuweisen ++x; // ++x erhöhen, es muss ja irgendwann die Bedingung in der ersten Schleife erfüllt werden } } for(unsigned int i = 0; i < primzahlen.size(); ++i) cout << primzahlen[i] << endl; // Zahlen werden ausgegeben
Aus irgendeinem Grund wird keine Primzahl ausgegeben, obwohl ich mir sicher bin, dass ich keinen Fehler gemacht habe(vllt. Logikfehler). Ich habe eine andere Version zum Primzahlen suchen geschrieben, welche Primzahlen bis zu einem Limit sucht, und diese Version funktioniert makellos.
Es wäre sehr nett, wenn sich jemand die Zeit nimmt und den Fehler entdeckt.mfg, tryharder