Anzeige:
Ergebnis 1 bis 11 von 11

Thema: Programm: Fermats Vermutung

  1. #1
    Registrierter Benutzer
    Registriert seit
    06.07.2005
    Beiträge
    14

    Question Programm: Fermats Vermutung

    Ich probiere grade ein Program aus einem Skript aus, das nach der bewiesenen Vermutung von Fermat eigentlich nicht terminieren dürfte. Was stimmt da nicht an derm Code? Sieht jemand den Fehler?
    Code:
    public class Fermat {
    	public static void main(String[] args) {
    		int max=3;
    		boolean ewig= true;
    		while(ewig){
    		 for(int k=3;k<=max;k++)
    		  for(int x=2;x<=max;x++)
    		   for(int y=2;y<=max;y++)
    		    for(int z=2;z<=max;z++)
    		     if((Math.pow(x, k)+Math.pow(y, k))==Math.pow(z, k))
    		     {
    		    	 System.out.println(Math.pow(z, k));
    		    	 ewig=false;
    		     }
    		 max++;
    		}
    		System.out.println("Alarm!");
    	}
    }
    "Alarm!" dürfte nicht ausgegeben werden, wird es aber! Irgendwas stimmt da nicht! Liegt es vielleicht an der Math.pow(double arg1, double arg2) Methode?
    Geändert von aporia (31-03-2006 um 11:33 Uhr)

  2. #2
    Registrierter Benutzer Avatar von Caveman
    Registriert seit
    03.11.2005
    Ort
    Geilsheim
    Beiträge
    308
    Welche Ausgabe bekommst Du denn?
    Was sagt die Zeile:
    System.out.println(Math.pow(z, k));

    Für alle nicht Mathematiker:
    http://de.wikipedia.org/wiki/Diophan...he_Gleichungen
    Programmiere (wenn es denn mal wieder vorkommt) in C, C++, Java, Perl
    Bin kein Student (Elektrotechnik) mehr und habe die Seiten gewechselt von der Software weg hin zur Hardware

  3. #3
    Registrierter Benutzer
    Registriert seit
    06.07.2005
    Beiträge
    14
    Mein Output:
    Code:
    2.1859115597386964E21
    2.1859115597386964E21
    4.722366482869645E21
    1.4063084452067724E22
    3.934640807529654E22
    4.722366482869645E21
    1.4063084452067724E22
    3.934640807529654E22
    Alarm!
    "System.out.println(Math.pow(z, k));" ist eigentlich überflüssig. Habe es eingefügt, um zu sehen, wann er aus der Schleife springt.

  4. #4
    Registrierter Benutzer
    Registriert seit
    06.07.2005
    Beiträge
    14

    Lightbulb Lösung gefunden!

    Ich hab's! 'ewig' muss auf true gesetzt werden! Dann endet er nie! Nochmal der komplette Code:
    Code:
    public class Fermat {
    	public static void main(String[] args) {
    		int max=3;
    		boolean ewig= true;
    		while(ewig){
    		 for(int k=3;k<=max;k++)
    		  for(int x=2;x<=max;x++)
    		   for(int y=2;y<=max;y++)
    		    for(int z=2;z<=max;z++)
    		     if((Math.pow(x, k)+Math.pow(y, k))==Math.pow(z, k))
    		     {
    		    	 System.out.println(Math.pow(z, k));
    		    	 ewig=true;
    		     }
    		 max++;
    		}
    		System.out.println("Alarm!");
    	}
    }

  5. #5
    Registrierter Benutzer Avatar von Caveman
    Registriert seit
    03.11.2005
    Ort
    Geilsheim
    Beiträge
    308
    Deine Zahlen sind sehr groß.
    Double-Werte haben eine Genauigkeit von 64 Bit.
    Diese hast Du hier IMO voll ausgeschöpft.
    Deshalb kommt es zu Ungenauigkeiten, die if-Bedingung wird wahr und damit wird die Schleife verlassen.

    Edit: war zu spät
    Wenn Du ewig immer auf true setzt, macht die Variable keinen Sinn mehr.
    Zu dem bleibt der Ungenauigkeitsfaktor bestehend.
    Programmiere (wenn es denn mal wieder vorkommt) in C, C++, Java, Perl
    Bin kein Student (Elektrotechnik) mehr und habe die Seiten gewechselt von der Software weg hin zur Hardware

  6. #6
    Registrierter Benutzer
    Registriert seit
    06.07.2005
    Beiträge
    14
    hmm ... da hab ich mich wohl zu früh gefreut. Aber Math.pow ist doch per default double. Ne Idee wie ich das umgehen kann?

  7. #7
    Registrierter Benutzer Avatar von Caveman
    Registriert seit
    03.11.2005
    Ort
    Geilsheim
    Beiträge
    308
    Was hast Du damit vor?
    Der Satz ist bewiesen. Willst Du versuchen dies zu wiederlegen?
    Programmiere (wenn es denn mal wieder vorkommt) in C, C++, Java, Perl
    Bin kein Student (Elektrotechnik) mehr und habe die Seiten gewechselt von der Software weg hin zur Hardware

  8. #8
    Registrierter Benutzer
    Registriert seit
    06.07.2005
    Beiträge
    14
    Nein, Quatsch! Es geht nur darum, dass ganze in Java darzustellen. Reines Interesse!

  9. #9
    Registrierter Benutzer Avatar von Caveman
    Registriert seit
    03.11.2005
    Ort
    Geilsheim
    Beiträge
    308
    Dann musst Du dich leider an die Grenzen der Genauigkeit halten.
    Wie und ob es unter Java geht diese zu erhöhen, weiß ich leider nicht.

    Dass man dann weiterhin die Funktion Math.pow() verwenden kann, denke ich eher nicht.
    Programmiere (wenn es denn mal wieder vorkommt) in C, C++, Java, Perl
    Bin kein Student (Elektrotechnik) mehr und habe die Seiten gewechselt von der Software weg hin zur Hardware

  10. #10
    Registrierter Benutzer
    Registriert seit
    05.04.2005
    Beiträge
    8
    Du könntest in Java den Typ BigDecimal benutzen entsprechende Doku findest du bei sun.

  11. #11
    Registrierter Benutzer
    Registriert seit
    29.03.2006
    Beiträge
    11
    Auf Gleicheit bei solchen Berechnungen zu prüfen ist eh immer eine sehr gefährliche Sache. Besser ist bei sowas immer ein >= oder <=, soweit dies möglich ist. Hab mir da das Programm nicht so genau angesehen.

    Das Problem auf das du bei solchen Dingen stößt ist ein numerisches. Da spielen solche Dinge wie Maschinengenauigkeit und Wertebereich der Datentypen eine Rolle.

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •