mersenneforum.org > News Holy new Mersenne prime, Batman!
 Register FAQ Search Today's Posts Mark Forums Read

 2008-08-24, 00:20 #12 Minty     Sep 2004 248 Posts OMG! I personally didn't expect this for several years - it's bound to be the first 10 million digit prime. Oh well, the hunt is over - but which project to move to? (Still, I do hope it's a false positive / sub-10 million, although the chances of this are really low)
 2008-08-24, 00:28 #13 biwema     Mar 2004 3·127 Posts Factored to 75 bits??? (41125727 75) How did that work? Different encoding of p-1? I know it is a bit off-topic...
2008-08-24, 00:36   #14
Mini-Geek
Account Deleted

"Tim Sorbera"
Aug 2006
San Antonio, TX USA

17×251 Posts

Quote:
 Originally Posted by Minty OMG! I personally didn't expect this for several years - it's bound to be the first 10 million digit prime. Oh well, the hunt is over - but which project to move to? (Still, I do hope it's a false positive / sub-10 million, although the chances of this are really low)
Well, you don't have to stop GIMPS just because the prize is found, unless your sole reason for searching for primes was the possibility of the prize (in which case you should probably stop searching until GIMPS is close to the 100M digit range, or do early testing in that area). But, hey, as long as you're looking for suggestions, check out NPLB or CRUS (I've found 12 primes so far in NPLB, and CRUS is its sister project...NPLB searches k*2^n-1 with odd 300<k<1002 for top-5000 primes, while CRUS searches many bases and riesel/sierp stuff trying to find riesel/sierp numbers by finding primes to eliminate numbers).
Quote:
 Originally Posted by retina Is it really the stuff of legends? And since 4/7 of the numbers given by Graff are less than 10M I would think it would be better to use the word "possibly" rather than "probably". A minor detail of course, but pedantry is one of my hobbies.
If his time period is correct, then yes, I agree that'd have to be "possibly". The probability is also higher than 4/7 (assuming all those are indeed first-times and not DCs) that it's <10M digits, since smaller numbers have a higher probability of being prime (for obvious reasons ).
Quote:
 Originally Posted by ixfd64 The archives are supposed to be at http://www.mersenneforum.org/primenet and http://tuatara.sdsu.edu/primenet, but they both seem to be down at the moment.
Gah......what terrible timing!

2008-08-24, 01:34   #15
jrk

May 2008

3×5×73 Posts

Quote:
 Originally Posted by biwema Factored to 75 bits??? (41125727 75) How did that work? Different encoding of p-1? I know it is a bit off-topic...
No, it is only factored to 68 bits. See here for v5 server status.

There is a bug in the version 25 client when it sends P-1 results to the v4 server, it reports that the exponent was factored to 75 bits.

Last fiddled with by jrk on 2008-08-24 at 02:02

2008-08-24, 01:45   #16
Graff

Jul 2006
USA (UT-5) via UK (UT)

22·59 Posts

Quote:
 Originally Posted by davieddy That is 1900 UTC. Is this the first time the prime is mentioned?
That would appear to be the biggest unknown ATM (other than the
value of the new Mersenne prime, obviously). I personally
think it unlikely that the notice of the unverified prime appeared
much before 19:00, simply because of the number of people
who check those pages.

If someone can show that the notice was there in the 18:00 UTC status
report, then the result was probably received between 17:00 and
18:00 UTC, meaning that the following are candidates:

Code:
42027443  69     0x8EFFA1B8935893__                23-Aug-08 17:56  oxcoda         None
33194627  69     0xDB4A0BAD6B161F__                23-Aug-08 17:47  sPat           hardwood
41129141  69     0xD1663E7FC97098__                23-Aug-08 17:46  S692347        Lab
39427627  69     0x51557590030585__                23-Aug-08 17:46  brandonlarson  calculus
41539793  75     0x391960A6533F73__                23-Aug-08 17:45  RichJacot      freex4600-1
38527129  69     0xEF582D2757B573__                23-Aug-08 17:41  mbdil          homedell
43690483  69     0x386F6A9B1612FE__                23-Aug-08 17:39  KUNCEVO6       P4-2400-GR
42908623  69     0x024114B12D6C14__                23-Aug-08 17:38  curtisc        grn307c-08l
42259759  69     0x840BDEC2C1B905__                23-Aug-08 17:08  belynam        awesome2
41122339  69     0x6B544F1F930395__                23-Aug-08 17:06  curtisc        wd-004--06l
Notice a familiar team appears twice in the above list...

Finding someone with a copy of the 18:00 UTC report that doesn't
show the possible prime would be helpful in confirming that the
candidate is in the first list I posted.

Presumably, the candidate is already being verified. It is also probable
that the verification is being done outside the normal GIMPS procedure.
I did check the assigned exponents for double checks being run on
the candidate exponents given in the first list. I didn't see any
matches. I wasn't expecting any, but I had to check :-)

The previous disclaimer regarding "codswollop" applies here.

Graff

Last fiddled with by Graff on 2008-08-24 at 02:01 Reason: Various edits to clean up poorly written text...

2008-08-24, 07:52   #17
S485122

Sep 2006
Brussels, Belgium

157610 Posts

Quote:
 Originally Posted by jrk No, it is only factored to 68 bits. See here for v5 server status. There is a bug in the version 25 client when it sends P-1 results to the v4 server, it reports that the exponent was factored to 75 bits.
Not completely correct : George attributed this to the way the results from the old server are synchronised with the new server :
Quote:
 Originally Posted by Prime95 This is a harmless side effect of v25.6. The code that translates v5 messages to send to the v4 server doesn't have enough info to send an accurate bit level (all it knows is that trial factoring is complete). So, it tells the v4 server that the exponent is factored to 74 bits knowing this will prevent the v4 server from handing the exponent out for further trial factoring. The master database is updated by a different means. It uses the text messages sent to the v4 server. So, if you look up the exponent on the v5 server you'll see the true bit level.
Jacob

2008-08-24, 09:00   #18
davieddy

"Lucan"
Dec 2006
England

2·3·13·83 Posts

Quote:
 Originally Posted by retina And since 4/7 of the numbers given by Graff are less than 10M I would think it would be better to use the word "possibly" rather than "probably". A minor detail of course, but pedantry is one of my hobbies.
An untypically high proportion. And the 17M exponent is especially
surprising since all exponents below 20M have been tested once.

The fake residue has in the past enabled the prime to be sleuthed
because it was poorly encrypted from the exponent.

 2008-08-24, 10:36 #19 davieddy     "Lucan" Dec 2006 England 647410 Posts
2008-08-24, 11:28   #20
ATH
Einyen

Dec 2003
Denmark

27·23 Posts

Quote:
 Originally Posted by davieddy The fake residue has in the past enabled the prime to be sleuthed because it was poorly encrypted from the exponent.
No exponent coming in after 10am UTC has that old fake residue. Last time George put the fake on another exponent and used some other kind of fake residue on M44:

32582657 68 L 0x663C8660956654__ 04-Sep-06 17:33 curtisc wd-102--04l

Not sure it follows a pattern, might be just a random 64bit number.

Last fiddled with by ATH on 2008-08-24 at 11:35

2008-08-24, 11:31   #21

"Richard B. Woods"
Aug 2002
Wisconsin USA

22·3·641 Posts

Quote:
 Originally Posted by ATH No exponent coming in after 10am UTC has that old fake residue, but that wasn't used last time in M44 either.
It's not that the same residue itself was used; it's that the same fake encoding algorithm was used to create the fake residue AFAIK.

Last fiddled with by cheesehead on 2008-08-24 at 11:32

2008-08-24, 11:45   #22
ATH
Einyen

Dec 2003
Denmark

1011100000002 Posts

Quote:
 Originally Posted by cheesehead It's not that the same residue itself was used; it's that the same fake encoding algorithm was used to create the fake residue AFAIK.
Yeah I know, I mean no exponent yesterday has that fake algorithm from 10am to 7pm UTC.

This is the exponent he used the algorithm on to confuse us last time: :)
29225803 69 L 0xB6C80136DB7FED__ 04-Sep-06 17:40 mcobb a2-170.0

 Similar Threads Thread Thread Starter Forum Replies Last Post dabaichi News 561 2013-03-29 16:55 R.D. Silverman NFSNET Discussion 4 2008-10-02 01:28 ewmayer Science & Technology 4 2008-03-14 19:19 ixfd64 News 265 2006-01-04 09:47 R.D. Silverman Factoring 11 2005-04-07 17:00

All times are UTC. The time now is 02:30.

Thu Oct 1 02:30:26 UTC 2020 up 20 days, 23:41, 1 user, load averages: 1.13, 1.46, 1.47