Entwickler-Ecke

Algorithmen, Optimierung und Assembler - Faktorisieren von etwas größeren Zahlen


Mathematiker - Do 21.06.12 22:46
Titel: Faktorisieren von etwas größeren Zahlen
Hallo,
wieder einmal ein kleines Programm meinerseits. Dieses versucht von etwas größeren, natürlichen Zahlen (20 Stellen und mehr) die Primteiler zu ermitteln.
Grundlage dafür ist nach Probedivision das Pollard-Rho-Verfahren. http://de.wikipedia.org/wiki/Pollard-Rho-Methode
Außerdem wird ein Primzahltest nach Rabin-Miller durchgeführt.
Das Programm kann sich zwar mit professionellen Faktorisierungsprogrammen (Faktorisierung mit elliptischen Kurven oder quadratischen Sieben) nicht messen, aber bis zu 30stelligen Zahlen geht es schon; wenn man Glück hat. :rofl: Das Pollard-Rho-Verfahren ist leider "nur" probabilistisch.
Beste Grüße
Mathematiker

Nachtrag: Durch die Mitarbeit von Lelf wurde das Pollard-Rho-Verfahren gegen das wesentlich schnellere Brent-Rho-Verfahren getauscht.


Delphi-Laie - Fr 22.06.12 07:54

Feine Leistung, prima!


Lelf - Sa 23.06.12 14:48

was ich mir noch wünschen würde:
- Abfangen von falschen Zeichen in Edit1
- ein Zeitanzeige
- Korrektur in FGIntRabinMiller:

Delphi-Quelltext
1:
While ((temp1.Number[1Mod 2) = 0)and(FGIntCompareAbs(temp1, zero) <> eq) Do Begin                    

- eine Brent-rho Implementierung:

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:
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:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
120:
121:
122:
123:
124:
125:
126:
127:
128:
129:
130:
131:
132:
133:
134:
135:
136:
137:
138:
139:
140:
141:
142:
143:
unit UBrentRho;

interface

uses FGInt;  //copyright 2000, Walied Othman

  function BrentRho(var A: TFGInt; var d: integer; var Z: TFGInt): string;

implementation

uses Forms, Math, SysUtils, Windows, ufaktor;
                                             //803143374682433343421987  8,05sec
                                         //Teiler = 23894352497 * 33612267785171

//------------------------------------------------------------------------------
  function BrentRho(var A: TFGInt; var d: integer; var Z: TFGInt): string;
  var
    okay: boolean;
    s: string;
    r, i, j, k, m: integer;
    time, t: cardinal; //Zeit-Messung Unit Windows
    xx, yy, tt, tmp, temp1, temp2, factorGGT, one: TFGInt;

  label neu;

  begin
    if(Length(A.Number) = 0)then
      exit;

    Base10StringToFGInt('0', xx);
    Base10StringToFGInt('0', yy);
    Base10StringToFGInt('0', temp1);
    Base10StringToFGInt('1', temp2);
    Base10StringToFGInt('1', factorGGT);
    Base10StringToFGInt('1', one);
    Base10StringToFGInt('0', tt);
    Base10StringToFGInt('0', tmp);
    result:='';
    time:= GetTickCount;;

    TRY

      FGIntRabinMiller(A, 3, okay);
      if(okay)then begin
        FGIntToBase10String(A, s);
        result:= format('%s', [s]);
        d:=0;
      end;
      WHILE not(okay)DO BEGIN
neu:
        d:=0;
        r:=1;
        m:=1024;

        while(FGIntCompareAbs(factorGGT, one) = eq)do begin

          FGIntCopy(yy, xx);        //xx = yy
          for i:=1 to r do begin
             FGIntSquare(yy, tt);
             FGIntAdd(tt, Z, tmp);
             FGIntMod(tmp, A, yy);  //yy = (yy²+1) mod A
          end;

          k:=0;
          j:= min(m, r);

          repeat

            for i:=j downto 1 do begin
               FGIntSquare(yy, tt);
               FGIntAdd(tt, Z, tmp);
               FGIntMod(tmp, A, yy);

               FGIntSub(xx, yy, temp1);    //temp1 = xx - yy
               FGIntAbs(temp1);
               FGIntMul(temp1, temp2, tt);
               FGIntMod(tt, A, temp2);     //temp2 = (temp1*temp2) mod A
            end;

            FGIntGCD(temp2, A, factorGGT);
            d:=d + 1;
            k:=k + m;

            if(d and 7 = 0)then begin
              t:= GetTickCount;
              Application.ProcessMessages;
              Form1.lblZeit.Caption:= Format('D: %d  time: %.1f sec', [d, (t - time)/1000]);
              if(abbruch)then begin
                Form1.Memo1.Lines.Add(Format('abgebrochen bei D: %d', [d]));
                exit;
              end;
            end;

          until((k >= r) or (FGIntCompareAbs(factorGGT, one) <> eq));

          r:= r shl 1;  //r:= r + r;

        end;

        if(FGIntCompareAbs(factorGGT, one) <> eq)then begin

          FGIntToBase10String(factorGGT, s);
          FGIntDiv(A, factorGGT, A);

          if(FGIntCompareAbs(A, one) = eq)then begin
            FGIntCopy(factorGGT, A);
            FGIntAdd(Z, one, Z);      //anderes Z versuchen !!
            Base10StringToFGInt('1', temp2);
            Base10StringToFGInt('1', factorGGT);
            goto neu;
          end else
            result:= format('%s%s * ', [result, s]);

          FGIntRabinMiller(A, 3, okay);
          if(okay)then begin
            FGIntToBase10String(A, s);
            result:= format('%s%s', [result, s]);
          end else
            Base10StringToFGInt('1', factorGGT);

        end;

      END;                         // 347068499990683866034691710961
                                   // = 98296514606911 * 3530832210873551
      FGIntToBase10String(Z, s);
      Form1.lblZeit.Caption:=
        Format('D: %d    Z: %s    time: %.2f sec   fertig!',
              [d, s, (GetTickCount - time)/1000]);

    FINALLY
      FGIntDestroy(xx);
      FGIntDestroy(yy);
      FGIntDestroy(temp1);
      FGIntDestroy(temp2);
      FGIntDestroy(factorGGT);
      FGIntDestroy(one);
      FGIntDestroy(tt);
      FGIntDestroy(tmp);
    END;
  end;    //BrentRhoTFGInt
//------------------------------------------------------------------------------

end.


Aufruf in TForm1.Button1Click(Sender: TObject); wäre dann:

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
var ...         
..., A, Zz: TFGInt;
begin
...
Base10StringToFGInt(k, A);
Base10StringToFGInt('1', Zz);   //besser noch Zz variabel wählbar über Eingabefeld
                                //beträchtliche Unterschiede in der Laufzeit 
k:= BrentRho(A, d, Zz);
...
memo1.lines.add('Teiler = '+k);
...
end;




Gruß Lelf

Moderiert von user profile iconChristian S.: Delphi-Tags hinzugefügt


Mathematiker - Sa 23.06.12 15:06

Hallo Lelf,
besten Dank für die vielen, guten Hinweise. Ich werde diese einbeziehen.
Danke
Mathematiker

Nachtrag: Auf Grund der Unterstützung durch Lelf ist die überarbeitete Version noch schneller. (siehe neue Version im ersten Eintrag)


Lelf - Sa 23.06.12 20:46

Hallo Mathematiker,

wenn Du Dein Programm noch wirkungvoller gestalten willst, empfehle ich Dir anstelle der unit FGInt eine effizientere Library zu verwenden wie zum Beispiel:

MPArith package unter http: http://www.wolfgang-ehrhardt.de

Mit einer ähnlichen Library habe ich folgende Ergebnisse erziehlt:

Faktoren von 347 068 499 990 683 866 034 691 710 961 (30)
98296514606911(14)
3530832210873551(16)
Brent-rho: 1,6976sec d: 132 z: 32

Faktoren von 85 663 386 900 622 087 599 187 757 435 826 763 (35)
48616941244147(14)
1762006919983579059529(22)
Brent-rho: 7,0012sec d: 419 z: 12

Gruß Lelf


Delphi-Laie - So 24.06.12 10:15

user profile iconLelf hat folgendes geschrieben Zum zitierten Posting springen:
Hallo Mathematiker,

wenn Du Dein Programm noch wirkungvoller gestalten willst, empfehle ich Dir anstelle der unit FGInt eine effizientere Library zu verwenden wie zum Beispiel:

MPArith package unter http: http://www.wolfgang-ehrhardt.de


Und wie schaut es diesbzeüglich mit Benny Baumanns BigNum2-Unit (meinem derzeitigen Favoriten) aus? Muß diese den Vergleich zur Wolfgang Ehrhardts Unit nicht scheuen oder doch?


Mathematiker - So 24.06.12 10:22

Hallo Delphi-Laie,
user profile iconDelphi-Laie hat folgendes geschrieben Zum zitierten Posting springen:
Und wie schaut es diesbzeüglich mit Benny Baumanns BigNum2-Unit (meinem derzeitigen Favoriten) aus? Muß diese den Vergleich zur Wolfgang Ehrhardts Unit nicht scheuen oder doch?

Kann ich noch nicht sagen. Im Moment bin ich gerade dabei, die 3 Units FGInt, MPArith und BigNum2 miteinander zuvergleichen. Gegenwärtig liegt MPArith im Vergleich zu FGInt klar vorn, BigNum2 muss ich noch ausprobieren. Dazu muss ich die Verwendung von BigNum2 aber erst einmal verstehen.
MPArith ist zwar superschnell aber schlechter zu handhaben als FGInt. Insbesondere die Freigabe des verwendeten Speichers am Ende ist etwas problematisch.
Beste Grüße
Mathematiker


Delphi-Laie - So 24.06.12 10:37

Die Frage war vornehmlich an Lelf gerichtet.

user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
Dazu muss ich die Verwendung von BigNum2 aber erst einmal verstehen.


Das sollte eigentlich kein Problem sein. Es gibt zwei Schnittstellenfunktionen, die Strings in BigNums bzw. umgekehrt konvertieren. Ein zusätzlicher Parameter muß dabei gesetzt werden, um mitzuteilen, ob Dezimal- oder Hexadezimalen gemeint bzw. gewünscht sind (das war mir auf die Dauer jedoch zu fummelig und unübersichtlich, deshalb kreierte ich neue Funktionen, die auf diesen Parameter verzichten, und noch weitere, die Kovertierung Cardinal<>BigNum vereinfachen - siehe in meinem Langzahlentaschenrechner). Der Rest sind - zum Glück - Funktionen mit selbsterklärenden Bezeichnungen, ich halte die Unit deshalb insgesamt für gut "handhabbar". In seiner BigNum-Diskussionen setzte ich einige meiner Beoachtungen hinein.


Lelf - So 24.06.12 12:51

Hallo,

Die BigNum2-Unit braucht einen Vergleich zu anderen Libraries keinesfalls zu scheuen. Sie ist wirklich Klasse und schön schlank.

Ich bin gerade dabei die oben beschriebene Brent-Rho-Procedure mit BigNum2 zu implementieren und finde keine Rabin-Miller-Primzahltest. Habe ich etwas übersehen?

Gruß Lelf.


Mathematiker - So 24.06.12 12:55

Hallo Lelf,
user profile iconLelf hat folgendes geschrieben Zum zitierten Posting springen:
Ich bin gerade dabei die oben beschriebene Brent-Rho-Procedure mit BigNum2 zu implementieren und finde keine Rabin-Miller-Primzahltest. Habe ich etwas übersehen?

Hast Du nicht. BigNum2 braucht noch ein paar Routinen für Primzahlen. Vielleicht kannst Du sie ja schreiben.
Übrigens kämpfe ich im Moment mit Deiner Brent-Rho-Methode für FGInt. Sie ist superschnell, nur leider gibt sie ab und an keine Primteiler sondern zusammengesetzte Zahlen zurück. Bis jetzt konnte ich ihr das noch nicht abgewöhnen :? .
Beste Grüße
Mathematiker


Lelf - So 24.06.12 14:41

Hallo Mathematiker

Verwende in einem solchen Fall ein anderes z und rechne von vorn oder starte neu mit anderen Anfanfswerten für xx und/oder yy.

Gruß Lelf


Gammatester - Mo 25.06.12 13:40

Warum neu anfangen? Ein zusammengesetztes Ergebnis ist doch (wenn's nicht gerade der Ausgangswert N ist) viel besser: Du hast dann mindestens zwei Faktoren zu Preis von einem!

Im Übrigen ist das oben implementierte Pollard-Brent-Verfahren nicht Standard. Normalerweise macht macht man eine Kopie des letzten Zwischenergebnisses mit ggt=1 und verwendet dies als Aufsetzpunkt für ein normales Pollard-Rho, wenn der ggt=N ist, siehe zB Pollard-Brent-Code [http://comeoncodeon.wordpress.com/2010/09/18/pollard-rho-brent-integer-factorization/]. Dieser Teil ist (soweit ich das sehe) nicht implementiert, und würde einen Neustart für Faktor=N vermeiden.

Aber der Geschwindigkeitsvorteil von Pollard-Brent ist relativ. Wenn nur ein Verfahren verwendet werden soll, ist es idR schneller als Pollard-Rho, aber es gibt andere kompakte Verfahren (p+1, p-1) für spezielle Zahlen oder ECM für allgemeinere Zahlen, die normalerweise schneller sind. Deshalb benutze ich in MPArith ein paar Pollard-Rho-Zyklen (allerdings mit schneller Barret-Reduktion statt mod) nach wenigen Iterationen der 'kleinen Spezial-Verfahren' bevor die Hauptarbeit von ECM gemacht wird.

An ein Quadratisches Sieb [http://de.wikipedia.org/wiki/Quadratisches_Sieb] wie MPQS oder gar an NFS habe ich mich nicht getraut, wäre wohl nur etwas für Hardcore - Langstrecken - Faktorisierer.


Lelf - Mo 25.06.12 17:10

Hallo

Daß die oben implementierte Brent-Rho-Methode nur für bestimmte Zwecke zu gebrauchen ist und Teiler von max. 14-15 Dezimalstellen innerhalb einer Minute(wenn es gut geht) finden kann, ist mir durchaus bewusst. Der Rat, mit einem neuen z zu rechnen, war eigentlich ein pädagogischer. Ich wollte die Interessierten dieses Themas dazu bringen, mit verschieden z's zu spielen, damit folgender Zusammenhang zu beobachten wäre:

_____________________________
Brent-rho Number: 26319475462595362139394151429 (29) BitLength: 95
factors: 1056550654801 (L13) * 24910755904602229 (L17)
d: 640 z: 1
time: 8,990 sec
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ 25.06.2012 15:20:37
_____________________________
Brent-rho Number: 26319475462595362139394151429 (29) BitLength: 95
factors: 1056550654801 (L13) * 24910755904602229 (L17)
d: 41 z: 7
time: 0,375 sec
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ 25.06.2012 15:21:17
_____________________________
Brent-rho Number: 26319475462595362139394151429 (29) BitLength: 95
factors: 1056550654801 (L13) * 24910755904602229 (L17)
d: 1050 z: 455357030
time: 16,333 sec
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ 25.06.2012 17:01:27

Gammatester hat natürlich richtig bemerkt, daß ein totaler Neuanfang nicht nötig ist.

Gruß Lelf


Mathematiker - Do 28.06.12 19:47

Hallo Lelf,
user profile iconLelf hat folgendes geschrieben Zum zitierten Posting springen:
Nun habe ich noch den Brent-rho-Algorithmus mit mPArith implementiert.

Sehr schön, ist richtig schnell. Damit ist das Programm deutlich effektiver geworden.
Aber bei meinem gegenwärtigen Problem, 54061288181178547649030354328049287773587228638908640 zu faktorisieren, reicht es auch nicht. Nachdem ich mein eigenes Faktorisieren mit elliptischen Kurven gegen das von MPArith getauscht habe, komme ich trotzdem nicht weiter.
Beste Grüße
Mathematiker

Nachtrag: Kurz nach dem Absenden des Beitrags erhielt ich als Faktorisierung 2, 2, 2, 2, 2, 3, 5, 7, 13, 94788964849717261630343, 13057077434350756882820861.
Dennoch denke ich, dass es ohne quadratische Zahlsiebe bald nicht mehr geht. Kennst Du bessere Beschreibungen über quadratische Zahlkörpersiebe als die allgemeinen Ausführungen, z.B. bei Wikipedia.


Lelf - Do 28.06.12 21:58

Hallo,

eine gute Beschreibung findest Du z.B. in http://www.karlin.mff.cuni.cz/~krypto/mpqs/main_file.pdf
oder google einfach mal mit MPQS.
Scott Patric Contini hat ein gute Implementierung(in C und GMP) zum Studieren ins Netz gestellt. Ich bastle auch an einer in Delphi. Da gibt es leider kaum eine Vorlage. Aber gerade desshalb is es sehr spannend:

_____________________________
MPQS_LP Number: 54061288181178547649030354328049287773587228638908640 (53) BitLength: 176
NUMBER has small prime factors: (2^5) * 3 * 5 * 7 * 13 *
new Number: 1237666853964710339950328624726403108369670985323 (49)
1. multiplier: 7 H: 9,166504 d: 0,000000 nn8: 5
2. multiplier: 67 H: 8,509277 d: 0,657227 nn8: 1
---> factorbase created. Bound1: 24.083 (maxprime) FB: 1.376 [*5 = 6.880 (LP-array)] 0,047 sec
multiplier: 7 (7,67) Log(Bound1): 10,089261 Differenz (Log(Bound1) - Hmultiplier) = 0,922758
smallprimes (7) = -1,2,3,5,11,13,17,19,29, 31 = primesFB[9]
logstart: 2,558594 n8: 3 nn8: 5 first g: 3606683099 (10)
TARGET_2: 48,260742 SIEVE_INTER: 40.000 M = 320.000 NUM = 8
First decomposed/sec: 309 k/sec: 1892 mal Bound2: 4.816.600 = Bound1 * 200
---> sieving process finished. k: 7.204
checked: 9.114 Polynome: 451 full relations: 763
largeP found: 5.588 partial relations: 645 (M: 232)
ADDITIONAL: 32 d_g34: 41.228
Ø decomposed/sec: 469,333 3,796 sec
---> built matrix. 0,000 sec
---> matrix solved. 0,156 sec
---> factors found. Versuche: 1 0,016 sec
(2^5) * 3 * 5 * 7 * 13 * 13057077434350756882820861 (Q26) * 94788964849717261630343 (Q23) ok, X is prime, Y is prime
time: 4,068 sec
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ 28.06.2012 21:46:15


Gruß Lelf


Mathematiker - Do 28.06.12 22:04

Hallo,
user profile iconLelf hat folgendes geschrieben Zum zitierten Posting springen:
Scott Patric Contini hat ein gute Implementierung(in C und GMP) zum Studieren ins Netz gestellt.

Ich habe einen C-Quelltext (GNU-Lizenz) von Prof.Forster (München) als Bestandteil seines genialen Aribas-Programms erhalten. Da ich aber von C absolut keine Ahnung habe, komme ich damit überhaupt nicht zurecht.
Beste Grüße
Mathematiker


Lelf - Fr 29.06.12 09:16

Hallo Mathematiker,

Eine Fundgrube findest Du, wenn Du mit "quadratic sieve diplomarbeiten" googelst: z.B.:
http://elib.uni-stuttgart.de/opus/volltexte/2005/2409/pdf/STUD_2007.pdf

Da es in Delphi kaum Quelltexte in dieser Sparte gibt, geht wohl kein Weg daran vorbei, sich in C und Java (C ähnlich mit eingebauter BigInteger-Klasse) einzuarbeiten. Java ist meiner Meinung nach das "verständlichere" C.

Ein mächtiges Programm (unglaublich schnell) mit Sourcecode in Java findest Du unter:
http://www.alpertron.com.ar/ECM.HTM

Gruß Lelf


Gammatester - Fr 29.06.12 09:27

user profile iconLelf hat folgendes geschrieben Zum zitierten Posting springen:
Nun habe ich noch den Brent-rho-Algorithmus mit mPArith implementiert.

Leider hat mich erst jetzt der Beitrag mit Anhang erreicht. Zwei Fragen noch:

Gibt es einen besonderen Grund, weshalb Du den über drei Jahre alten Quellcode der Version V1.11 verwendest (wo hast Du den eigentlich noch saugen können?) und nicht den neuesten veröffentlichten MPArith V1.20.24? [http://www.wolfgang-ehrhardt.de/misc_de.html#mparith]

Warum benutzt Du für den Primtest mp_miller_rabin mit t=5? Warum nicht die automatische Wahl mit t=0? Für Deine Größenordnungen würde dann wahrscheinlich t=28 benutzt werden. Warum überhaupt mp_miller_rabin und nicht den Standardprimtest mit mp_is_pprime?

Gruß Gammatester


Mathematiker - Fr 29.06.12 09:28

Hallo Lelf,
das schnellste frei verfügbare Faktorisierungsprogramm soll MSieve 1.50 von Jason Papadopoulos sein.
http://tuts4you.com/download.php?view.1252
Ebenfalls mit Quellcode, aber natürlich wieder in C.
Mit der Version 1.44 habe ich schon 80stellige Zahlen mit zwei 40stelligen Primteilern zerlegt. Richtig schnell!
Gruß Mathematiker


Lelf - Fr 29.06.12 10:14

Hallo,

@Gammatester:
Ganz einfach, vor 3 Jahren habe ich zuletzt die mpArith heruntergeladen und seither
meine eigene mit vielen Anregungen daraus weiterentwickelt.

RabinMiller deswegen, damit man auch sehr grosse Zahlen(>80 stellig) auf kleine Primfaktoren untersuchen kann, um dann mit ECM und QS weiterzumachen.

Den Parameter t habe ich offenbar nicht richtig verstanden. Danke für den Hinweis.

@Mathematiker
MSieve und Yafu sind mir wohl Begriffe. Erwähnenswert wäre noch QSieve von Thorsten Reinecke.
80-stellige Zahlen schaffe ich auch so gerade noch, benötige aber mindestens 2 Stunden dafür. Ich will mich vielleicht noch an das siqs wagen. Aber das wird noch Jahre dauern.

Gruss Lelf


Gammatester - Fr 29.06.12 10:50

user profile iconLelf hat folgendes geschrieben Zum zitierten Posting springen:
RabinMiller deswegen, damit man auch sehr grosse Zahlen(>80 stellig) auf kleine Primfaktoren untersuchen kann, um dann mit ECM und QS weiterzumachen.

Den Parameter t habe ich offenbar nicht richtig verstanden. Danke für den Hinweis.

Miller-Rabin hat sich irgendwie festgesetzt, es ist mM ein Überbleibsel aus 20-30 Jahre alten RSA-Specs (wo es verlangt wird). Neuere Matheprogamme benutzen mehr oder weniger den auch in MPArith/ispprime verwendeten BPSW-Algorithmus (1 x Miller-Rabin mit Basis 2 und schließend 1 x starker Lucastest):
Zitat:
(Mathematica) PrimeQ first tests for divisibility using small primes, then uses the Miller-Rabin strong pseudoprime test base 2 and base 3, and then uses a Lucas test.

(Maple, isprime) It returns false if n is shown to be composite within one strong pseudo-primality test and one Lucas test and returns true otherwise.

(Pari, default BPSW) ispseudoprime(x,{n}): true(1) if x is a strong pseudoprime, false(0) if not. If n is 0 or omitted, use BPSW test, otherwise use strong Rabin-Miller test for n randomly chosen bases.


Gruß Gammatester

PS: Der BPSW-Test kann wie alle Pseudoprimtest nur 'wahrscheinlich' prim sagen. Bisher ist jedoch kein Gegenbeispiel bekannt, wenn Du eines findest, wirst Du mit einem Schlag berühmt (zumindestest in einschlägigen Kreisen) und reich ($620 :wink: , siehe Prize Problems [http://www.wolframalpha.com/input/?i=mathworld+subject+prize+problem]).


Mathematiker - Fr 29.06.12 11:14

Hallo Gammatester,
user profile iconGammatester hat folgendes geschrieben Zum zitierten Posting springen:
Gibt es einen besonderen Grund, weshalb Du den über drei Jahre alten Quellcode der Version V1.11 verwendest ... und nicht den neuesten veröffentlichten MPArith V1.20.24? [http://www.wolfgang-ehrhardt.de/misc_de.html#mparith]

Ich habe gerade 1 Stunde lang die Teilersummenfolge von 840 parallel mit V1.11 und V1.20 rechnen lassen. Das sind über 600 Faktorisierungen von teilweise 40stelligen Zahlen, viele Primzahltests usw.
Genutzt wurde der Miller-Rabin-Test, Lelfs Brent-Rho-Verfahren und die Faktorisierung mit elliptischen Kurven. Alle Parameter waren gleich.
Das Ergebnis ist überraschend: So lange die Glieder der Folge maximal 20 Stellen hatten, war V1.20 vorn. Dann holte die alte Version auf, und als Höhepunkt fand die neue Version für das 400.Glied
18753145125348788607553275398558954818510418200
Primteiler 2, 2, 2, 5, 5, 19, 1257099831268459831417, 3925732919637436942817,
die beiden großen Primteiler nicht, während die alte Version problemlos arbeitete.
Irgendwie komisch.
Beste Grüße
Mathematiker


Gammatester - Fr 29.06.12 11:37

user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
.. und als Höhepunkt fand die neue Version für das 400.Glied
18753145125348788607553275398558954818510418200
Primteiler 2, 2, 2, 5, 5, 19, 1257099831268459831417, 3925732919637436942817,
die beiden großen Primteiler nicht ...

Merkwürdig. Frisch aus dem Archiv kompiliertes t_pfde.exe liefert bei mir

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:
Test of MPArith V1.20.24 (31/32 bit) [mp_calc/pfdu]  (c) W.Ehrhardt 2006-2012
To exit the test program entering an empty expressions string.

Expression to factor: 18753145125348788607553275398558954818510418200
N=18753145125348788607553275398558954818510418200
    2 2344143140668598575944159424819869352313802275
    5 93765725626743943037766376992794774092552091
   19 4935038190881260159882440894357619689081689
SLim: 1073676289
PFD1: 4935038190881260159882440894357619689081689
PRIM: 4935038190881260159882440894357619689081689 - FALSE
Word: ................
PPow:
PP-1: .........................................................................
...........................................................................
WP+1: .........................................................................
...........................................
PRho: .........................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
...............................................................................
..............................................
ECM1: ................................................................
ECM2: .........................................................................
...........
PFD1: 3925732919637436942817
PRIM: 3925732919637436942817 - TRUE
PFD1: 1257099831268459831417
PRIM: 1257099831268459831417 - TRUE
2^3 * 5^2 * 19 * 1257099831268459831417 * 3925732919637436942817
Start: 18753145125348788607553275398558954818510418200
Check: 18753145125348788607553275398558954818510418200
 Time: 33.910s


Moderiert von user profile iconNarses: Beiträge zusammengefasst

Ich sehe gerade, daß in der von Leif angehängten MPArith V1.11 einige Manipulation vorgenommen wurden, zB sind aus mp_prng.pas die Includeanweisungen {$i STD.INC} und {$i mp_conf.inc} entfernt worden (warum auch immer??). Dadurch wird der Taus88-Generator verwendet. Wenn nun V1.20.24 aus der Box benutzt wird, werden völlig verschieden Zufallszahlen generiert (standard mäßig wird ISAAC verwendet). Das kann Auswirkungen auf Geschwindigkeit und/oder Mißerfolg haben, man vergleicht dann eventuell Äpfel mit Birnen. Zumindest liefert das einen Ansatz für die festgestellten Unterschiede, da die eigentlichen ECM-Routinen sind unverändert sind.


Mathematiker - Mo 02.07.12 21:44

Hallo,
mit Hilfe der MPArith-Units von Wolfgang Erhardt enthält das Programm jetzt auch die Faktorisierung mittels elliptischer Kurven. Nach Probedivisionen und dem Brent-Rho-Verfahren wird nun zusätzlich mit dieser sehr schnellen Methode nach Teilern gesucht.
Viel Spaß beim Testen.
Mathematiker

Nachtrag: Da ich nur verkürzte Units im Text hatte, ist der Quelltext vorerst entfernt. Entschuldigung!
Nachtrag 2: Der Quelltext enthält jetzt in den Fremdunits alle Kommentare.


Gammatester - Di 03.07.12 11:22

user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
Hallo,
mit Hilfe der MPArith-Units von Wolfgang Erhardt enthält das Programm jetzt auch die Faktorisierung mittels elliptischer Kurven.

Hallo Mathematiker, leider habe ich mit Bedauern festgestellt, daß Du total verstümmelte Versionen meiner Units verteilst. Die von mir verwendete Zlib-Lizenz ist zwar sehr liberal, aber auch sehr deutlich:

Englisches Original: Altered source versions must be plainly marked as such, ... und deutsch Geaenderte Quellcodes muessen deutlich als solche gekennzeichnet werden ...

Du hast zB aus den Units mp_base, mp_types etc praktisch alle Kommentare, Dokumentation etc gelöscht, ohne das da Du das jeweis deutlich gekennzeichnet hast. Ich bitte ich, also im Sinne von Opensource dies zu unterlassen, oder bei jedem Entfernen/Löschen das deutlich zu kennzeichnen.

Was hast Du eigentlich für ein Problem mit den Kommentaren und Dokus? Warum kannst Du nicht die Original-Sourcen beipacken?

Mit nachdenklichen Grüßen
Wolfgang Ehrhardt


Mathematiker - Di 03.07.12 11:28

user profile iconGammatester hat folgendes geschrieben Zum zitierten Posting springen:

Hallo Mathematiker, leider habe ich mit Bedauern festgestellt, daß Du total verstümmelte Versionen meiner Units verteilst.

Sorry, mein Fehler. Ich werde, dies umgehend ändern.
Beste Grüße
Mathematiker


Gammatester - Di 03.07.12 12:27

user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
user profile iconGammatester hat folgendes geschrieben Zum zitierten Posting springen:

Hallo Mathematiker, leider habe ich mit Bedauern festgestellt, daß Du total verstümmelte Versionen meiner Units verteilst.

Sorry, mein Fehler. Ich werde, dies umgehend ändern.
Beste Grüße
Mathematiker

Danke!

Übrigens sind bei Deiner Aktion (nennt man wohl euphemistisch-denglisch Refaktoring?) gerade die für Delphi interessanten Ansistring-Routinen den Bach 'runtergegangen, zB das schnelle subquadratische mp_radix_astr, Du brauchst also nicht immer über lokale Shortsrings und Pcharszu gehen; aber wenn man alle Hinweise löscht, was die Routinen eigentlich machen, kann sowas schon mal vorkommen :) wie zB in

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
var n: mp_int;
    s:array[0..255of char;
begin
    mp_random_randomize;
    mp_init(n);
    strpcopy(s,bb);
    mp_read_radix(n,s,10);
...
einfach mp_read_decimal_astr(n,bb). Im übrigen scheint das lokale mp_random_randomize genauso kontraproduktiv wie mehrmaliges aufrufen des normalen Delphi randomize. Besser einmal global, oder noch besser die Datei mp_conf.inc beilegen und {$define MPC_Randomize} setzen.

Gruß Gammatester