World!Of Numbers | |||
Search for the first PRP megaprime of the form 10^999999 + y | |||
Output data batch 1 Doublechecking PRP candidates |
[ January 2013 ] Breaking news ! The search team made a hit !! ( Peter Kaiser, Kenneth Pedersen, Patrick De Geest ) The smallest MegaPRP has been found 10999999 + 593499
and doublechecking as well as Primebase verification and enhancement of the PRP is finished ( This pdf file is very huge [44 MB] so be patient till it's fully downloaded.) |
The Minimum MegaPRP. Projectmanager: Kenneth Egtved Pedersen Siever: Kenneth Egtved Pedersen (Sieved to p=2003542974956722) The complete dataset wich contains data for all y values, ranging from y=1 to y=593499, The PRP was found on December 24th 2012, by Peter Kaiser and was verified by On January 15th 2013 our MegaPRP was verified as Strong-Fermat, Lucas and On January 19th 2013 our MegaPRP was verified as Strong-Fermat, Lucas and And finally on January 21st 2013 our MegaPRP was verified as Strong-Fermat, This gives a total of 8 different prime-bases that each came back as PRP. improve the search and make this project succesfull, this fast. Please note that this PRP is most likely when proven, the smallest possible prime with exactly 1,000,000 digits, hence the Minimum MegaPRP search has achieved its goal of searching for and finding the smallest possible Megaprime. Go to the Minimum MegaPRP dataset.pdf webfile to get a full extraction of the dataset. The dataset is now available after the completion of the doublecheck effort. |
This is a project started by Kenneth Egtved Pedersen. To become a success many helping hands were needed.
On a Q6600 2.4 GHz it takes an 8-24 hours to do just a single test, dependant on the value of y.
Will you join in ? Patience and a stroke of luck will link your name for ever to this discovery...
However we are not going to go too far with such an effort, if other people or projects have already conducted several years of search.
So, if you are aware of any individuals or projects searching for the first PRP megaprime please let us know.
From the Mersenne Forum... a discussion dd. 2006 !
Kenneth wrote [ November 6, 2011 ] ¬
" I had 136237 candidates remaining at p=1G, and I expect to find around 21000 factors from p=1G to p=10G,
but I'll not know before next weekend for sure, how many factors were in the range. After having sieved to p=10G, I'll
hopefully be able to make a combined sievefile and sieve all remaining candidates on each core and then do 4 different
sieveranges at a time. I should even with a combined sievefile, be able to sieve ~2.1G each day."
Kenneth wrote [ December 2, 2011 ] ¬
" I noticed that you have searched 10^999999+1011, that candidate I've a factor for, so it is a verified composite.Thanks to Axn and Ken, I've now found out that using NewPGen is possible. When using the "AP: b^n+2k-1" function
Thanks for hosting the details regarding my search. With a strike of luck and with my currently planned investment
in NewPGen, it is sieving approximately 10T a day on a Q6600 2.4 GHz. This is something like 10,000 times
faster than using srsieve. Currently the minimum sievedepth of the sievefile is 106T, with 87,563 candidates remaining.
Currently no one has joined the effort and maybe it isn't nescessary after all, since things are now progressing
beyond my wildest imaginations. Optimal sievedepth is currently around 2,000T, wich will be reached nothing later
than by December 2012. I'm currently sieving from 106T-506T, and expect to get there by the end of this year.
in new CPU ressources, we may before the end of 2020 see the first possible MegaPRP. I'll give you the next update
as I get to p=1,000 T, wich will be late january or early february 2012."
Kenneth wrote [ January 2, 2012 ] ¬
" Hi Patrick
Status: 83904 candidates remaining at 436.2T "
Kenneth wrote [ January 13, 2012 ] ¬
" Status: 83745 candidates remaining at 463.5T
Ps. I'll do some testings on my Sandy bridge and see if I should stop sieving at p=1000T.
Most likely I'll reach optimal sievedepth at p=1000T, since the removal rate is getting close to 5 hours there.
So maybe before testing time gets to 5 hours we'll have a PRP for the project. "
Kenneth is nearing the end of sieving [ February 24, 2012 ] ¬
" Tuesday 28 february the sieving of the Mega prp is reaching p=1000T, after that I'll put
some of my cores on the megasearch.
and there is ~82023 y's overall remaining in the sieve file :) "
Kenneth annouces [ March 5, 2012 ] ¬
" I can inform you that p=1000T has been reached, there is ~83K untested candidates
remaining in sievefile. I'll continue sieving to p=2000T, since stopping now, is only abour 30%
of optimal sievedepth. So this means that for the next 100 days I'll only support your testing
by removing further factors from your test-ranges. I'll give you the exact number of untested
candidates remaining...
ps. New sieving range will take approximately 100 (IRL) days to complete, by then (I hope) a live
ps2. 'CRUS' is short for Conjectures 'R' US, wich is a subproject under the PrimeProjects list at
version of LLR supporting AVX will be released to the science community :) Anyways, AVX or not,
in 100 days I'll have all my current CRUS reservations completed and will be able to focus my resources 100%
on the MegaPRP search :) Hope you can manage another 100 days on your self (Maybe less if I sieve
using my Sandy Bridge, wich is possible in less than 100 days, to be able to do).
the mersenneforum, where those who support the project, tries to prove as many conjectures on the
sierpinski aswell on the Riesel side for bases ⩽1030, as possible. If you're familiar with the former
RieselSieve project, then what CRUS does is the same as what RieselSieve did for RieselBase2conjecture only,
while CRUS tries to do it for 1030 bases on both the riesel aswell the sierpinski side. So to sum up,
CRUS is about conjectures and about proving as many of them that can be proven in one lifetime,
as possible and to have all k's tested to n⩽25000 for all the conjectures that can't be proven
in a lifetime for all bases ⩽1030."
Kenneth makes progress [ March 18, 2012 ] ¬
" Hello Patrick
I have now sieved 200T more on our MegaPRP search, therby removing 325+ candidates..."
Kenneth informs [ April 29, 2012 ] ¬
" Hello Patrick
I'm currently 45 days from reaching p=2000T as sievedepth. At that level it is about 490 minutes/factor.
My sandy bridge appears, when using Prime95 to take about 5.017 hours per test. So here is my current approach:
I've loaded the candidates from y=58231 to y<1M, a total of 15,251 tests at current sievedepth,
into a worktodo.txt file and started processing it with Prime95 version 27.6! My sandybridge is able to do
about 18 tests/day. I'll most likely continue sieving on my old Q6600 because it appears that optimal
sievedepth is around p=10,000T - so there is plenty of work to do. Never the less, it always helps save off
some doublechecks as sieving progresses towards further Peta's."
Here is a discussion about older versions of Primeform and LLR and how they compare to each other.
Kenneth wrote
If you decide to do PRP testing, please upgrade to LLR 3.8.5 or the most recent version of PFGW
since they have some flaw corrections and error checking wich makes their testresults more reliable
than previous versions wich used a bug filled GWNUM FFT library :)
A slightly worried Patrick replied
In the past I did an upgrade of PFGW and found out that testing was considerably slower.
So I decided to stay with the then current version (I used the DOS running version 1.2.0 ...)
In that regard is LLR testing faster than PFGW ?
ps. the bug you mentioned in the 'GWNUM FFT library' how does it show up when using
old PFGW versions? I take it that when PFGW says a candidate is composite, it really is composite !
For many years I send PRP's to Lifchitz's TOP10000 list. Should I be worried now ?
A reassuring Kenneth answered
The bug affected PFGW versions is versions released around september 2010, all of them is between 3.3.0 and 3.3.5,
all bugs were fixed in version 3.3.6, so if you're using versions previous to the upgraded FFT library version (version 3.3.0 to 3.3.5)
then you are safe and sound. However if you want to have the same speed as LLR 3.8.5 (the most modern and bug free version of LLR)
and still want to use PFGW you should upgrade to at least pfgw 3.3.6 or newer versions .
But you shouldn't be worried about your previous PRPs since they seem to have been found with the older and dreadfully slower GWNum library,
because before the new and upgraded FFT libraries, PFGW were considerably slower than newer versions of PFGW and of preupgraded versions of LLR.
However the non-upgraded versions of LLR and PFGW were known to have been thoroughly and extensively tested for bugs and none were found.
The only time that PFGW and LLR couldn't be used to compare their residues, was if one had a faulty CPU or RAM or HDD. So the morale of the story
is that your previous results should be good and flawless, so your PRPs send to the PRP list should be in fact PRPs. However a doublecheck with
PFGW version 3.3.6 or newer, using the -a1 (wich slows things down a bit but however uses a bigger FFT length wich is less prone to error) to see
what comes back. If your PRPs come back as composites then those are composites, however if your PRPs come back as PRPs then they are most certainly PRPs.
In regards to speed, there is no difference between the most recent version of LLR and the most recent version of PFGW. The bug if there is one,
either reveals it self as missed PRPs or primes or most often it shows up as a non-matching residue, wich means that a third testing is necessary
to show wich computer is right and wich is wrong.
ps. As mentioned above the most recent version of PFGW can be found at http://sourceforge.net/projects/openpfgw/files/ and this version is 3.3.7 .
I haven't used pfgw 3.3.7 , there may be some small speed-increases compared to 3.3.6 but as far as I know, the functions should overall still be the same.
OpenPFGW and LLR formats for input files
The PFGW file has no header since each line contains the number being worked on, such as: 10^999999+y,
while the LLR input file, contains a header and for each line it contains "y 999999", wich transforms into: 10^999999+y,
as a result of the information executed by the header of the file.
Here is the list of numbers that bite the dust !
Participants :
Kenneth Pedersen Peter Kaiser (a.k.a. PuzzlePeter) Patrick De Geest ( using PFGW Version 3.5.7.64BIT.20111115.Win_Stable [GWNUM 26.6] )
[ TOP OF PAGE]