Arch Linux

Primzahlen in C

johny

Ich möchte eine Zahl eingeben und es soll überprüft werden ob es eine Primzahl ist, also nur durch 1 und sich selbst Teilbar ist. Habe es so realisiert nur gibt es mir nicht immer richtige Ergebnisse raus:
Ich habe den anderen Teil des Programms mal außen vor gelassen also nicht wundern warum keine abschliessenden Klammern unten sind und kein return0.

#include <stdio.h>
int main (void)

{
    int zeichen,
        prim_uberpruefen=0,
        primzahl=0,
        i,
        rest=0,
        teiler=0;
          
    printf ("Bitte wählen Sie eine Funktion:\n1 - Primzahlen\n2 - Ascii-Tabelle\n3 - Fibonacci\n0 - Beenden\n> ");
    while (zeichen !=0)
    {
  
        scanf ("%d", &zeichen);
        switch (zeichen)

        {
            case 1:              
                printf("Bitte geben Sie eine Zahl ein: ");
                scanf("%d",&prim_uberpruefen);
              
                for (i=1;i<=prim_uberpruefen;i++)
                {
              
                    rest = prim_uberpruefen % i;
                    if (rest==0)
                    {
                        teiler++;
                    }
                }

                if (teiler==2)
                {
                    printf("Dies ist eine Primzahl\n");
                }
          
                else  
                {
                    printf ("Dies ist keine Primzahl\n");  
                }

                break;

Also es funktioniert wenn ich das Programm jedes mal neustarre, ich denke es liegt daran das "teiler" schon mit einem wert belegt ist ich müsste es nach jedem Durchgang löschen am besten alle Variablen habe dazu aber noch nichts gelernt.

Gruß

linux-ka

Setz doch <teiler> direkt nach dem case Eintritt auf null. Dann beginnst du stets mit definierter Teileranzahl.

Für die Optik und vielleicht auch Performance :

Da du <rest> eigentlich gar nicht verwendest, steck doch <prim_uberprüfen%i> in die if-Abfrage.

T.M.

Ich sach doch, Du musst die Variablen in der Lebensdauer beschränken, also dort vereinbaren, wo sie gebraucht werden, d.h. die allermeisten innerhalb der Schleife. zeichen ist die einzige Variable, die ausserhalb der Schleife stehen muss.

Die meisten Variablen sollten dann lokal in den case-zweigen definiert werden. Damit das gelingt, solltest Du Dir angewöhnen, generell Klammern um die case-Zweige zu machen:

switch (Ausdruck)
{
  case Wert:
  {
    int x,y,z;
    // ...
    break;
  }
  case Wert:
  {
    float a,b,c;
    // ...
    break;
  }
  case Wert:
  {
    bool b;
    // ...
    break;
  }
  default:
  {
    char c;
    // ...
    break;
  }
}

johny

Ok jetzt funktioniert es richtig nachdem ich teiler=0 direkt nach dem Case eingebracht habe..

Du meinst es so?


					if (prim_uberpruefen%i==0)
					{
						teiler++;
					}

linux-ka

So würd ich es machen, ja.

johny

Okay scheint sinnvoll, danke!

portix

Du könntest da noch einiges optimieren, in deiner Implementierung wird die for-Schleife immer bis zur Zahl durchlaufen auf die du testen willst, das heißt beispielsweise bei allen geraden Zahlen wird die Schleife bis zum Ende durchlaufen auch wenn du bei i=2 schon weißt, dass es keine Primzahl ist. Zudem muss die Schleife nicht bis zur Primzahl selbst durchlaufen werden, wenn die Zahl einen Teiler hat dann kann der höchstens so groß sein wie die Wurzel der Zahl auf die du testen willst.

johny

bei einem "case 0; return0;" braucht man da auch noch ein "break;" hinten dran in einer Switch-Case Anweisung?

T.M.

johny schriebbei einem "case 0; return0;" braucht man da auch noch ein "break;" hinten dran in einer Switch-Case Anweisung?

Hinter einem return muss kein break kommen. Es ist aber dort auch nicht falsch, es ist redundant. Achtung aber bei bedingten returns:

case 12:
{
  if (z == 3)
    return 17; // bedingtes return!
  // ...
  break; // abschliessendes break notwendig
}

Achtung auch bei bedingten breaks:

case 12:
{
  if (z == 3)
    break; // bedingtes break!
  // ...
  break; // abschliessendes break notwendig
}

johny

Ich habe deinen Post #3 jetzt erst gesehen oO. Habe die Variablen jetzt in die einzelnen Case Blöcke in Klammern gesteckt, scheint vernünftiger zu sein. Ich frage mich ob ich irgendwie testen kann wieviel Speicher es weniger verbraucht wenn ich die Lebensdauer der Variablen so beschränke?

Gruß

T.M.

johny schriebIch frage mich ob ich irgendwie testen kann wieviel Speicher es weniger verbraucht wenn ich die Lebensdauer der Variablen so beschränke?

Es geht hier um Stack-Speicher. Diese Variablen liegen ja alle auf dem Stack. Einen insgesamt geringeren Speicherbedarf wirst Du kaum bemerken, da die Stack-Grösse meist fest vorgegeben ist, aber die Stackbelastung ist natürlich geringer, weil immer wieder das Unbenötigte freigegeben wird, anstatt es bis zum Ende in Benutzung zu lassen.

Der Vorteil dieser Schreibweise liegt mehr auf Deiner Seite: Du hast nur bestimmte Variablen im Focus, nur die interessieren jetzt. Der Compiler meldet Dir, wenn Du auf eine zugreifst, die nicht dazugehört, weil sie aus einem anderen Block stammt. Und Du machst dann das mit der Initialisierung wahrscheinlich automatisch richtig, nämlich sauber in jedem Schleifendurchlauf, anstatt einmal oben am Anfang der Funktion.

Smon

johny schriebbraucht man da auch noch ein "break;"

Ich brauche auch gar kein break, es kommt immer darauf an, was ich erreichen will.
Beispiel:

#include <stdio.h>
#include <stdlib.h>
#define SIZE 100

int main(  ) {

	int dest[ SIZE ];
	int source[ SIZE ];
	int i;

	for( i = 0; i < SIZE; i++ ) {
		dest[ i ] = 11;
		source[ i ] = 123;
	}

        int n = (SIZE + 3) / 4;
        i = 0;
 
        switch(SIZE % 4) {
        case 0:        do { dest[i] = source[i]; i++;
        case 3:             dest[i] = source[i]; i++;
        case 2:             dest[i] = source[i]; i++;
        case 1:             dest[i] = source[i]; i++;
                       } while(--n > 0);
        }

	for( i = 0; i < SIZE; i++ ) {
		printf( "%d : %d\n", i, dest[i] );
	}

	return 0;
}

T.M.

Smon schrieb

        switch(SIZE % 4) {
        case 0:        do { dest[i] = source[i]; i++;
        case 3:             dest[i] = source[i]; i++;
        case 2:             dest[i] = source[i]; i++;
        case 1:             dest[i] = source[i]; i++;
                       } while(--n > 0);
        }

Frag fünf ausgebildete C-Programmierer, was dieses Programm tut, und Du kriegst sechs verschiedene Meinungen.

Creshal

T.M. schrieb

Smon schrieb

        switch(SIZE % 4) {
        case 0:        do { dest[i] = source[i]; i++;
        case 3:             dest[i] = source[i]; i++;
        case 2:             dest[i] = source[i]; i++;
        case 1:             dest[i] = source[i]; i++;
                       } while(--n > 0);
        }

Frag fünf ausgebildete C-Programmierer, was dieses Programm tut, und Du kriegst sechs verschiedene Meinungen.

Frag den Erfinder dieses Konstrukts und du kriegst sechs verschiedene Meinungen. 😃

Smon

T.M. schriebFrag fünf ausgebildete C-Programmierer, was dieses Programm tut, und Du kriegst sechs verschiedene Meinungen.

Dann unterscheidet sich wohl unsere Auffassungen des Begriffs "ausgebildet".

@Creshal: Es reduziert die Anzahl der jle Abfragen.
'do {' gibt lediglich die Sprungadresse für das while an.
Beim ersten mal Springe ich in die Schleife, damit der Rest des Arrays durch 4 teilbar ist. (Ein Vielfaches von 4 ist)
Dann springe ich immer zum Anfang der Schleife und führe den Code 'dest[ i ] = source[ i ]; i++;' pro Schleifendurchlauf 4x aus.

[gelöscht]

Ich muss T.M. zustimmen, hier sind nicht Programmierer oft ziemlich uneinig, ich arbeite zwar "nur" als FISI, aber bei uns in der Abteilung sitzen drei Programmierer und wie oft die sich uneinig sind, das ist schon nicht mehr zu fassen. Was deine Primzahlen angeht, hast du es ja jetzt richtig "konstruiert" 😃

Smon

Krizzo schriebich arbeite zwar "nur" als FISI, aber

Danke, dass du meiner Aussage noch einmal Nachdruck verleihst. ;p

T.M.

Smon schrieb
Krizzo schriebich arbeite zwar "nur" als FISI, aber
Danke, dass du meiner Aussage noch einmal Nachdruck verleihst. ;p

Welcher Aussage denn?

Unlesbare Quelltexte kommen in der Praxis leider sehr oft und unter allen möglichen Personen vor. Weil eigentlich immer Zeitdruck herrscht, weil die Leute unterschiedliche Stile haben, sehr oft weil Code von irgendwoher kopiert wird (noch dazu ohne ihn verstanden zu haben), sehr oft auch weil bestehender Code für eine ähnliche (aber eben nicht gleiche) Aufgabe wiederverwendet werden soll, dann wird er oft sehr pragmatisch angepasst.

Nicht nur ärgerlich, sondern ein echter Zeit- und Kostenfaktor ist es, wenn man später Fehler suchen oder Änderungen an einem Code machen muss, den man nicht oder nicht vollständig versteht. Dadurch kommen oft sogar neue Fehler zustande, die man möglicherweise erst sehr spät bemerkt, der Code lief ja immer! Sowas hat häufig überhaupt nichts mit Ausbildung oder Erfahrung zu tun - man kann auch mit 20 Jahren Berufserfahrung manchmal einfach gar nicht so weit um die Ecke denken, wie ein anderer das allerdings getan hat, man hat insbesondere nicht die Zeit dazu, man soll ja andere (!) Aufgaben lösen, als Bestehendes zu analysieren.

Ein Algorithmus muss eigentlich drei Dinge erfüllen: a) er muss die Aufgabe lösen, b) er muss zuverlässig laufen und c) er muss les- und damit wartbar sein. Man ist vor allem im akademischen Umfeld gelegentlich geneigt, daran Abstriche zu machen, insbesondere wenn der Fokus vor allem auf a) liegt. In der Praxis muss ich allerdings auf einen Blick sehen, wie ein Algorithmus funktioniert, welche Verzweigungen unter welchen Bedingungen durchlaufen werden und welche Ergebnisse dabei herauskommen, und ich muss das zuverlässig vorhersagen und nicht erst im Debugger ermitteln können, und zwar auch nach Jahren und Jahrzehnten noch (C++-Quellen sind ja sehr langlebig).

Dein kurzes Stück Text (diese switch-Anweisung) ist ja in der Hinsicht noch banal. Es gibt allerdings, wie ich eingangs schrieb, sehr häufig Texte, die versteht keine Sau mehr, nicht einmal der Autor selbst. Das ist übrigens in allen Sprachen so, nicht nur in C++. Es hat damit zu tun, wie so ein Text entsteht, wie Menschen arbeiten, Fehler machen, diese berichtigen usw. Drum lege ich jedem nahe, sauber zu schreiben.

Smon

Natürlich ist es banal, deswegen verstehe ich auch eure Aufregung nicht.
Was passiert denn wohl, wenn ich in eine Schleife springe?
Eigentlich muss man sich nur vorstellen, wie es wohl übersetzt wird.

T.M. schriebEin Algorithmus muss eigentlich drei Dinge erfüllen

Eigentlich .. ^^
Algorithmus != Code
"Ein Algorithmus ist eine eindeutige Handlungsvorschrift zur Lösung eines Problems" Quelle: https://de.wikipedia.org/wiki/Algorithmus

Kleines Beispiel: In einem Algorithmus muss ich mit 2^x multiplizieren. Ich weiß, dass auf der Zielplattform ein shl immer unabhängig der Eingabe doppelt so schnell ausgeführt wird wie eine Multiplikation. Was nutze ich nun wohl?
Angenommen in meinem Auto ist kein i5. Ich würde trotzdem wollen, dass der Airbag so schnell wie möglich aufgeht und möglichst noch, bevor ich eine Verletzung erleide.
Es ist nunmal nicht in jedem Anwendungsgebiet so, dass man Programme für einen i5 mit 16Gb Speicher schreibt.

T.M. schriebc) er muss les- und damit wartbar sein.

Nicht zwangsläufig, kommt auf den Wunsch des Arbeitgebers an. Es gab mal Projekte, bei denen nach der "Fertigstellung" das Compilat noch optimiert wurde, weil ein Compiler eben auch nicht alles weiß. Keine Ahnung, ob das heute noch irgendwo gemacht wird.

Mal ehrlich, wozu gibt es Kommentare?
Wenn ich Angst habe, dass irgendwer meinen Code nicht kapiert, erkläre ich ihn dahinter nochmal, aber ich nutze nicht extra langsameren Code, nur mit ihn auch der 0815-Praktikant versteht.
Wenn der Arbeitgeber kommt und sagt: "Dieses Programm läuft 6 Monate. Wir wollen, dass es maximal 9 Wochen läuft", dann wird eben mit allen Tricks gearbeitet, auch wenn diese noch so "dreckig" sind.

Verstehe mich bitte nicht falsch, ich stimme dir ja "eigentlich" 😉 zu, was die Wartbarkeit betrifft, nur gibt es eben je nach Aufgabenstellung wichtigere Prioritäten.

Im Prinzip ging es mir nur um die Aussage, weil es sich hier teilweise so anhörte, als braucht man zwingend ein break.

T.M. schriebbreak; // abschliessendes break notwendig.

War nur das erste Gegenbeispiel, welches mir einfiel.

Datenschutz
Impressum