Results 1 to 6 of 6

Thread: decreasing the n-range in the dat-file

  1. #1

    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.

  2. #2
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331
    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



    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

  3. #3
    Quote Originally Posted by vjs View Post
    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.
    ___________________________________________________________________
    Sievers of all projects unite! You have nothing to lose but some PRP-residues.

  4. #4
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331





  5. #5
    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.

  6. #6
    Moderator vjs's Avatar
    Join Date
    Apr 2004
    Location
    ARS DC forum
    Posts
    1,331
    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

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •