Algebraic factors in sieve files

[pepi37]

Originally Posted by MisterBitcoin

Is someone able to post the script in this thread. I searched in the forums for it, but I didn´t found it. :/
I´ve some spare time atm.


EDIT:
Lucky me. http://www.mersenneforum.org/showpos...&postcount=105

EDIT2:
Not so lucky me, seems to be somethink different...

This is link ( on my Dropbox)
https://www.dropbox.com/s/750j4s4aphyj475/d.pl?dl=0

[MisterBitcoin]

Thx Pepi.

I tested 3 Bases (R738, R396 and R1023) from Riesel, and the same there.

I´ll now test any sieve file (only .zip and suitable .txt-files with k´s like 8) from the Riesel side.

[MisterBitcoin]

And it´s done.
Attached are factors for 57 bases, only on Riesel side.

[gd_barnes]

If sr(x)sieve is modified to remove additional algebraic factors I expect that extensive beta and parallel testing be done before it is released to the public as an official version. It should be tested behind-the-scenes by multiple users without any increments done to official alpha version of the program(s). I would like to see detailed testing and test plans to see that no current processes have been affected. In other words I want to see it tested in a manner like a company would test a major program change as though it had major financial incentives to get it correct the first time. We had very serious issues previously when the first version of srsieve came out with algebraic factors being removed and I believe it caused a number of problems on several of our bases on this project.

Personally I would prefer that srsieve is not modified to remove any more algebraic factors than it already does. The simple ones for squares and cubes are enough. When the program was designed in the first place it was never intended to remove algebraic factors; only fixed numeric factors. Since Batalov has a script that removes more complex algebraic factors that is great and should be used. Sr(x)sieve should be left alone. The fact that it does not remove more complex algebraic factors is not a bug.

[pepi37]

Well it is Ok to think about it, but then we must ask one question: will we prefer time ( for solving bases) over security ( to dont remove something that should not be removed).
I am pretty new here, so my voice is maybe irrelevant,but I am sure that many of us has very limited resources. That is not problem when N is small and LLR is done in short amount of time. But I will never forget when I take S155 and Batalov script "saves me" from 4 month of 24/7 LLR in second , because factors was not removed from sieve file.
So real question is : how to "force" people who sieving and people who take sieve to process to check before start. Peoples are lazy, they take sieve file, and split it , then start to LLR. They expect everything is made on sieve file. But it is not.
And many months can be saved using script.
So what I suggest is to modify Batalov script in small exe for Windows, so user have to input file name of sieve, press "Remove" and program write new output file(with removed factors), and file with factors ( if any) and that program to be uploaded to Boinc Confederation page.
Nobody will search for small script on this forum, but if you put it there, and write what program do.. that will be different story.

[masser]

Please just leave sr(x)sieve alone. Reasons:

1. Since you need to sieve further for large exponents, the likelihood that you won't find a factor for one of the terms in the algebraic factorization goes down significantly.

2. Very light P-1 factoring would further significantly reduce the likelihood of an unfactored, large exponent term with algebraic factors.

3. We have a program that will identify the algebraic factors; just use it.

4. The best software does one well-defined thing well. We have a sieve program; we have a program that identifies algebraic factors. Let's not kluge them together.

[pepi37]

Originally Posted by masser

2. Very light P-1 factoring would further significantly reduce the likelihood of an unfactored, large exponent term with algebraic factors.

Is anywhere program like that ( p-1 factoring) can be used on npg or abcd files?

[masser]

Originally Posted by pepi37

Is anywhere program like that ( p-1 factoring) can be used on npg or abcd files?

On linux, I just use awk to create input to mprime/prime95.

If you are a Windows exclusive person and a masochist, you could probably create prime95 input with Excel.

Edit: I think srsieve comes with srfile; that will do it too.

[Batalov]

Originally Posted by gd_barnes

Personally I would prefer that srsieve is not modified to remove any more algebraic factors than it already does. The simple ones for squares and cubes are enough. When the program was designed in the first place it was never intended to remove algebraic factors; only fixed numeric factors. The fact that it does not remove more complex algebraic factors is not a bug.

I am confused here. (and this was already discussed 4 years ago and perhaps 2 years ago again.)

So, "The simple ones for squares and cubes are enough." I could agree with that, it would be a good start.
"The fact that it does not remove more complex algebraic factors cubes is not a bug." Or is it? It doesn't remove cubes!

P.S. If one removes cubes with P-1, perhaps one is a masochist. You said it, not me.

[gd_barnes]

OK, I likely misstated. I was not aware of which specific algebraic factors that it removes. If it only removes simple sqaures then I stand corrected.

Thanks for chiming in Masser. Clearly you think exactly as I do. The best programs do one thing extremely well.

[Batalov]

Originally Posted by rogue

Serge, I'm sure there are algebraic factors the srsieve is not finding. They come in many forms and the program is only searching for one form. If you have some code idea to implement into srsieve, please share with me.

One could think that you are referring to some obscure forms here, like an Aurifeillian factorization of a sum of 12-th or 17th powers. No, I am talking about sums of cubes.
And yes, I have a code idea that implements that. After the initialization block where a bitmask for the n's is prepared, the code should check:
- is k a cube? is c a cube (attention! - both negative and positive cube) ?
- if yes, drop the bitmask bits for all n that are divisible by 3.

Originally Posted by rogue

I have made some enhancements to srsieve and sr2sieve that some of you would be interested in. I've forwarded these to Geoff, but haven't received a response yet.

I modified srsieve to remove numbers that have algebraic factorizations. Not only does it find those that hiddenpowers.pl (used primarily by CRUS) can find, but it can also find others. An example of that is when k = m^x*b^y and x > 1.

"Not only does it find those that hiddenpowers.pl (used primarily by CRUS) can find", but it also doesn't. That is what I have a problem with. Then a typical user takes the sieve file from CRUS' website and runs the job up to 25% slower than they could. And these are frequently the same people that are very proud that they were able to OC their comp by another 5%. I think the fact that they just saved 5% of their runtime only to throw away 25% of the runtime would make them somewhat upset, too. But quoting D.Miller, that's just my opinion, I might as well be wrong.