Nonstandard lasieve binaries
 

A couple of years ago I built 15e with the check for lpb<=33 simply removed (having looked through to see that the large-prime-part was only ever handled by gmp utilities, so wasn't getting trimmed at 64 bits); it worked fine, but I didn't try it on any examples big enough for 34-bit large primes to be needed.

Something that intrigued me in the RSA200 writeup was that the lambda values were 3.6 rather than 2.6; do the 15f and 15g sievers actually allow more than two large primes? I remember Alex's and Thorstein's talks at Nancy in 2008 mentioning several-large-primes variants, but I don't know if they're included in the released source.

IIRC there was one pair of sievers which had a very short diff between them, the only difference was that Q was allowed to be larger than 2^32.

where is the source for the 15f and 15g sievers? i can't find it

Ah, it was courtesy of Alex, actually. [URL="http://mersenneforum.org/showthread.php?p=169889#post169889"]Here[/URL].
[URL="http://mersenneforum.org/attachment.php?attachmentid=3571&d=1240161161"]lasieve5-20081105.tar.bz2[/URL] ([SIZE=1]233.4 KB, 42 views[/SIZE])
15e and 15f have the <=33-bit warning in the code (which can be #if 0'd).
15g doesn't. 15g uses mpz_t for the special_q and more changes.
[COLOR=green]This source uses SCHED_TOL of 2.0; the first thing to try is to use SCHED_TOL of 1.2 plus padding of 48.[/COLOR]

I wonder if there exists an even newer one.
_________

[COLOR=green]By merging the sources and then debugging of what will be broken, 16e/g may (?) be built (totally unsure about the assembly code compatibility). 17*-sievers will not work in the current form (the internal implementation of many structures is in 16-bit integers; even if this is changed, the sievers will become impractical because the memory footprint would immediately double).[/COLOR]

Just for curiosity: Do 16g (or even 17g) sievers exist? (No, I don't have the ressources to actually [I]use[/I] them in a meaningful way, I'm just curious.)

[quote=Batalov;213232]Ah, it was courtesy of Alex, actually. [URL="http://mersenneforum.org/showthread.php?p=169889#post169889"]Here[/URL].
[URL="http://mersenneforum.org/attachment.php?attachmentid=3571&d=1240161161"]lasieve5-20081105.tar.bz2[/URL] ([SIZE=1]233.4 KB, 42 views[/SIZE])
15e and 15f have the <=33-bit warning in the code (which can be #if 0'd).
15g doesn't. 15g uses mpz_t for the special_q and more changes.
[COLOR=green]This source uses SCHED_TOL of 2.0; the first thing to try is to use SCHED_TOL of 1.2 plus padding of 48.[/COLOR]

I wonder if there exists an even newer one.
_________

[COLOR=green]By merging the sources and then debugging of what will be broken, 16e/g may (?) be built (totally unsure about the assembly code compatibility). 17*-sievers will not work in the current form (the internal implementation of many structures is in 16-bit integers; even if this is changed, the sievers will become impractical because the memory footprint would immediately double).[/COLOR][/quote]
Thanks
I booted into linux and successfully compiled 12e.
I had to type:
make libgmp-aux.a
before it would compile though

12f or 12g won't compile for me without further changes
any ideas? is the bug reproducable for you?

[QUOTE=henryzz;213247]Thanks
I booted into linux and successfully compiled 12e.
I had to type:
make libgmp-aux.a
before it would compile though

12f or 12g won't compile for me without further changes
any ideas? is the bug reproducable for you?[/QUOTE]

:question:

Do I understand correctly that the difference between 15e and 15g is that 15g is able to sieve with lpb's bigger than 33? Is there any other difference / advantage of the 1?g-sievers?

If not - what purpose would a 12g siever have? GNFSing 90-digit composites with BIG large primes for testing purpose?
(I'd expect that lpb > 33 would become relevant in regions of 190+ digits where 16g (or even 17g if it exists) sievers will also become relevant...)

"Use the source, Luke, use the source!"
 

I've never built this particular source. I've also been reading on and off the cweave'd commented source and honestly didn't get anywhere close to understanding.

Because it was not a very trivial excercise (.w -> .tex -> .pdf, I've done it a year ago and now my pdftex doesn't run, so I cannot reproduce), I will post [URL="http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/trunk/src/lasieve4/gnfs-lasieve4e.pdf"]this PDF to SourceForge[/URL]. It has all the comments that the .c code doesn't.

I cannot answer any questions about this code.

Ok, a few read-only notes from a nightly build. (everyone who wants to build this source is on their own.)

FWIW, this source builds [I]as is [/I](with a working CWEB).
It is a CWI-oriented source: CWI-poly in, CWI-relations out.
I hacked the GGNFS-poly input and a few patches (right into .w files, of course; the intermediate .[ch] files are erased with every build).
[B]16[/B]* binaries do not build with L1_BITS 15 (ther's a [I]TODO[/I] tag in the parts of the asm code; no wonder; I did solve it earlier for 16e, it remains to be seen if it will work for 16[B]g[/B]).
15[B]f[/B] needs additional -DVERY_LARGE_Q to build.

So, they do build; now the research question is: what do we get back from sieving the two-three different RSA-200 at different bit-levels?

A bit of humor, if you can call it that.
Here's an obfuscated hack for SCHED_TOL :devil:
[code]
was
#define SCHED_TOL 2

replace by
#define SCHED_TOL 48+1.2

<and then, it is used in expression>
allocate= rint(SCHED_TOL*n_i*j_per_strip*log(log(fbp_ub)/log(fbp_lb)));
[/code]
Don't do it at home.