| 
| Autor | Beitrag |  
| Mathematiker 
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Di 09.04.13 21:17 
 
Hallo,
 ich quäle mich wieder einmal mit einem Zahlenproblem herum, dem Moser-Problem.
 Ist n eine natürliche Zahl, so existiert evtl. eine Darstellung als Summe aufeinander folgender Primzahlen, z.B. 
  36 = 5+7+11+13 = 17+19.
 Dabei sei f(n) = k die Anzahl der verschiedenen Darstellungsmöglichkeiten für n. Auf Leo Moser geht die Frage zurück, ob für jedes f(n) = k ein n existiert. 
 Mein Programm sucht nun nach den jeweils kleinsten Zahlen n, für die k verschiedene Primzahlsummen existieren. Dabei betrachte ich zwei Arten. Zum einen, diejenigen die k echte Summen mit mindestens 2 Primsummanden haben, zum anderen, diejenigen mit k-1 solchen Summen, die jedoch selbst Primzahl sind. 
 In der Ergebnisliste ist die zweite Art mit einem * gekennzeichnet.
 Das Problem ist nun, dass ich über k = 9 nicht hinauskomme. Das Programm ist einfach zu langsam.
 Im Moment verwende ich folgenden Algorithmus:
 Ein dynamisches Feld erhält eine Größe g. Nun werden alle Primzahlsummen von einer unteren Primzahl bis zu einer oberen Primzahl bestimmt, die noch in den Bereich g hineinpassen. Das Feldelement der gefundenen Summe wird erhöht. Danach wird die untere Primzahl erhöht usw.
 Ist der Bereich 0...g abgesucht, wird der Bereich auf g...2g erweitert, danach auf 2g...3g usw. usf.
 Dieses Aufteilen habe ich gewählt, da zum Beispiel ein dynamisches Feld mit theoretisch 1 Milliarde oder mehr Elementen von meinem Rechner nicht mehr (vernünftig) verarbeitet wird.
 Die Suche kann nur mit dem Schalter Stopp abgebrochen werden.
 Wahrscheinlich klingen meine Erklärungen etwas verworren. Aber vielleicht sieht jemand von Euch eine Möglichkeit die Suche zu beschleunigen. k = 12 wollte ich eigentlich erreichen.
 Vielen Dank für Eure Hilfe und beste Grüße
 Mathematiker
 Rev 1/2: Überlauf beseitigt.
 Rev 3: Dank   Horst_H 's Hinweise ist das Feld auf die reinen Primzahlen reduziert. Damit wird weniger Speicher benötigt und die Berechnung läuft schneller.
 Rev 4: Es werden nicht mehr die Primzahlen, sondern nur deren Abstand im Feld gespeichert. Das reduziert die Feldgröße erneut deutlich.
Einloggen, um Attachments anzusehen!
 
_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 
 Zuletzt bearbeitet von Mathematiker am Mo 15.04.13 08:34, insgesamt 5-mal bearbeitet
 |  |  |  
| F34r0fTh3D4rk 
          Beiträge: 5284
 Erhaltene Danke: 27
 
 Win Vista (32), Win 7 (64)
 Eclipse, SciTE, Lazarus
 
 | 
Verfasst: Di 09.04.13 21:31 
 
Wie groß werden denn die Primzahlen und dein n bei k > 8 ? |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Di 09.04.13 22:02 
 
Hallo,
 	  |  F34r0fTh3D4rk hat folgendes geschrieben  : |  	  | Wie groß werden denn die Primzahlen und dein n bei k > 8 ? | 
 Für k = 9* habe ich n = 48205429 mit
 48205429	= 48205429, 46507 » 56611, 124291 » 128749, 176303 » 179461, 331537 » 333397, 433577 » 434939, 541061 » 542149, 2536943 » 2537323, 16068461 » 160668499
 gefunden, wobei a » b Primzahlsumme von a bis b bedeutet. Für ein reines k = 9 kenne ich noch kein n.
 Beste Grüße
 Mathematiker
 Nachtrag: Ich habe nun alle n bis einschließlich 300 Millionen getestet (1 h Computer quälen) und habe für k = 9 noch n = 274452156 gefunden._________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| F34r0fTh3D4rk 
          Beiträge: 5284
 Erhaltene Danke: 27
 
 Win Vista (32), Win 7 (64)
 Eclipse, SciTE, Lazarus
 
 | 
Verfasst: Di 09.04.13 22:23 
 
Müssen es mindestens k Summen sein oder genau k? |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Di 09.04.13 22:25 
 
	  |  F34r0fTh3D4rk hat folgendes geschrieben  : |  	  | Müssen es mindestens k Summen sein oder genau k? | 
 Mindestens k Summen.
 Beste Grüße
 Mathematiker_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| F34r0fTh3D4rk 
          Beiträge: 5284
 Erhaltene Danke: 27
 
 Win Vista (32), Win 7 (64)
 Eclipse, SciTE, Lazarus
 
 | 
Verfasst: Di 09.04.13 22:35 
 
Ich hab grad erst einmal einen naiven Algorithmus in Java implementiert, um das Problem zu verstehen (Der Teufel liegt oft im Detail). Der ist vermutlich auch noch eine ganze Ecke langsamer, als das Verfahren, welches du aktuell verwendest:
 												| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 20:
 21:
 22:
 23:
 24:
 25:
 26:
 27:
 28:
 29:
 30:
 31:
 32:
 33:
 34:
 35:
 36:
 37:
 38:
 39:
 40:
 41:
 42:
 43:
 44:
 45:
 46:
 47:
 48:
 49:
 50:
 51:
 52:
 53:
 54:
 55:
 56:
 57:
 58:
 59:
 60:
 61:
 62:
 63:
 64:
 
 | import java.math.BigInteger;import java.util.ArrayList;
 
 public class Moser {
 public static boolean isPrime(long m) {
 int[] p17 = {2, 3, 5, 7, 11, 13, 17};
 for (int i=0; i<p17.length; i++) {
 int a = p17[i];
 if (m == a) {
 return true;
 }
 BigInteger A = new BigInteger(""+a);
 long b = A.modPow(new BigInteger(""+(m-1)), new BigInteger(""+m)).longValue();
 if (b != 1) {
 return false;
 }
 }
 return true;
 }
 
 
 public static void main(String[] args) {
 int targetK = 4;
 
 ArrayList<Long> primes = new ArrayList<Long>();
 boolean found = false;
 long example = -1;
 for (long n = 2; n < Long.MAX_VALUE; n++) {
 if (isPrime(n)) {
 primes.add(n);
 }
 int k = 0;
 int skip = 0;
 for (int s = 1; s < n; s++) {                 for (int p = primes.size()-(skip + 1); p >= s-1; p--) {
 long sum = 0;
 for (int i = 0; i < s; i++) {
 sum += primes.get(p-i);
 }
 if (sum < n) {
 break;
 }
 if (sum == n) {
 k++;
 skip = s;
 break;
 }
 }
 if (k == targetK) {
 example = n;
 found = true;
 break;
 }
 }
 if (found) {
 break;
 }
 }
 
 System.out.println("Found example for f^-1(k=" + targetK + ") = " + example);
 }
 }
 |  Ich schau mal, was mir da so für Tricks einfallen, um das zu beschleunigen   . 
 EDIT: Wenn Summen der Länge 1 mitgezählt werden sollen, muss s natürlich bei 1 anfangen.
 EDIT2: Hast du das hier  mal gelesen? 
 Zuletzt bearbeitet von F34r0fTh3D4rk am Mi 10.04.13 15:15, insgesamt 1-mal bearbeitet
 Für diesen Beitrag haben gedankt: Mathematiker
 |  |  |  
| IhopeonlyReader 
          Beiträge: 600
 Erhaltene Danke: 23
 
 
 Delphi 7 PE
 
 | 
Verfasst: Mi 10.04.13 09:27 
 
wenn es mindestens k summen sein müssen, dann ist bei 36 k auch mindestens 4
 du hast geschrieben:
 	  |  Mathematiker hat folgendes geschrieben  : |  	  | 36 = 5+7+11+13 = 17+19 | 
 UND
 29+7 
 23+13
 29+5+2
 und wenn die mehrfachnutzung einer Primzahl Möglich ist:
 7+7+7+5+5+5
 ebenfalls zeigt er mir für 311 4* 4 und 5* an... reicht nicht 5* 
 oder verstehe ich das Moser-Problem falsch?_________________ Sucht "neueres" Delphi    Wer nicht brauch was er hat, brauch auch nicht was er nicht hat!
 |  |  |  
| Horst_H 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: Mi 10.04.13 10:51 
 
Hallo,
 Was für merkwürdige Rätsel.
 für k= 12 soll es also minimal 166400805323 sein. 1.6*10¹¹ ist natürlich schon weit über longint hinaus.  F34r0fTh3D4rk  hat Ja in seinem EDIT2 eine passende Seite gefunden, der bis 82 Milliarden die Primzahlen gespeichert hat.Ich bräuchte dafür mindestens 0.198 (1*2*4*6*10*12*16/(2*3*5*7*11*13*17)) *82e9 Bit = 2,035e9 Byte 
 Aber mir fällt etwas auf    	  | Zitat: |  	  | aus www.primepuzzles.net/puzzles/puzz_046.htm
 218918 =
 =  3301  + … + 3769    (62)
 = 4561  + … + 4957    (46)
 = 5623  + … + 5897    (38 )
 = 7691  + … + 7937    (28 )
 = 9851  + … + 10069   (22)
 = 13619  + … + 13729   (16)
 = 18199  + … + 18289   (12)
 | 
 Wenn man die zu untersuchende Zahl erhöht, bleiben die Zahlen, die man z.B. bei 12 Summanden untersuchen muss, natürlicherweise fast identisch.
 218918+1=218919 zu untersuchen findet auf den selben Zahlen statt.Aber viel wichtiger bei sehr großen Zahlen = wenig Summanden.
 Ich brauche in Bereich "großer" Zahlen ja nur ein Primzahlsieb der Region mitzuführen und ab und an aktualisieren wenn man die Region verlässt, oder ich suche eine Funktion NextPrim die eben in gewissen Regionen Miller-Rabin anwendet ( von   Gammatester Die 50,8 Mio Primzahlen bis 1e9 lassen sich ja unkompliziert speichern.
 Für die kleineren Zahlen, viele Summanden, merkt man sich nur den Startwert des Bereiches( Nummer der Primzahl in der Liste) , den Endwert und die Summe von Start bis Endwert.
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 
 |    tSummand= recordStartIndex,                EndIndex,                  Summe  : Int64Longint;
 
 Pufferindex : integer;
 RingpufferDiffenzen : array Of integer;             end;
 Summanden = array of TSummand;
 |  Wie groß ist die Summe aller Primnzahlen bis 1e9?
 Wenn jede 20.te Zahl prim wäre ( 50.8e6/1e9) 1/20 Summe 1..1e9 aber da die Diche der Primzahlen im wichtigen Bereich eher 1/40 ist, somit eher 1/40 * 1e9²/2 = 1.25e16 müsste also für k = 12 reichen.
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 20:
 21:
 22:
 23:
 24:
 25:
 26:
 27:
 
 | Ablauf:Felder der Summandenzahl 1..1000 initialisieren.
 maxSumZahl = 1000;
 Startzahl S = 2+3
 wiederhole
 k = 0
 sumAnz = 2;
 wiederhole
 with Summanden[SumAnz] do
 Ist S >= Summe dann
 Falls S = Summe dann
 erhoehe k
 wiederhole
 np = Nextprim(Endwert)
 summe = summe - Startwert+np
 dec(Startwert,RingpufferDiffenzen[Pufferindex]);
 RingpufferDiffenzen[Pufferindex] := np-Endwert;
 inc(Pufferindex);
 IF Pufferindex >= SumAnz then
 Pufferindex := 0;
 bis Summe >S;      inc(sumAnz);
 bis sumAnz >= maxSumZahl;
 S = NextPrim(S);
 bis SNT
 |  Dann fehlen noch Bedingen für mehr Summenden etc. pp.
 Gruß Horst
 @  IhopeonlyReader Es bezieht sich aufeinanderfolgende Primzahlen, deshalb kann mein hier skizzierter Ansatz überhaupt funktionieren. |  |  |  
| Gammatester 
          Beiträge: 328
 Erhaltene Danke: 101
 
 
 
 
 | 
Verfasst: Mi 10.04.13 10:52 
 |  |  |  
| Horst_H 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: Mi 10.04.13 12:16 
 
Hallo,
 mir fällt gerade noch ein, dass man vielleicht ein Feld mit Zeigern auf eine einfache verkettete Liste machen könnte.
 In diesen Listen steht die Anzahl der Summanden mit gleicher Summe.
 Als S+4 -> 3->6->9->14->17->NIL  ( uups k= 5, jetzt wird es zu einfach... )
 S+5 -> NIL
 ..
 
 Listeneintrag 0 -> in der Liste stehen alle Summanden deren Summe gerade S ist.
 Listeneintrag 1 -> in der Liste stehen alle Summanden deren Summe gerade S+1 ist.
 ..
 Listeneintrag 999 -> in der Liste stehen alle Summanden deren Summe gerade S+999 ist.
 Listeneintrag 1000 alle restlichen, enventuell in 100er/1000er Schritten.
 Dann kann ich erst alle Einträge bis 1000 verarbeiten und aktualisieren und dann einmal komplett auf den neuesten Stand bringen.Dann muss man nicht immer wieder tausende anschauen, obwohl sich nichts getan hat, denn k= 12 kommt das erste Mal bei 1.6e11  oder bezog sich dies auf S= prim?
 
 Gruß Horst
 Für diesen Beitrag haben gedankt: Mathematiker
 |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 10.04.13 13:06 
 
Hallo,
 und Danke an alle mit Ihren guten Vorschlägen. Ich werde sehen, was ich davon verwenden kann.
 Heute Nacht (3.24 Uhr) wurde ich munter und hatte eine Idee zur Beschleunigung des Verfahrens. Es ist wirklich so, dass das Gehirn weiterarbeitet, auch wenn man schläft.
 In der verbesserten Version (siehe 1.Beitrag) berechne ich einmal(!) alle Primzahlsummen 2+3+...+p der ersten m Primzahlen und speichere diese in einem großen Feld. Praktisch ist das die Idee von Horst_H.     Für die möglichen Primzahlsummen muss ich dann nur die möglichen und interessanten Differenzen der Summen auswerten. 
 Das beschleunigt ungemein, allerdings auf Kosten des Speichers. 
 Jetzt werde ich meinen Computer rechnen lassen. Mal sehen, was möglich ist.
 Beste Grüße
 Mathematiker
 Nachtrag: Mit 50 Millionen Primzahlen, d.h. der Suche bis 1,95 Milliarden ergibt sich neu für k = 10* als keinstes n = 1798467197.
 Jetzt müssen es 250 Millionen Primzahlen werden. Bei meinem Computer wird das dauuuuuuuuuuuuuuuuuuuuuuuern.
 Nachtrag 2: Sch... Computer. Über 125 Millionen Primzahlsummen im Feld bekomme ich ein nettes "Out of memory".    Nachtrag 3: Was ist denn jetzt los? Kann das sein, dass das Feld auf die Festplatte ausgelagert wird?_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| jfheins 
          Beiträge: 918
 Erhaltene Danke: 158
 
 Win 10
 VS 2013, VS2015
 
 | 
Verfasst: Mi 10.04.13 15:10 
 
	  |  Mathematiker hat folgendes geschrieben  : |  	  | Nachtrag: Mit 50 Millionen Primzahlen, d.h. der Suche bis 1,95 Milliarden ergibt sich neu für k = 10* als keinstes n = 1798467197. Jetzt müssen es 250 Millionen Primzahlen werden. Bei meinem Computer wird das dauuuuuuuuuuuuuuuuuuuuuuuern.
 Nachtrag 2: Sch... Computer. Über 125 Millionen Primzahlsummen im Feld bekomme ich ein nettes "Out of memory".
   Nachtrag 3: Was ist denn jetzt los? Kann das sein, dass das Feld auf die Festplatte ausgelagert wird?
 | 
 Hi,
 ich kann das ja mal im Hintergrund laufen lassen. bei mit geht's immerhin bis 223 Mio. Primzahlen. (Braucht dann 1,795 GB RAM)
 Aber das Teil hängt bei läppischen 25% CPU Auslastung rum! Kann man da nicht was parallelisieren?
 Und was den RAM angeht: Natürlich lagert Windows nicht benutzte Teile auf die Festplatte aus. Wenn du also 2GB Speicher anforderst und erst mal nur die ersten paar MB benutzt kann es schnell passieren dass der Rest ausgelagert wird.
 Da ich anderweitig zu tun habe, werde ich wohl nicht dazu kommen eine C# Version zu programmieren   |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 10.04.13 15:35 
 
	  |  jfheins hat folgendes geschrieben  : |  	  | ich kann das ja mal im Hintergrund laufen lassen. bei mit geht's immerhin bis 223 Mio. Primzahlen. (Braucht dann 1,795 GB RAM)
 | 
 Breche mal lieber die Berechnung ab. Ich hatte noch einen numerischen Überlauf im Programm. Ist in Rev 1 beseitigt.
 Beste Grüße
 Mathematiker_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| jfheins 
          Beiträge: 918
 Erhaltene Danke: 158
 
 Win 10
 VS 2013, VS2015
 
 | 
Verfasst: Mi 10.04.13 15:42 
 
Ach deshalb isses eingefroren ^^
 Okay, also auf ein neues   |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 10.04.13 15:44 
 
Hallo jfheins,
 	  |  jfheins hat folgendes geschrieben  : |  	  | Okay, also auf ein neues  | 
 Warte mal noch einen Moment. Ich teste gerade auf einem 2.Computer und da stimmt irgendetwas nicht.
 Da tritt schon wieder ein Überlauf ein. Tut mir leid.
 Beste Grüße
 Mathematiker
 Nachtrag: Mit Rev 2 gab's keinen Überlauf mehr. Nochmals Entschuldigung bitte._________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| jfheins 
          Beiträge: 918
 Erhaltene Danke: 158
 
 Win 10
 VS 2013, VS2015
 
 | 
Verfasst: Mi 10.04.13 17:20 
 
Ja, jetzt läuft's einigermaßen    Immer noch nicht multithreaded, aber ich habe schon paar Ergebnisse: 	  | Zitat: |  	  | Berechnung bis 9326037144 2*	5
 2	36
 3*	41
 3	240
 4	311
 4*	311
 5*	311
 5	16277
 6*	34421
 6	130638
 7	218918
 7*	442019
 8*	3634531
 8	9186778
 9*	48205429
 9	274452156
 10*	1798467197
 10	4611108324
 Ende
 gesucht bis 9300000000
 | 
 Edit: Ist fertig. Für diesen Beitrag haben gedankt: Mathematiker
 |  |  |  
| F34r0fTh3D4rk 
          Beiträge: 5284
 Erhaltene Danke: 27
 
 Win Vista (32), Win 7 (64)
 Eclipse, SciTE, Lazarus
 
 | 
Verfasst: Mi 10.04.13 19:56 
 
Wenn man das plottet (angenommen, man nimmt immer das kleinste n), hat die Kurve eine starke Ähnlichkeit zu einer Exponentialfunktion. Ich postuliere weiterhin, dass f(n) normalverteilt ist      . |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 10.04.13 20:40 
 
Hallo,
 	  |  jfheins hat folgendes geschrieben  : |  	  | aber ich habe schon paar Ergebnisse: 	  | Zitat: |  	  | Berechnung bis 9326037144 ... 10*	1798467197
 10	4611108324
 | 
 | 
 	  |  F34r0fTh3D4rk hat folgendes geschrieben  : |  	  | Wenn man das plottet (angenommen, man nimmt immer das kleinste n), hat die Kurve eine starke Ähnlichkeit zu einer Exponentialfunktion. | 
 Wenn man die Ergebnisse sich ansieht und dazu noch den von   F34r0fTh3D4rk  angegebenen Link www.primepuzzles.net/puzzles/puzz_046.htm , so wird klar, dass mit meiner Lösung nichts Neues gefunden werden kann.
 Um den bisher von Wilfred Whiteside getesteten Bereich bis 260 Milliarden zu übertreffen, würde ich deutlich über 5 Milliarden Primzahlsummen benötigen. Das hält wohl kein Speicher aus; nicht zu reden von der extrem steigenden Berechnungs- und Auswertungszeit.
 Fazit: Entweder wir finden eine neue Superidee für das Problem, oder das war's. Leider.    Danke an alle für Eure Bemühungen.
 Beste Grüße
 Mathematiker_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| Horst_H 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: Mi 10.04.13 21:35 
 
Hallo,
 da habe ich etwas nicht verstanden, wie das sein kann:
 	  | Zitat: |  	  | 4 311 4* 311
 5* 311
 | 
 Es kann doch nicht gleichzeitig einer 4er und eine 5er Zerlegung von 311 geben.
 Ach, ich habe es falsch verstanden.Vorher gab es maximal eine dreifache Zerlegung in eine Summe von aufeinander folgender Primzahlen und nun auf einmal direkt eine 5-fache mit 311 prim.
 Lazarus verweigert unter meiner experimentellen Linux-Version irgendetwas auszugeben. Mit Freepascal, als Konsolenprogramm ging es. Jau, gotoXY funktioniert, nachdem ich die Konstante grenze global gemacht habe, die lies sich innerhalb der procedure nicht ändern, das zu finden hat gedauert.
 Wie ist denn eigentlich das Laufzeitverhalten, das müßte doch quadratisch sein.
 Wenn es für 2^32= 4,3e9 2 Stunden waren, sind es für 1,6e11 schätzungsweise:
 (1.6e11/4.3e9)^2 *2h =  2775.5 h = 16,6 Wochen.
  Mathematiker  hat es ja schon erkannt, dass dauert.
 Da ist doch mein Vorschlag nicht übel, mit bis zu 1000 Summanden seperat zu speichern, denn 1000 * Zahlen im Bereich 4e9 sind eben 4e12== 400 Milliarden.
 Die maximale Anzahl an Summanden kann man ja auch bestimmen, das ist die Summe aller Primzahlen ab 2 ..? die dann 4e12 ergeben und dass sind deutlich unter 50 Mio. ich rate 25 Mio.
 Für diese Zahlen mit kleinen Summanden, die man noch im Speicher halten kann reichte ein record von 
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 
 |    tkleinerSummand= recordStartIndex,
 EndIndex: Dword;
 Summe  : Int64;
 end;
 |  Für kleine Summanden also ein Feld [1.. 25e6] of tKLeinerSummand ~ 400 Mb
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 
 |    tGroßerSummand= recordStartWert,
 EndWert,
 Summe  : Int64;
 PufferStartPos: ^byte;                     PufferIndex   :^byte;
 end;    Ringpuffer = array [0..1000*1001 div 2] of byte; Bei 2 Summanden zeigt PufferStartPos auf Ringpuffer[0] PufferIndex geht von 0..0( Summandenzahl-2 )
 Bei 3 Summanden zeigt PufferStartPos auf Ringpuffer[1] PufferIndex geht von 0..1
 Bei 4 Summanden zeigt PufferStartPos auf Ringpuffer[3] PufferIndex geht von 0..2
 Bei 5 Summanden zeigt PufferStartPos auf Ringpuffer[6] PufferIndex geht von 0..3
 |  ..
 Natürlich gingen auch dynamische Felder. Aber brauchen noch mehr Platz, aber bei 1000 Feldern in der Länge von 1,2,3,4..999 ist das kein großer Aufwand.
 Natürlich fehlen noch die Primzahlen 50.8 Mio als DWORD. = 200 Mb
 Also 600 Mb könnten fast reichen    Wer wird denn da verzagen, dass ist doch nur ein Ansporn.
 Wenn man sich auf istPrime verlassen kann, der ja recht schnell zu sein scheint, brauchen nur die obersten Summanden diesen Primtest, wie in dem Link zum prime puzzle46. 
 Vielleicht könnte hier sogar ein 64-Bit Betriebssystem von Vorteil sein, bei den ganzen Int64 hier.
 Gruß Horst Für diesen Beitrag haben gedankt: Mathematiker
 |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 10.04.13 22:48 
 
Hallo,
 trotz der motivierenden Worte von   Horst_H  habe ich erst einmal das Moser-Problem kurz abgebrochen und eine Verallgemeinerung betrachtet.
 Sucht man allgemein die Darstellung einer natürlichen Zahl n als Summe aufeinanderfolgender natürlicher Zahlen (nicht notwendig Primzahlen), so ergeben sich auch für kleine n eine Vielzahl von Möglichkeiten.
 Meine Annahme, dass man schnell viele Zahlen n findet, für die genau k solche Summen existieren, war aber ein Trugschluss.
 Obwohl ich meinen Computer mit 100 Millionen Zahlsummen gequält habe (die Festplatte leistete eine Mammutaufgabe) habe ich keine Zahl gefunden, für die es genau 18 solche Summen gibt. 
 Die ersten Ergebnisse sind
 		                       Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 20:
 21:
 
 |    k  kleinste Zahl6  729
 7  105
 8  225
 9  405
 10  59049
 11  315
 12  531441
 13  3645
 14  2025
 15  945
 16  43046721
 17  1575
 18  ---
 19  2835
 20  18225
 21  295245
 22  ---
 23  3465
 24  50625
 25  2657205
 |  Schön ist, dass man keine Primzahlberechnung mehr braucht. Nicht so schön ist, dass man zum Testen aller Zahlen bis 1 Milliarde nun 500 Millionen Summen benötigt, bei dem Original-Moser-Problem sind es nur etwas über 50 Millionen.
 Aber vielleicht kann man bei diesem "einfacheren" Problem noch schneller einen effektiven Algorithmus finden.
 Ich gehe jetzt erst einmal in's Bett und werde wohl wieder von Zahlen träumen.
 Beste Grüße
 Mathematiker
 Nachtrag: In einem späteren Beitrag habe ich eine sehr schnelle Lösung des Problems. Deshalb ist der Anhang hier nicht mehr vorhanden._________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 
 Zuletzt bearbeitet von Mathematiker am Mo 15.04.13 09:26, insgesamt 2-mal bearbeitet
 |  |  |  |