Next K

[smh]

Louie,

On http://www.prothsearch.net/sierp.html i see more and more values reserved for SoB :)

What will be the next K, and how far will you test each K before moving to the next?
Will there be multiple K's under test to move the lowest N up or will you complete each K till lets say 3M before moving on to the next one?

Do current K=27653 test have priority over K=33661? I mean, if a number for the first K expires will it be reassigned first?

Sander

[jjjjL]

probably all at once after more factoring has been done on the other k values.

also, the 27653 have higher priority and will be reassigned before 33661 blocks until they are gone.

-Louie

[Vato]

What is the highest value for n that is needed for each k ?
I suspect I could work this out if I had a working brain,
but it would be useful to list this next to the graphs anyway.

Keep up the good work...

[Mystwalker]

The highest n is the one that makes the formula prime... :p

With the approach used by SB, it is only possible to filter k's that are no sierpinski numbers. If they are, we would "never" find out, because we can't be sure there's definitely no prime with an untested n - and as the set of n's is infinite...

The sense of this project is - as far as I understand it - to sort out non-Sierpinskis, so that others (who try to prove that there are no primes for a specific k - it's possible... somehow...) have less k values to work with. If we get all 17 remaining, we would even liberate them of all work! :D

[smh]

Well, there is always the extended Sierpinski (http://www.glasgowg43.freeserve.co.uk/siersurv.htm) search. Although one could wonder how far you should extend this search. It's more a search for (medium) large primes.

And of course, there is still the Riesel problem. This problem is even harder to solve then the Sierpinski problem. But maybe by the time all 17 remaining values are eliminated there will be only 17 candidates for the Riesel problem left. :cool:

[jwolfe]

There are 115 values of k left for the Riesel problem, although they haven't been searched nearly as far as in the Sierpinski problem. All but one of the Sierpinski k's have been tested over 500,000, with six over 1M, but only about half of the Riesel k's have been tested over 500,000, with none over 1M.

I would love to see the SB search extended to include the Riesel problem as well.

- Jeff

[Vato]

I've just re-read the other stuff and realised my error.
I was confusing this with something else that I also misunderstood :rolleyes:

Regarding Riesel problem, how much effort would it be to convert the SoB client/server over to this once the current project is completed?

[smh]

I guess it's many times harder to solve the Sierpinski problem then to change the client to handle numbers -1 numbers.

BTW, i just got a K=67607 test. I guess this is bad for my cEMs rate ;) but at least the test goes fast. It's way less then one block.

[Vato]

Is K=67607 just testing, or are we about to go live with it?
When will the graph be added to the stats page please?

[smh]

I think we're live. Just got another one which is much higher (for such a short time) 444K vs 403K

[shifted]

Louie is probably just testing things again. I know the plan is to finish the lower k's first.

[jjjjL]

the new k value is live now.

i decided to add n values for all k's today. they will test in order of n values. there are very few k=67607 blocks. in terms of frequency, there are less than half as many in a given interval of values as most other k. they have no special priority but since the lower bound is lowest of any value, it is being tested first.

the k=27653 blocks still have priority so the last 300 tests left for it will be reassigned until they are gone. while they are all tied up (or they finish) the block with the lowest n value will be assigned regaurdless of k.

there are a total of 92220 tests currently in the db now between all the k values. that sounds like a lot... then again, we have completed several thousand in the last couple weeks. if this doesn't sound like a lot, i might point out that i actually haven't added any tests for k=4847, 24737, 54767, and 65567 simply because they need more sieving.

needless to say, this will make stats a mess soon. expect changes.


-Louie

[smh]

What do you mean with ALL values? I guess only 3 values for now?

Just saw the new graph for 67607, but unfortunately the big version doesn't work :(

<edit> i guess you haven't forgotten about Phil's sieving page? I know this is probably not far enough, but should be sufficient for exponents below 1M

[Mystwalker]

I guess Louie means all 5 k's assigned to SB.

btw. what does the "L" mean in front of the 67607 at the table from http://www.prothsearch.net/sierp.html ?

[nuutti]

So that has not been assigned to us in :http://www.prothsearch.net/sierp.html

but I think than it is ok if we decide that we will
do every range. Competing projects are usual in crypto
Challenges.

I Just want that more numbers are removed from the list and I don’t care who is doing the job. And I believe that this project
will do the job faster than anyone else.

If every remaing 17 number is added to server, then we will find a prime during next few weeks.

Yours,


Nuutti

[nuutti]

>btw. what does the "L" mean in front of the 67607 at the table >from http://www.prothsearch.net/sierp.html ?

I guess that it means lowest n

Yours,

Nuutti

[smh]

Then it won't be for long ;)

Louie, would you consider lowering the expiration time for the lowest N's a bit? Two weeks seems a bit long.

[smh]

Hé, just got a K=55459, didn't know we were going to do that one ;)

How far are all K's sieved currentely?

And how long do you think it will take for the new stats page is online? I's getting hard to follow current progress :rolleyes:

[Mystwalker]

Just got a 10223! :thumbs:

Is Ray Ballinger concentrating on 54767 now?

[Stricker]

my linux box has a 55459
and it is still seg faulting

[Bellbox]

Bleh, working on a k=10223 block, very large and low cEMs/s

[Mystwalker]

Just curious:
Is a larger k harder to calculate, given that the n is the same?
Or is it (mostly) independant of total value (which is of course larger when k get bigger)?

[Hawk]

The size of k is basically irrelevant when compared to the size of 2^n, so - yes the time taken is completely dependent on the total value, but this is just about independent of k.

The size of k would only become important if the size got too close to the FFT limb size, because then optimisations that allow modular reduction to be done faster for the special form k.2^n+1 would become less efficient (as k gets larger, the number becomes "less special"). This doesn't happen til at least k = 1000000 though so won't effect us at all.

[Mystwalker]

Thanks for that fast answer! :thumbs:

Right, I forgot once again that - let's say - 32768 is only 2^15, so n+15 would do the same... more or less... ;)