Hallo zusammen,
ich bin auf ein neues Projekt gestoßen: bealathome.com
Noch ganz frisch. Der Start wart am 24.03.2014. Anwendungen gibt es für Windows und Linux.
Ein paar Details zu dem mathematischen Inhalt lassen sich auch bereits bei uns hier im Forum finden:
Idee für neues Subprojekt: Gegenbeispiel für Beal-Vermutung
Neues Projekt beal@home
Re: Neues Projekt beal@home
Das Projekt ist reine Strom-Verschwendung. Den Quell-Code findet man hier: https://code.google.com/p/olib/source/b ... e_cpu_v3.c
Man sieht, dass die gleichen Fehler wie auch schon in vorherigen naiven Ansätzen gemacht werden: Es werden nur Potenzen berechnet und dann abgeglichen. Da man jedoch nicht mit Big-Integer-Arithmetik rechnet, sondern sich einbildet, dass die Potenzen in 32-Bit-Datentypen passen, geht das natürlich "vergleichsweise" schnell, liefert aber keine korrekten Ergebnisse. (Es ist nicht definiert, wie sich diese Datentypen bei den nun hier ständig vorkommenden Überläufen verhalten. Im besten Fall finden hier alle Operationen mod 2^32 statt, und das war's.)
Mal davon abgesehen, dass von dem bisschen Grips, von dem ich im oben verlinkten Beitrag geschrieben habe, nichts aber auch gar nichts dort Berücksichtigung findet. Mit anderen Worten: Man liefert dort keine brauchbaren Ergebnisse ab, sondern heizt nur mit der CPU seinen Raum...
Es ergibt übrigens aus heuristischen Gründen wenig Sinn den Suchraum nach maximaler Basis-Größe und maximalem Exponenten zu beschränken: Ein Gegenbeispiel für die Beal-Vermutung findet sich um so wahrscheinlicher, je kleiner die Potenzen sind, nicht je kleiner Basis und Exponent sind (und so ist 2^100 deutlich größer als 1.000.000^4).
Damit man sich von dem Projekt ganz verabschieden kann: Im Moment ist ein Paper mit meiner Co-Autorschaft im Review-Prozess, was einen etwas intelligenteren Ansatz verfolgt. Dort ist mit der Rechenkapazität eines Buro-Rechners (ok, über 3 Wochen) nachgewiesen worden, dass es kein Gegenbeispiel der Beal-Vermutung unterhalb von 10^32 gibt. (Insbesondere ist die Komplexität des Verfahrens nicht mehr O(n^(2/3)), sondern nur O(n^(1/2)), wobei n die obere Schranke des Suchraums angibt und durch entsprechende Überlegungen, die den rechen-intensivsten Teil auf die elementare Operation von binärer UND-Verknüpfung von Bitmasken, welche im L1- bzw. L2-Cahce vorgehalten werden können, beschränken, konnte auch die "Konstante" deutlich verringt werden.)
Damit wäre obiges Projekt wohl eher Jahrhunderte beschäftigt um dieses Ergebnis nachzurechnen...
Man sieht, dass die gleichen Fehler wie auch schon in vorherigen naiven Ansätzen gemacht werden: Es werden nur Potenzen berechnet und dann abgeglichen. Da man jedoch nicht mit Big-Integer-Arithmetik rechnet, sondern sich einbildet, dass die Potenzen in 32-Bit-Datentypen passen, geht das natürlich "vergleichsweise" schnell, liefert aber keine korrekten Ergebnisse. (Es ist nicht definiert, wie sich diese Datentypen bei den nun hier ständig vorkommenden Überläufen verhalten. Im besten Fall finden hier alle Operationen mod 2^32 statt, und das war's.)
Mal davon abgesehen, dass von dem bisschen Grips, von dem ich im oben verlinkten Beitrag geschrieben habe, nichts aber auch gar nichts dort Berücksichtigung findet. Mit anderen Worten: Man liefert dort keine brauchbaren Ergebnisse ab, sondern heizt nur mit der CPU seinen Raum...
Es ergibt übrigens aus heuristischen Gründen wenig Sinn den Suchraum nach maximaler Basis-Größe und maximalem Exponenten zu beschränken: Ein Gegenbeispiel für die Beal-Vermutung findet sich um so wahrscheinlicher, je kleiner die Potenzen sind, nicht je kleiner Basis und Exponent sind (und so ist 2^100 deutlich größer als 1.000.000^4).
Damit man sich von dem Projekt ganz verabschieden kann: Im Moment ist ein Paper mit meiner Co-Autorschaft im Review-Prozess, was einen etwas intelligenteren Ansatz verfolgt. Dort ist mit der Rechenkapazität eines Buro-Rechners (ok, über 3 Wochen) nachgewiesen worden, dass es kein Gegenbeispiel der Beal-Vermutung unterhalb von 10^32 gibt. (Insbesondere ist die Komplexität des Verfahrens nicht mehr O(n^(2/3)), sondern nur O(n^(1/2)), wobei n die obere Schranke des Suchraums angibt und durch entsprechende Überlegungen, die den rechen-intensivsten Teil auf die elementare Operation von binärer UND-Verknüpfung von Bitmasken, welche im L1- bzw. L2-Cahce vorgehalten werden können, beschränken, konnte auch die "Konstante" deutlich verringt werden.)
Damit wäre obiges Projekt wohl eher Jahrhunderte beschäftigt um dieses Ergebnis nachzurechnen...
Re: Neues Projekt beal@home
Ohje
Wenn dein Paper drausen ist, bitte hier verlinken / referenzieren
Btw: Wenn du mal 30MB L3 Cache für paar Tage brauchst, sag bescheid.
Wenn dein Paper drausen ist, bitte hier verlinken / referenzieren
Btw: Wenn du mal 30MB L3 Cache für paar Tage brauchst, sag bescheid.
Re: Neues Projekt beal@home
Nachfolgeprojekt ist jetzt online: BealF@Home http://bealf.pl/bealf/index.php