Register FAQ Search Today's Posts Mark Forums Read

2018-04-20, 01:16   #1497
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

2×17×173 Posts

Quote:
I think it is wrong to selectively have PRP tests appearing in some places and not others. If a pair of matching PRP tests can put the exponent into the LL-D column, then a single PRP should put an exponent into the LL column. A suspect LL should be moved out of that column if a good PRP is done later.

As it is now there is a lot of confusion about what happens with PRP tests and how they are counted in various places.

It is a little bit more than a "display anomaly", the fundamental handling of PRP tests still needs to be integrated more thoughtfully. Let's get it fixed. I suggest to remove the LL nomenclature and replace it with a clearer testing and/or tested, and similarly LL-D to be verifying/verified. This would better match the chosen wording on the milestones page also. We don't need to mention the implementation details of which test is done.

2018-04-25, 12:12   #1498
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5·13·73 Posts

Quote:
 Originally Posted by chalsall My interpretation is the Captain is asleep at the wheel. This always works out so very well....
More like the shipwright is busy with something new and wonderful. As it regularly happens.

 2018-04-25, 12:34 #1499 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 5×13×73 Posts P-1 marked expired when result reported manually I noticed something odd the other day, and investigated, and found an anomalous server behavior goes back to March 26. For manually assigned P-1, performed on GPUs in CUDAPm1, and manually reported results, including the proper AID in the report, the result is entered, and the assignment is also recorded as expired, apparently at the same time. I've confirmed this supposition on timing by checking an exponent's status immediately before reporting a no-factor result for it, and rechecking status afterward. See for example https://www.mersenne.org/report_expo...8000027&full=1 where it shows my P-1 result recorded, and an expiration of the P-1 assignment, occurring with the same date. Active P-1 assignments are not indicated as having _any_ expiration date when I look at my current assignments, including immediately before I report a P-1 result manually. CPU-based Prime95 P-1 results automatically reported through Primenet seem to be fine, not getting marked expired. I've no information on what occurs if a CPU-based P-1 computation is reported manually, since I haven't any instances of running that way.
 2018-04-27, 02:37 #1500 potonono     Jun 2005 USA, IL 19310 Posts On the https://www.mersenne.org/download/ page, in the "Software Source Code" section, there is an incomplete sentence that just indicates, "If you are curious anyway, you can". That sentence used to end with sentences like ",you can download all the source code (mm.mMB). This file includes all the version vv.v source code for Windows, Linux, FreeBSD, and Mac OS X. Last updated: yyyy-mm-dd." with the "download all the source code" linked to a file. Is that paragraph failing to generate correctly because of the link, or does it need to be removed all-together?
2018-04-27, 15:03   #1501
GP2

Sep 2003

2·1,291 Posts

Quote:
 Originally Posted by GP2 Similarly, the outstanding NO-LL is most likely due to a hung assignment on M77231809. The system seems to think that the first-time PRP assignment is still outstanding, despite the fact that the result was already submitted. No LL test was ever done on this exponent, nor should it be at this point. Again, doing an early PRP double-check will likely resolve the problem, by shifting it into confirmed-composite status. I am poaching this exponent to do that, it's about 25% complete.
Hmmm. The PRP double-check of M77231809 completed about four-and-a-half hours ago, but there is still a stubborn "1" in the "Status Unproven: NO-LL" column. It did clear the "1" in the "Assigned: LL" column, though.

M77732573 and M77879497 should complete in a couple of days.

2018-04-27, 15:45   #1502
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5·13·73 Posts
manual submit P-1 and PRP leaves assignment marked expired?

Quote:
 Originally Posted by GP2 Hmmm. The PRP double-check of M77231809 completed about four-and-a-half hours ago, but there is still a stubborn "1" in the "Status Unproven: NO-LL" column. It did clear the "1" in the "Assigned: LL" column, though. M77732573 and M77879497 should complete in a couple of days.
And now, my PRP assignment is marked expired on the same date as the second PRP result submission. My PRP result was submitted manually.

Perhaps not so coincidentally, all my manually submitted P-1 since March 26 have the assignment marked expired same date as each result was submitted.

2018-04-27, 16:41   #1503
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5×13×73 Posts
PRP handling etc

Quote:
 Originally Posted by retina I think it is wrong to selectively have PRP tests appearing in some places and not others. ... As it is now there is a lot of confusion about what happens with PRP tests and how they are counted in various places. ... the fundamental handling of PRP tests still needs to be integrated more thoughtfully. Let's get it fixed.
Yes to all the quoted above.

It's taking a while to get PRP integrated. More visible progress would be appreciated. Work is occurring. There are few manually submitted PRP results, and sometimes they generate issue reports, which tend to generate prompt attempts to fix the issue identified. It's slow going, since not everyone spots or reports issues, and it can be weeks between result records from someone willing to report issues with sufficient detail; resolving one issue can lead to revealing another issue the next time. Issue reports by email with screen shots and copies of the submitted result record seem to work best in my experience. (Reports on a forum thread without details seem to be at the other end of the spectrum.)

There is some utility to distinguishing between PRP and LL primality testing in the various tables. LL is only fully double checked in the sense of a matching residue confirming the calculation went correctly, by another LL check. Quality of LL check varies, because some prime95 runs will include the Jacobi check, while older executable versions will not; gpu runs made by CUDALucas or clLucas will not. A PRP run, on a recent enough version of prime95, or on gpuOwL, confirms another PRP run in the same more thorough sense if the residues match. A Gerbicz-checked PRP may confirm the composite nature of a mersenne number, but yet not confirm the LL residue or run was correct. Matching PRPs confirm each other. Matching LLs confirm each other.

I had the impression from Prime95's participation in the initial discussion of expanding GIMPS to support PRP with Gerbicz check results, that a policy of requiring primality test types to match between a first and second test to declare a mersenne number's primality settled was at least under consideration, and might have been chosen as policy, as a means of promoting the quality of the data in the GIMPS databasae.

There may not be a rule in place, that once one primality test assignment is issued for a given exponent, that others must be of the same type, either by Primenet or manual checkout. Some small subset of exponents having matching PRPs or LLs plus one or two of the other type is ok. This may occur from QA or brute-force benchmarking on software running against known-composite exponents. It's likely to occur with new primes. To frequently have primality type not match between first and second test does not seem efficient. But the resulting residues may have future utility.

Some form of representing PRP in the work distribution map table would be welcome.
Clarity, compactness, and completeness conflict.
I'd like to see twice the frequency of the header lines
Code:
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
Exponent Range    | Composite  | Status Unproven  |        Assigned         |        Available        |
Start   Count  P |   F   LL-D | LL   LLERR NO-LL |  TF    P-1   LL   LL-D  |  TF    P-1   LL   LL-D  |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- 
so that one header was always on screen no matter which portion was scrolled to. Shrinking font size in the browser to get that to be the case with over 110 lines vertically, makes the characters so small they're very difficult to read.

Also, there are no columns for PRP performed or PRP DC or P-1 performed counts or TF performed counts. It's hard to tell in what ranges the various algorithms haven't even been tried yet. The table is wide now, but there's room on my screen and probably many others to widen it further.

2018-04-28, 17:04   #1504
Serpentine Vermin Jar

Jul 2014

29×113 Posts

Quote:
 Originally Posted by potonono On the https://www.mersenne.org/download/ page, in the "Software Source Code" section, there is an incomplete sentence that just indicates, "If you are curious anyway, you can". That sentence used to end with sentences like ",you can download all the source code (mm.mMB). This file includes all the version vv.v source code for Windows, Linux, FreeBSD, and Mac OS X. Last updated: yyyy-mm-dd." with the "download all the source code" linked to a file. Is that paragraph failing to generate correctly because of the link, or does it need to be removed all-together?
Weird. The text that comes next is dynamically generated by some code... I'll take a look. Thanks for spotting it.

2018-04-28, 17:13   #1505
Serpentine Vermin Jar

Jul 2014

29×113 Posts

Quote:
 Originally Posted by kriesel Also, there are no columns for PRP performed or PRP DC or P-1 performed counts or TF performed counts. It's hard to tell in what ranges the various algorithms haven't even been tried yet. The table is wide now, but there's room on my screen and probably many others to widen it further.
As noted, PRP still needs work to be integrated into reporting. The most important part that had to be done server side was simply to set it up to assign and accept PRP work because that sort of work was already happening before the server was really ready to do anything with it.

Unfortunately that also means a lot of the reporting needs to be modified and speaking for myself, schedule-wise this has been a pretty packed time which means I haven't has much time to work on the site beyond the basic maintenance. I've gone as far as creating PRP specific report pages just like LL, but when it comes to the aggregate reports that display summary progress of ranges, yeah, that all needs to be spiffed up.

I've had a task to convert that range stats to an actual HTML table anyway, but right now it's generated in a somewhat unconventional way which makes changing it more complicated. You'll all have to bear with it for now and be patient. I think the 77M-78M range is the first one to have a mix of LL and PRP first time tests in there which make it complete, but the range report isn't properly reflecting that...

Anyway, to summarize, be patient and it will be worked on as time allows.

2018-04-29, 01:35   #1506
Serpentine Vermin Jar

Jul 2014

1100110011012 Posts

Quote:
 Originally Posted by Madpoo Weird. The text that comes next is dynamically generated by some code... I'll take a look. Thanks for spotting it.
Fixed. There was some regex to get details on the source specific ZIP file and apparently it's been broken ever since those filenames had the "b" in there for the build revisions (e.g. p95v294b7.source.zip). That "b" was throwing it off.

Good catch. It would have been broken since 29.4 build 2 I guess.

Personally I prefer version #'s like 29.4.2 or 29.4.8 if we were including sub-revisions (or just make it 29.4, 29.5, etc) Oh well. We'll manage either way.

2018-04-29, 15:18   #1507
GP2

Sep 2003

2·1,291 Posts

Quote:
 Originally Posted by GP2 M77732573 and M77879497 should complete in a couple of days.
These exponents have completed and now the Work Distribution Map shows no exponents anymore under "Status Unproven: LL ERR" for the 77M line.

This was to be expected, since the previous 76M range already had a similar situation for some time. There are two exponents (76347737 and 76564567) which have a single LL test which is Suspect, but each of these also has two matching PRP tests (since February), and there are no "LL ERR" entries there either.

So now the remaining anomaly for the 77M line is: 1 exponent under "Status Unproven: NO-LL" and 35812 under "Composite: F", when it really should be none and 35813, respectively.

Maybe it's not even a PRP issue. There are no PRP assignments currently in the 77M range.

Madpoo, can you look at the SQL to see which exponent is causing the NO-LL?

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Lounge 39 2015-05-19 01:08 ewmayer Science & Technology 41 2014-04-16 11:54 cheesehead Soap Box 56 2013-06-29 01:42 cheesehead Soap Box 61 2013-06-11 04:30 Dubslow Programming 19 2012-05-31 17:49

All times are UTC. The time now is 21:53.

Tue Dec 1 21:53:05 UTC 2020 up 82 days, 19:04, 1 user, load averages: 2.46, 2.21, 2.16

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.