Autor Beitrag
Mathematiker
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Di 09.04.13 22: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 user profile iconHorst_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 09:34, insgesamt 5-mal bearbeitet
F34r0fTh3D4rk
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 5284
Erhaltene Danke: 27

Win Vista (32), Win 7 (64)
Eclipse, SciTE, Lazarus
BeitragVerfasst: Di 09.04.13 22:31 
Wie groß werden denn die Primzahlen und dein n bei k > 8 ?
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Di 09.04.13 23:02 
Hallo,
user profile iconF34r0fTh3D4rk hat folgendes geschrieben Zum zitierten Posting springen:
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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 5284
Erhaltene Danke: 27

Win Vista (32), Win 7 (64)
Eclipse, SciTE, Lazarus
BeitragVerfasst: Di 09.04.13 23:23 
Müssen es mindestens k Summen sein oder genau k?
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Di 09.04.13 23:25 
user profile iconF34r0fTh3D4rk hat folgendes geschrieben Zum zitierten Posting springen:
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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 5284
Erhaltene Danke: 27

Win Vista (32), Win 7 (64)
Eclipse, SciTE, Lazarus
BeitragVerfasst: Di 09.04.13 23: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:

ausblenden volle Höhe C#-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:
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 {
    // Für m < 341.550.071.728.321
    public static boolean isPrime(long m) {
    int[] p17 = {2357111317};
    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);
            }
            // Alle Primzahlen kleiner als n sind bekannt
            int k = 0;
            int skip = 0;
            for (int s = 1; s < n; s++) { // s ist die Länge der aktuellen Sequenz
                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 16:15, insgesamt 1-mal bearbeitet

Für diesen Beitrag haben gedankt: Mathematiker
IhopeonlyReader
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 600
Erhaltene Danke: 23


Delphi 7 PE
BeitragVerfasst: Mi 10.04.13 10:27 
wenn es mindestens k summen sein müssen, dann ist bei 36 k auch mindestens 4
du hast geschrieben:
user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
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 :D
Wer nicht brauch was er hat, brauch auch nicht was er nicht hat!
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1652
Erhaltene Danke: 243

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Mi 10.04.13 11: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.user profile iconF34r0fTh3D4rk 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 user profile iconGammatester
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.
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
   tSummand= record
               StartIndex, // bei großen Zahlen  Startzahl
               EndIndex,   // bei großen Zahlen  Endzahl
               Summe  : Int64Longint;
              {Falls wenige Summanden sprich großen Zahlen, also ab weniger als 1000 }
               Pufferindex : integer;
               RingpufferDiffenzen : array Of integer;//length= Anzahl Summanden)
             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.
ausblenden 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
     //ich klappere alle summandenfelder ab.
     with Summanden[SumAnz] do
     Ist S >= Summe dann
       Falls S = Summe dann 
         erhoehe k
       // solange nach größerer Primzahlsuchen bis Summe goeszer s wird 
       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; // =S kann es nicht sein. 
     inc(sumAnz);
   bis sumAnz >= maxSumZahl;
  S = NextPrim(S);
bis SNT // SanktNimmerleinsTag

Dann fehlen noch Bedingen für mehr Summenden etc. pp.

Gruß Horst

@user profile iconIhopeonlyReader
Es bezieht sich aufeinanderfolgende Primzahlen, deshalb kann mein hier skizzierter Ansatz überhaupt funktionieren.
Gammatester
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 328
Erhaltene Danke: 101



BeitragVerfasst: Mi 10.04.13 11:52 
user profile iconIhopeonlyReader hat folgendes geschrieben Zum zitierten Posting springen:
wenn es mindestens k summen sein müssen, dann ist bei 36 k auch mindestens 4
du hast geschrieben:
user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
36 = 5+7+11+13 = 17+19

UND
29+7
23+13
...
oder verstehe ich das Moser-Problem falsch?

Ja. Es wird doch gefordert "eine Darstellung als Summe aufeinander folgender Primzahlen"
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1652
Erhaltene Danke: 243

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Mi 10.04.13 13: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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 10.04.13 14: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. :D

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". :evil:
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
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 918
Erhaltene Danke: 158

Win 10
VS 2013, VS2015
BeitragVerfasst: Mi 10.04.13 16:10 
user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
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". :evil:
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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 10.04.13 16:35 
user profile iconjfheins hat folgendes geschrieben Zum zitierten Posting springen:

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
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 918
Erhaltene Danke: 158

Win 10
VS 2013, VS2015
BeitragVerfasst: Mi 10.04.13 16:42 
Ach deshalb isses eingefroren ^^
Okay, also auf ein neues ;-)
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 10.04.13 16:44 
Hallo jfheins,
user profile iconjfheins hat folgendes geschrieben Zum zitierten Posting springen:
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
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 918
Erhaltene Danke: 158

Win 10
VS 2013, VS2015
BeitragVerfasst: Mi 10.04.13 18: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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 5284
Erhaltene Danke: 27

Win Vista (32), Win 7 (64)
Eclipse, SciTE, Lazarus
BeitragVerfasst: Mi 10.04.13 20: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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 10.04.13 21:40 
Hallo,
user profile iconjfheins hat folgendes geschrieben Zum zitierten Posting springen:
aber ich habe schon paar Ergebnisse:
Zitat:
Berechnung bis 9326037144 ...
10* 1798467197
10 4611108324

user profile iconF34r0fTh3D4rk hat folgendes geschrieben Zum zitierten Posting springen:
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 user profile iconF34r0fTh3D4rk 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. :nixweiss:
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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1652
Erhaltene Danke: 243

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Mi 10.04.13 22: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.
user profile iconMathematiker 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
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
   tkleinerSummand= record
                     StartIndex,
                     EndIndex: Dword;
                     Summe  : Int64;
                     end// 16 Byte

Für kleine Summanden also ein Feld [1.. 25e6] of tKLeinerSummand ~ 400 Mb

ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
   tGroßerSummand= record
                     StartWert,
                     EndWert, 
                     Summe  : Int64;
                     PufferStartPos: ^byte;//oder  Array of byte
                     PufferIndex   :^byte;
                     end// = 3*8+2*4= 32 Byte 
   Ringpuffer = array [0..1000*1001 div 2of byte; // Speichert die Differenzen zwischen den Primzahlen dies ist viel kompakter statt der Primzahlen selbst ~0,5 Mb 
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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 2622
Erhaltene Danke: 1447

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 10.04.13 23:48 
Hallo,
trotz der motivierenden Worte von user profile iconHorst_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
ausblenden Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
   k  kleinste Zahl
   6  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 10:26, insgesamt 2-mal bearbeitet