mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Factoring (https://www.mersenneforum.org/forumdisplay.php?f=19)
-   -   10^420 + 1 sieving (https://www.mersenneforum.org/showthread.php?t=12770)

jasonp 2010-02-04 03:26

On the other hand, if you get many of these then there is a mismatch between the polynomials used in the sieving and in the postprocessing. Maybe a coefficient somewhere is missing its last digit?

Batalov 2010-02-04 03:43

Same as Jasonp says, in different words: similar symptoms could happen if some fraction of relations (in this case from relation 16464491 till the end) are concatenated from another project that was being done in parallel. (It did happen to me a few times.)

juno1369 2010-02-04 12:53

[quote=jasonp;204513]On the other hand, if you get many of these then there is a mismatch between the polynomials used in the sieving and in the postprocessing. Maybe a coefficient somewhere is missing its last digit?[/quote]

What do you mean by that?

jasonp 2010-02-04 13:30

There is a great deal of checking of each relation and of the input polynomials when the postprocessing starts; if you get lots of -11 errors then most likely your rational polynomial (the R1 or R0 from msieve.fb) does not match with the rational polynomial used by the sieving. Does the .fb file have a trailing newline? If not, the current release has a bug that causes it to not read that polynomial coefficient. The latest msieve source has a fix though.

Andi47 2010-02-04 13:38

[QUOTE=juno1369;204549]What do you mean by that?[/QUOTE]

If a few occasional "error -xy reading relation xyz" occur on a few single relations, then just these few relations have got somehow corrupted - you can ignore this, it is not harmful.

In your case, you get plenty of errors in consecutive relations. This indicates that at least one of your relation files, which you have concatenated to your msieve.dat file (or your polynomial file), is corrupt. This might have one of the following reasons:

* your msieve.fb file might be corrupt (maybe you have accidently deleted / altered a line or a digit?)
* if you have done (maybe smaller) factorizations in between, your msieve directory could contain an msieve.fb file which no longer fits to the current factoring project.
* one of the relations files which you have concatenated to your msieve.dat files could have been corrupted - maybe due to an error in a zipping/unzipping process
* you might have accidently copied a relations file from an other factoring project to the directory where you collect the relations file for 10^420+1
* you might have accidently copied a wrong (or corrupted) polynomial file to one of the computers which you use for sieving.

Andi47 2010-02-04 13:44

[QUOTE=jasonp;204551]There is a great deal of checking of each relation and of the input polynomials when the postprocessing starts; if you get lots of -11 errors then most likely your rational polynomial (the R1 or R0 from msieve.fb) does not match with the rational polynomial used by the sieving. Does the .fb file have a trailing newline? If not, the current release has a bug that causes it to not read that polynomial coefficient. The latest msieve source has a fix though.[/QUOTE]

Seems Jason was faster (and maybe has a better explanation for the errors than me).

BTW: @JasonP: There have been a few important fixes since the latest official version (1.43), and not everybody has the patience to try and buile a binary from the tarball. (I succeeded to build one for linux, but I did not succeed in windows, perhaps I should try again). Can you please release one of the newest SVNs as an official 1.44 (with an "official" windows binary available)?

juno1369 2010-04-24 00:54

c150 is factored by p67 * p84
 
[quote=Andi47;203879]you will need ~46M relations for a c150, so you are approx. halfway through.[/quote]

Well, according to my c150 summary report, it had 45598432 relations (close enough to ~46M relations) in order to run the linear algebra step. It took 5 days for the Linear Algebra Step. Prior to this, I used Brian Gladman's [SIZE=2]python script which uses both ggnfs and msieve tools. Disaster struck on February 5, 2010, when using the python script that cleared my c150.dat while factoring the number 3 months ago. [/SIZE]To make things easier on Windows in particular, I started the sieving over on the same day it cleared my c150.dat. Here the summary of the c150 factorization:
[code]
Number: c150
N = 191413141591299314411353617644492718709042398621746359743575335167576218516274501587918765785208170431266534615378694736680781077885837943706833300081 (150 digits)
Divisors found:
r1=1146780383632163283649175272843774050715065531735480891145232027761 (pp67)
r2=166913512232431273140362987966641859731500109846278942036790211593884632236221381121 (pp84)
Version: Msieve v. 1.44
Total time: 1321.70 hours.
Factorization parameters were as follows:
n: 191413141591299314411353617644492718709042398621746359743575335167576218516274501587918765785208170431266534615378694736680781077885837943706833300081
skew: 581056.87
# norm 3.49e+020
c5: 417300
c4: 6293707890075
c3: 661926573905922818
c2: -1142910230692705225820950
c1: -305033470566634835042268478702
c0: 13979210859054806935193981807485035
# alpha -5.68
Y1: 22746208757392231
Y0: -53988855542895713658925943846
# Murphy_E 4.74e-012
# M 42516010405424856805684090534471339985472838519578990692918969250315963958564685692805011963349843096316919602745856301635282723806748487864856881786
type: gnfs
rlim: 20800000
alim: 20800000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.6
alambda: 2.6
qintsize: 100000
Factor base limits: 20800000/20800000
Large primes per side: 3
Large prime bits: 29/29
Sieved algebraic special-q in [10400000, 33200000)
Total raw relations: 45598432
Relations: 6859564 relations
Pruned matrix : 4250955 x 4251180
Polynomial selection time: 0.00 hours.
Total sieving time: 1224.80 hours.
Total relation processing time: 0.71 hours.
Matrix solve time: 88.93 hours.
time per square root: 7.25 hours.
Prototype def-par.txt line would be: gnfs,149,5,65,2000,1e-05,0.28,250,20,50000,3600,20800000,20800000,29,29,58,58,2.6,2.6,100000
total time: 1321.70 hours.
--------- CPU info (if available) ----------
[/code]

Batalov 2010-04-24 01:16

Send [URL="http://homes.cerias.purdue.edu/~ssw/cun/"]an email[/URL] to Prof.Wagstaff and you will be immortalized on a [URL="http://homes.cerias.purdue.edu/~ssw/cun/other"]webpage[/URL]. (You already emailed M.Kamada, ok.)

juno1369 2010-04-25 14:51

[quote=Batalov;213007]Send [URL="http://homes.cerias.purdue.edu/%7Essw/cun/"]an email[/URL] to Prof.Wagstaff and you will be immortalized on a [URL="http://homes.cerias.purdue.edu/%7Essw/cun/other"]webpage[/URL]. (You already emailed M.Kamada, ok.)[/quote]

I tried but Sam Wagstaff did not respond to it yet. :sad:

Batalov 2010-04-28 01:11

[quote=bdodson;204509]This message (and error -6 as well) show up on the sieving data
I ship off to Greg and to Serge. They say things like "transient errors"
and non-reproducible. A small percentage of the relns; nothing to
worry about; at least not on this account. -Bruce[/quote]
As I am filtering today, I've written a funny script to remove almost all errors -6/-11, and here it is (an excercise to the reader to figure out what it does; this is not exactly an obfuscated perl entry):
[code]#!/usr/bin/perl -w
while(<>) {
print $_ unless (/^[-0-9]+,(\d+)\d{8}:/ && $1>42);
}
# example of use:
# zcat MyProject.relations.*.gz | ./removeHighBs.pl >> test.dat[/code]

Useless hint #1: [spoiler]msieve uses a 32-bit arithmetic on a,b so b must be <2^32[/spoiler]
Useless hint #2: [spoiler]perl is much more effective at pattern matching, than at arithmetic, so we use that 43*10^8 > 2^32[/spoiler]
42, of course, is [spoiler]the Ultimate Answer to Life, the Universe and Everything[/spoiler]


All times are UTC. The time now is 23:27.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.