You need a septic polynomial! Or maybe octic. :smile:

In the K.F. sieve source the placeholder for the number is too short.
See [URL]http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/trunk/src/lasieve4/input-poly.c[/URL]
If you recompile the gnfs-lasieve4I15e from the source with input-poly.c patched to have [I]value[[U]512[/U]],[/I] then it will work...
...but you will need gnfs-lasieve4I16e, ...34-bit LPs and a terabyte of relations. or gnfs-lasieve4I17e?? and 35-bit LPs??
...and it will take the lifetime of you and your grandchildren to do the number.

P.S. [B]Septic is faster[/B]! I've collected 17 rels, q=100000541 (22.98353 sec/rel)
(Don't even tell me that my limits are too low.)

[quote=Syd;146995]Do you have a hint for me why the siever isn't working with m1061 and above while it is working for smaller mersenne numbers?[/quote]

Short answer, the number is just too big.

Slightly longer answer, the sieve works by factoring a great deal of smaller numbers, then manipulating these smaller factorizations in a clever way to reveal the factorization of the larger number. The size of the smaller jobs that are done, and the number of them required, grows with the size of N, your input. They have grown past all practicality for M1061, at least for your (likely) resources and for GGNFS.

[QUOTE=bsquared;147006]Short answer, the number is just too big.

Slightly longer answer, the sieve works by factoring a great deal of smaller numbers, then manipulating these smaller factorizations in a clever way to reveal the factorization of the larger number. The size of the smaller jobs that are done, and the number of them required, grows with the size of N, your input. They have grown past all practicality for M1061, at least for your (likely) resources and for GGNFS.[/QUOTE]

I will bet that there is a multi-precision arithmetic error; probably
an overflow. Something is undoubtedly limited to 1024 bits or smaller.
Look at the defined constants in the code for something limiting the size of
the numbers.

[quote=R.D. Silverman;147022]I will bet that there is a multi-precision arithmetic error; probably
an overflow. Something is undoubtedly limited to 1024 bits or smaller.
Look at the defined constants in the code for something limiting the size of
the numbers.[/quote]

I should qualify... it does, strictly speaking, work. I tried it out on Syd's poly, just to see, and found a few relations. The point I was trying to make was that it is *practically* impossible. As you well know.

@ Syd
You may have left out the Y0 and Y1 lines. You didn't quote them as being in your poly file. If you get it working, you will soon see something like:
total yield: 0, q=4001003 (inf sec/rel)

unless you drastically change the parameters you are using.
(please don't take this as encouragement to keep working on it...)

- ben.

1) The number simply [I]has[/I] to be ECM'd to t65 first. At the very least to N*t60 (which [I]appears[/I] to be the purpose of this thread, anyway). Going to SNFS without this is like doing 100M LL test without TF and P-1 (which is also fashionable these days, I am afraid).

2) The answer (the hint) is above. Do not stop reading after the first line, when/or/if it is a joke (or half a joke in fact. I am actually serious that septic may be better.) The only problem is in the input-poly.c; the number simply gets truncated to 255 chars while scanf'ing. (...ah yes, you also need to change to %511s in the sscanf call)

The point is that K.F. sievers are not limiting for this number. The insanity of going unprepared is the limit.

74 bits ???
 

Does anyone know why the v5 servers is now reporting:
[CODE]
Exponent How far factored (2^n) P-1 Bound #1 P-1 Bound #2
1061 74 45000000000 4500000000000
[/CODE]

[QUOTE=petrw1;147693]Does anyone know why the v5 servers is now reporting:
[CODE]
Exponent How far factored (2^n) P-1 Bound #1 P-1 Bound #2
1061 74 45000000000 4500000000000
[/CODE][/QUOTE]

Maybe someone has TF'ed this number up to 74 bits??

BTW: According to post #47, the P-1 bounds should read B1 = 104*10^10, B2 = 10^18.

[QUOTE=Andi47;147720]Maybe someone has TF'ed this number up to 74 bits??[/QUOTE]

That would be highly unlikely. On Sept 15, 08 Syd went to 62 bits.

I don't have the math handy but I'm pretty sure it would take "+/- forever" to take this exponent to 74 bits.

35 curves with B1 = 260M, B2 = default, using GMP-ECM 6.2

[QUOTE=akruppa;83903]
(*) Note: we've been toying with the idea of a sliding window stage 1 in affine coordinates with many curves in parallel. This could be up to ~20% faster than Montgomery's projective coordinates with PRAC, at the expense of greatly increased memory use. I'm not sure how practical the idea is.[/QUOTE]

Is this still planned / in progress? Any news?

No work done in this regard, and if we write a new stage 1, we'll probably use the Edwards curves that Bernstein and Lange are advocating.

Alex

[QUOTE=Andi47;125574]Done 100 curves with B1 = 260M, B2 = default.

Updated statistics:

[code]
post # curves B2 multiplicator % of t60
1 - 36 23028 various various 25.934
37 1600 default 1 3.808
40 3200 default 1 7.616
41 3200 default 1 7.616
43 100 default 1 0.238
[b]total 31028 45.212[/b][/code][/QUOTE]

I reported these efforts to [URL="http://factorization.ath.cx/search.php?query=2^1061-1"]Syd's Factorization database[/URL] with credit to "Mersenneforum (various contributors)". 45.212% should be worth ~[B]18996[/B] curves at B1 = 260M, B2 = default, so I reported this number of curves.