[QUOTE=jasong;119942]Um, Geoff, there's more than one one sieving effort that's been going on at PrimeGrid. Actually, over it's short life, there have been three separate sieving projects for three separate objectives, (1) Cullen/Woodall sieving, which uses gcwsieve, which is the best method, at least for the lower p-values (and this is the project I'm talking about),(2) twin prime search, which involves n=333,333 at the moment, and involved n=195,000 in the past, and (3) what you're involved in, which is the Sierpinski sieve, which helps both the Prime Sierpinski project and the Seventeen or Bust project which have some overlapping and nonoverlapping k's in their initiatives.[/QUOTE]

I am not sieving for PSP on PrimeGrid. I am talking about sieving for Cullen/Woodall primes using gcwsieve. gcwsieve is running on my Celeron at 46,000 p/sec for 58,000 Cullen and Woodall numbers. Unless NewPGen has added new capabilities since I last used it, it is the wrong tool for this job.

If it does somehow work out to be worthwhile doing more trial factoring on an individual Cullen/Woodall candidate, that that will just show that sieving was stopped too soon. P-1 or ECM factoring is a different matter, it may well be worthwhile doing P-1 or ECM factoring before LLR testing.

If you want to be accurate the range in P-1 testing was done up to 2^44.7 :wink:

Also P-1 factoring is a great way to go as im currently finding a factor every 45444 seconds using Pfactor=. 2 LLR tests on my computer take approx. 86400 seconds so Im getting excellent results.

~BoB

Mea [b]maxima[/b] culpa. Pride goeth before a fall(my pride, my fall) and all that stuff.

[QUOTE=geoff;119940]
That is 90sec for one number? You are using NewPGen with a one-line input file?

My 2.88GHz Celeron is sieving about 58,000 numbers for PrimeGrid at the rate of about 46,000 p/sec. That is equivilent to 240G for one number in 90 sec. Unless your machine is 24 times slower than mine, you are wasting your time.[/QUOTE]

Just to clarify, if you are using newpgen to sieve a single number of the form k*2^n+1, then there are 2 different algorithms the program can use. The one used for fixed n is really fast, whereas the one used for fixed k will be slow. So you have to adjust the header line to make sure it is 'fixed n' not fixed k.

:smile:

If you really want to do a proper test then you would need to do the following...

1)create a text file

2)put this as the first line 0:M:0:2:1 (first zero being sieve start point and M meaning minus for woodall units... use p for cullen)

3)put all the n and k values in separated by a space

it should look something like this:

179044366:M:0:2:1
3850248 3850248
3850249 3850249
... ect

Make sure the cullen and woodall are separated though.


edit the first number on the first line to be the sieve start point then set your max P value in newpgen and run....


This would be the only proper way to compare newpgen and gcwsieve.

Also this method is a lot more work for users in the end because they need to edit the first number before every sieve!

~BoB


I personally think there will be little difference but you never know...

I have just done the conversion and I will be running some tests momentarily...

~BoB

I am having a strange problem... it is not finding the factors it should... (Im using the test available with gcwsieve's source code)

[quote=popandbob;120261]I am having a strange problem... it is not finding the factors it should... (Im using the test available with gcwsieve's source code)[/quote]


Guess I should open my eyes every once in a while... (fixed k or n only!)

Doh!:whistle::no::blahblah: