decreasing the n-range in the dat-file

Hi, I'm sieving for "Sierpinskie/Riesel base 5".
I have the following Question:

at the moment we are sieving for

Code:

---

184 <= n <= 2000000

---

According to the stats-page

the lowest n for an active test is
for riesel: 289605
and for sierpinski: 328596.
So if we start sieving in a Range

Code:

---

250000 <= n <= 2000000

---

we could save some time finding factors. Is it possible to change the range? or is this a bad idea? And how can I manage this?

I asked this question in the Project-Forum, but i didn't get a Message, so maybe someone in this Project Forum can help me.

your best option is to actually change the range from your current range to the following.

991<n<50000000

Also you should change each of the k values to those we are currently using... that would be your best option.

This can easily be done by downloading our dat and participating in our project considering this is where the support is coming from, LOL

:Pokes:

Seriously,

that range seems tiny for a project unless they don't plan on testing very deep. In order to answer that question we really need more information.

How deep will you expect to test
how many k will you eliminate before then
are you double checking and when will you start


a quick calculation for your increase in speed is something like (% decrease in range)^0.5

Quote:

---

Originally Posted by vjs

your best option is to actually change the range from your current range to the following.

991<n<50000000

---

Umm, they are doing Sierpinski base 5, so they might have other numbers as the SoB 991/50M. H.

:umm:

:gangpunch

:sofa:

Thanks for your answers.
And sorry that I didn't react, but I was on holidays *g*
I got answers in the project's forum, and they want the results for lower values too, to be sure, that they didn't miss anything in a "pre-sieve-phase" or something. So, I'll keep the range.

no problem

In most cases please stick with the project supplied dat or get everyone to switch for a good reason based on efficency. Even if the one that's currently being used is not optimal the headache from switching dats is :hair:

Shirinking the range is less of a problem but only when all tests are double checked with matching residuals and yada yada, even then the speed increase is generally not worth it.

Or the speed increase you get now is offset by the "non-optimal approach of sieve at higher n values" ( somewhat difficult to explain ) when you cut the high end.

Anyways I thought my first response was at least somewhat humorous, did anyone else get it?