Possible JJsieve bug?

[Citrix]

Please keep track, if you used proth_sieve or JJsieve. I had some bad experience with JJsieve. It missed about 3000 factors (for p around 1-3 billion) for a k I was working on. I used Geoff's srsieve to find them.
Just in case, this is a bug or something, it is better to know, which ranges to resieve.

Thanks

[grobie]

Wow, I have been using jjsieve for my range should I stop it now?

[grobie]

Well if you are going to have to resieve my range no use of going on!!

Unreserving range 168600-168700 41.7% complete with 22 factors

Should I e-mail the fact.txt & factrange.txt?

[ltd]

Originally Posted by Citrix

Please keep track, if you used proth_sieve or JJsieve. I had some bad experience with JJsieve. It missed about 3000 factors (for p around 1-3 billion) for a k I was working on. I used Geoff's srsieve to find them.
Just in case, this is a bug or something, it is better to know, which ranges to resieve.

Thanks

Strange.

I made several tests with Proth_sieve and jjsieve and never had a difference in found factors.

Lars

[VJS]

not sure what the problem is or was, the client was tested quite extensively without error?

Can you give the exact p you were using.

[Citrix]

I started uisng srsieve from 3.7 G to 52 G. Before that I used JJsieve, from 50,000 to 3.7 G. Below 50,000 was newpgen.

Once I reached 52G, I thought to double check my work since srsieve is new and not reliable for base 2.

so I retested from 0-5G range ~3000 factors were found between 50,000 and 3.7G and 1 factor between 3.7 G and 5G.

I have tested all the factors, so I think jjsieve missed ~3000 factors.

The k=3^16

Lars, Is it possible for you to double check the entire range 0-10G for PSP k's with Srsieve in case we missed alot of factors and a range tested with jjsieve only, not with proth_sieve. If we do not find alot of missing factors then we can think, this was an isolated incidence and jjsieve is safe to use.

edit: I made some tests of my own, jjsieve seemed fine with the PSP's k's. May be it is just that one k that causes problems with jjsieve.

[Citrix]

Originally Posted by grobie

Well if you are going to have to resieve my range no use of going on!!

Unreserving range 168600-168700 41.7% complete with 22 factors

Should I e-mail the fact.txt & factrange.txt?

Just hold on with your range till we sort this out. We may not have to redo your range.

[Joe O]

Originally Posted by Citrix

I started uisng srsieve from 3.7 G to 52 G. Before that I used JJsieve, from 50,000 to 3.7 G. Below 50,000 was newpgen.

Once I reached 52G, I thought to double check my work since srsieve is new and not reliable for base 2.

so I retested from 0-5G range ~3000 factors were found between 50,000 and 3.7G and 1 factor between 3.7 G and 5G.

I have tested all the factors, so I think jjsieve missed ~3000 factors.

The k=3^16

Lars, Is it possible for you to double check the entire range 0-10G for PSP k's with Srsieve in case we missed alot of factors and a range tested with jjsieve only, not with proth_sieve. If we do not find alot of missing factors then we can think, this was an isolated incidence and jjsieve is safe to use.

edit: I made some tests of my own, jjsieve seemed fine with the PSP's k's. May be it is just that one k that causes problems with jjsieve.

I'm not where I have access to the source, and/or a calculator, but I think that your k is out of range. The tested k are, Riesel, PSP and SB plus one or two others. Please compute your k and tell me how many bits there are. The limit is 2^15 or 2^17 or somewhere around there.
There is another possible low limit on p. Though I have tested it for very small p, the extensive testing started at 1G. That was the lower limit of MKlasson's program that we used to verify JJsieve. The next version, already under test, will have a lower limit of 2. That is correct, it will allow p to be as low as 2 and proceed on up from there. This is in response to requests for people who want to start from scratch.


Please send me your dat file for this k, so that I can easily test. Send it even if it is larger than 2^15 since I am considering expanding the limit on k.

[Joe O]

Originally Posted by grobie

Well if you are going to have to resieve my range no use of going on!!

Unreserving range 168600-168700 41.7% complete with 22 factors

Should I e-mail the fact.txt & factrange.txt?

Please email them to factrange at yahoo dot com as well. For the p range you are using and for the PSP and combined dat, we have yet to find a case that jjsieve missed a factor. The one time that someone thought it did, it had found the factors but put them in factexcl.txt because of a faulty dat file that the person had constructed on their own.

[Citrix]

The k has 26 bits. The large k and the small p must have been the reason. I am glad that PSP is safe, and we do not need any retesting.

Could you create a readme file for JJSieve, with all the limitations of the program, so in future people do not make similar mistakes.

edit:-

See attached file for the dat and the factors found using srsieve, some of which were missed by jjsieve. The dat has been tested to 76G. If you test it further please PM me the factors, so I can update the dat.

For this dat, your program can be made 16 times faster. since all factors must be p=1 (mod 32). Currently with srsieve I get 10,500kp/s and with your program 2,000 kp/s.

If you could make your program faster for this k, I would really appreciate it.

Thank you.

[grobie]

Ok, will resume testing with JJsieve.