mersenneforum.org > Data Matching BAD LL results?
 Register FAQ Search Today's Posts Mark Forums Read

2019-05-15, 18:58   #23
Serpentine Vermin Jar

Jul 2014

62678 Posts

Quote:
 Originally Posted by Madpoo Clearly with M1586623 there's a strange bit shift happening in the middle there, so I will mark it bad like the others, but now you have an idea that I was trying to give that code very benefit of the doubt. In the end though, a bad result is a bad result even if there's some perfectly good reason for it.
Ditto with M1587121. Seems like those funny 48-bit residues he had were buggy in a different way than the others where the LSB was off by one.

It's just funny that the residues seem almost arbitrary in how many bits they would include... 9 bits, 25, 48, whatever, who cares.

2019-05-15, 19:12   #24
R. Gerbicz

"Robert Gerbicz"
Oct 2005
Hungary

24×83 Posts

Quote:
 Originally Posted by GP2 Feel free to add the 70th LL result for M1,000,003 though.
And those (altogether) with RES64 is still weaker than a single (error checked) PRP test for that exponent.

2019-05-15, 19:34   #25
GP2

Sep 2003

2·1,289 Posts

Quote:
 Originally Posted by Madpoo It's just funny that the residues seem almost arbitrary in how many bits they would include... 9 bits, 25, 48, whatever, who cares.
Some of the small old residues omit leading zeros. So an extreme case like 4-hex-digit 000C becomes just C (for M979,987). And similarly 000E becomes E (for 985,531).

2019-05-15, 19:42   #26
GP2

Sep 2003

2×1,289 Posts

Quote:
Originally Posted by R. Gerbicz
Quote:
 Originally Posted by GP2 Feel free to add the 70th LL result for M1,000,003 though.
And those (altogether) with RES64 is still weaker than a single (error checked) PRP test for that exponent.
That particular exponent has not one but three PRP tests (somebody did another one just today), and 69 LL tests (68 good, 1 bad).

More likely than not, it is, in fact, composite.

2019-05-15, 20:13   #27
Serpentine Vermin Jar

Jul 2014

325510 Posts

Quote:
 Originally Posted by GP2 Currently all new LL results for exponents under 1 million are rejected. Feel free to add the 70th LL result for M1,000,003 though.
I wonder if we should increase that 1e6 rule to something around 30e6

Anyone with an assignment below 30 million who may still be working on it and will one day turn it in, well, they'd be out of luck.

As it turns out, I didn't spot any < 30e6 assignments that have checked in since May 1, but there are some just above that threshold:
M30574289
M30574351
M30574409
M30574529
M30718351

Those poor souls (or maybe the same anonymous user...I think the first 4 are for sure). Assigned in 2012, expired in 2014, definitely no longer needed, but they still keep checking in some 6.5 years after being assigned.

These 2 were last updated in March, so not super recently but who knows, maybe they only check in once every few years:
M25413671
M25413779

Maybe after 8.5 years, they'll actually go above 0% progress sometime soon?

Anyway, point being, people can test out a small exponent to see if they match to confirm their machine is fine, but we really don't need those checked in.

If someone (like me) felt like doing triple-checks on small exponents just to confirm that the old code was just as good as the new code (or vice versa) then we can always make exceptions for a one-off project.

 2019-05-15, 20:30 #28 VBCurtis     "Curtis" Feb 2005 Riverside, CA FA116 Posts Triple checks are good for the project, and a nice way to test hardware/software/etc. I'm in favor of not recording any test beyond a quad-check, and I'm not sure recording a 4th confirming test is useful. If it's easier to set an exponent cutoff, perhaps set it to the level where triple-checks have been done for all smaller exponents?
2019-05-15, 21:22   #29
GP2

Sep 2003

1010000100102 Posts

Quote:
 Originally Posted by Madpoo I wonder if we should increase that 1e6 rule to something around 30e6
Seems like overkill for a mostly non-existent problem. Unless there's truly a problem I'd rather leave the door open for data miners to poke around for anomalies and do redundant triple-checks on already-verified exponents out of paranoia or just for the hell of it.

All of the exponents with a very large number of results (other than 1,000,003 itself) appear to be from long-extinct runaway processes involving a single user, rather than from multiple users).

The numbers below seem like a lot, but it's a drop in the bucket compared to the tens of millions of exponents tested.

The exponents with more than 10 good results are (as of May 1):
Code:
    656 21934219 (last runaway result: 2010-07-08)
306  6522911 (last runaway result: 2002-01-02)
245  8893783 (last runaway result: 2003-05-26)
79 12670673 (last runaway result: 2004-11-22)
78 18598117 (last runaway result: 2007-11-17)
73  5721461 (last runaway result: 2000-11-05)
67  1000003 (still getting 10 or fewer results per year from many different random users)
66 16213667 (last runaway result: 2006-08-14)
62 19042577 (last runaway result: 2012-02-22)
55  4983379 (last runaway result: 2001-11-24)
45  9368201 (last runaway result: 2000-08-10)
43 18491911 (last runaway result: 2004-01-27)
37 13283969 (last runaway result: 2002-07-06)
33 32629271 (last runaway result: 2007-11-17)
33 15845057 (last runaway result: 2014-07-21)
32 41224723 (last runaway result: 2008-11-16)
32 22118647 (last runaway result: 2004-07-13)
32 20234831 (last runaway result: 2005-09-22)
32 16401349 (last runaway result: 2003-10-08)
31 38973653 (last runaway result: 2008-06-14)
29  8883257 (last runaway result: 2000-02-16)
28 11425133 (last runaway result: 2006-03-01)
27 30180739 (last runaway result: 2015-01-05)
25 11636461 (last runaway result: 2001-08-04)
22 11157473 (last runaway result: 2004-03-08)
21 20494237 (last runaway result: 2003-10-08)
21 13719179 (last runaway result: 2006-08-14)
20 28232483 (last runaway result: 2011-08-06)
20 13693733 (last runaway result: 2006-02-01)
19 28488127
18 41012981
18 30078407
18 14942209
17 34835443
17 34295449
17 34242407
17  1000969 (last runaway result: 2009-05-16)
15 27531443
15 24404123
15 21525227
15 18445487
15 14417057
14   375091
14   375029
14 21507709
14 15051347
13   375103
13   375101
13 34164479
13 18732037
12  4353311
12 30563657
12 15511487
12 15388291
11  8653889
11  3365707
11 30573449
11 18530399
11 17692357
11 13788781
10 28864207
10 28488913
10 28106591
10 13191533
The counts below are from "Reports > Detailed Reports > LL Results", but most of these don't show up as multiple in the web page. I guess if there are multiple results with the same user, residue and shift count and date, then only one result shows in the web page.

The exponents with more than 10 bad results (as of May 1):
Code:
     67 13514429 (only one appears on the webpage)
67 12905257 (only one appears on the webpage)
32 10670573 (only one appears on the webpage)
31 10828327 (only one appears on the webpage)
28 10855109 (only one appears on the webpage)
26 11648237 (only one appears on the webpage)
24 13322633 (only one appears on the webpage)
23  7953793 (only three appear on the webpage, one real user)
20  7339489 (only five appear on the webpage, two real users)
19  7516657 (only four appear on the webpage, one real user)
19 12934189 (only one appears on the webpage)
14 14691829 (only one appears on the webpage)
12  2397103 (actually 12, but only one real user)

2019-05-18, 16:11   #30
Serpentine Vermin Jar

Jul 2014

62678 Posts

Quote:
 Originally Posted by GP2 ...M21934219...
Ugh... that one with all the results. Takes a VERY long time to load. I really need to fix up how that page loads results for a single exponent so it's faster.

As an example, here's the XML version of the report for that exponent and note how fast it loads:
M21934219 (XML)

 2019-05-18, 19:14 #31 PhilF     Feb 2005 Colorado 3×11×13 Posts How can a PRP test have a zero shift? https://www.mersenne.org/report_expo...4122531&full=1
2019-05-19, 13:44   #32
endless mike

Jan 2004
Milwaukee, WI

22·37 Posts

Done with GPUOwl most likely.

Quote:
 Originally Posted by PhilF How can a PRP test have a zero shift? https://www.mersenne.org/report_expo...4122531&full=1

2019-05-19, 15:34   #33
PhilF

Feb 2005

42910 Posts

Quote:
 Originally Posted by endless mike Done with GPUOwl most likely.
Interesting. I didn't know PRP tests were possible on GPUs yet.

 Similar Threads Thread Thread Starter Forum Replies Last Post sdbardwick Lounge 1 2015-02-03 15:03 miket Math 5 2014-08-12 00:41 Dubslow PrimeNet 8 2012-04-27 18:19 patrik Data 1 2011-09-24 23:44 cheesehead Data 6 2010-12-27 22:47

All times are UTC. The time now is 22:48.

Sat Apr 4 22:48:21 UTC 2020 up 10 days, 20:21, 0 users, load averages: 1.08, 1.18, 1.35