Anyone factoring <5M?

[cheesehead]

Originally Posted by garo

How do you square that with your argument that poaching is inefficient?

I don't work on someone else's assigned exponent. Tell me who I'm hurting. Show me where I'm taking away someone else's hope or credit, or otherwise discouraging them.

I hope there's a way to register TF assignments below 20000 with v24 prime95 communicating to v5 PrimeNet. I haven't tested that yet.

Other people might have obsessive compulsive desires to clean up the trailing exponents.

... and they can learn to channel that into less-interfering non-duplicative efforts.

[garo]

To-MAH-to To-MAY-to

BTW a fair proportion of poached exponents are never completed by their original assignee.

[Joe O]

Originally Posted by garo

To-MAH-to To-MAY-to

BTW a fair proportion of poached exponents are never completed by their original assignee.

Yes, but two out of my first three exponents were poached. And no, they were not on slow machines, but on fast (for the time) dedicated machines.

[garo]

Look I am not defending poaching. Anyone who cares to search through the forum archives will note that I am strongly against it. Or rather I laid out three different forms of poaching and came out against two of those when the old server was running. I have been a victim of poaching too. But I do find cheesehead's moralizing a bit tedious at times.

[cheesehead]

Originally Posted by garo

But I do find cheesehead's moralizing a bit tedious at times.

Understandable. It's a hot-button issue with me, and I go too far sometimes. I'm trying to develop a way of thinking about this that will enable me to stay calmer.

[NBtarheel_33]

How about adopting the following new rules, perhaps with the eventual introduction of PrimeNet v6 (or immediately with regard to the EFF prize, not that that will realistically be an issue for 5+ years, most likely).

The overarching rule shall be that all exponents must report "reasonable" progress no less than every 73 days (1/5 year). Now what is "reasonable"? Well, a typical 3-GHz PIV system (conservatively) puts out at least 1% of an LL per day on a 50M exponent, and (I'd guess) at least 2% per day of an LL-D on a 30M exponent. Of course, there are folks for whatever reason who like to hoard larger-than-normally-assigned quantities of work and distribute and maintain it over multiple systems. I believe Cheesehead has mentioned doing this in the past, and I myself have done it (and actually am doing it as we speak - take a look at my early thread about taking out 24 exponents on my birthday last year, and LL'ing them between then and my upcoming birthday - I'm 70% of the way between birthdays, with roughly 68% of the LLs completed). I believe that this is OK...to a certain extent. I would hope that most folks would agree with me that it is unreasonable for a user with one CPU to have a worktodo containing 50 LL exponents. Yes, I took out 24 birthday exponents, but I also have as many as 33 cores to run them on.

Let us then consider adopting the following rules on exponent reporting, progress, and completion:

1. All exponents assigned via PrimeNet or PrimeNet Manual Assignment (in the current "classical" range of interest - note that I'm not really concerned with the 332M tests (right now)) must (1) check in with PrimeNet no less than once every 73 days, and (2) show progress in completion of no less than (a) 10% for an LL test or (b) 20% for an LL-D test. Note that this ideally places an upper bound on LL testing time at 2 years, and an upper bound on LL-D testing time at 1 year. (Are there many systems left out there that would need a year to run a 30M double-check? If so, maybe make the percentages in (a) and (b) both 10%, yielding a 2-year upper bound for everything.) COROLLARY: PrimeNet assignments no longer need to have an ultimate, one-year expiration date. Either you check all of your assignments in, with appropriate progress, every 73 days (and keep them), or you don't (and lose them).

2. (This is the part that would possibly require some work on the PrimeNet infrastructure.) In the case that either or both of (1) and (2) above are not satisfied, on day 74 from assignment or last progress report, two things happen. First, an e-mail to the user owning the exponent(s) in question is dispatched, warning them that if their exponent(s) do not make a satisfactory progress report within 15 days, these exponents will be lost to be reassigned. At the end of day 89 from assignment or last satisfactory report, if the user stays mum, the AIDs of the exponents should immediately be invalidated, and the exponents should be reassigned as regular 1st LLs or LL-Ds, as appropriate.

Secondly, the exponents without proper reports should be displayed in red on the user's PrimeNet assignments report, and the user's PrimeNet summary should display an appropriate message (e.g. "WARNING! Check in exponents now to avoid losing assignments!").

3. (Regarding poaching.) Any and all poaching of PrimeNet LL or LL-D assignments is permitted...








(gotcha Cheesehead)


...subject to the following caveats. (1) No progress report on any exponent, other than such from the exponent's registered owner, shall be acknowledged by PrimeNet. (I believe this is pretty much what happens now, right?) (2) In the event of a completion report from a user other than the registered owner, PrimeNet should handle the result in the following manner: (a) If the result is a first LL result and no other LL result yet exists, PrimeNet should treat the result as a DC-in-waiting. The residue should be posted to the exponent's record, however, as a potential DC, and credit for a DC should be given to the submitter. If the registered user never finishes the LL assignment (due to failure to update in 73 days or due to seeing the poacher's residue), promote the DC-in-waiting to a first LL result. ***If the result is a zero residue (and thus the exponent in question likely yields a Mersenne prime), the submitter should receive DC credit, and the registered owner should be contacted at once to arrange for sending save files, etc. The registered owner is to be credited for the prime discovery, or in the case of the EFF Prize, awarded the prize. The poacher gets a "gee, thanks for helping User X by finding her prime for her!" (and what a lesson that would be). (b) If the result is a first DC result and no other DC result yet exists, PrimeNet should treat the result as a Triple-Check-in-Waiting. No credit is immediately assigned to the poacher, but if the registered user doesn't submit their result, or if their result differs from the LL result (hence requiring a triple check), the poacher should later be credited with DC credit for their early triple check.

Note that this should discourage poaching for the sake of milestones. Say, for instance, that M43xxxxxx (assigned to Alice) is holding up a first-LL milestone. Bob comes along and poaches it. When Bob reports completion to PrimeNet, the result will be held and treated as a DC-in-waiting. This is not going to immediately help the first-LL milestone count, and in fact, won't ever, unless Alice lets 73+15 days lapse, or drops the assignment. In other words, Alice GETS TO KEEP the benefit of being the "Milestone Queen" until SHE finishes the exponent, or lets it drop by not checking in with PrimeNet. In other words, Bob may be able to poach, but he is not able to hurt Alice's enjoyment of GIMPS. She is in sole control of whether or not she is credited for completing the LL on M43xxxxxx, and by extension, whether or not she is credited for being the one to hit the milestone. Last but certainly not least, if M43xxxxxx should happen to be a prime, Alice is credited as the discoverer, once she can provide her save files, and it can be verified that Bob's zero residue is correct.

The above scenario goes ditto for a DC milestone. In fact, we could make all of this a little more punitive on the poacher by resetting Alice's 73-day reporting window as soon as Bob reports his result to PrimeNet. This would mean that a poacher trying to rush a milestone would only delay it by as long as another 89 days!

How 'bout it guys (especially Cheesehead)? What do you think? What else might we add to put the hammer on poaching? How hard are these extra mechanisms for George/Scott to add into PrimeNet?

[cheesehead]

Originally Posted by NBtarheel_33

How about adopting the following new rules, perhaps with the eventual introduction of PrimeNet v6

I applaud your having come up with a comprehensive proposal, not just here-and-there tweaks!

The overarching rule shall be that all exponents must report "reasonable" progress no less than every 73 days (1/5 year).

Fine. Numeric details are minor.

Of course, there are folks for whatever reason who like to hoard larger-than-normally-assigned quantities of work and distribute and maintain it over multiple systems. I believe Cheesehead has mentioned doing this in the past,

Clarification: For a couple of years, sometime before 2002, I did "hoard" a somewhat-larger-than-normally-assigned quantity (that is, larger than would normally have been assigned to a system with my system's CPU speed) of L-L work, for the specific purpose of glomming on to certain particular exponents. However, I never allowed any of my assignments to even come close to holding up any milestone.

There were times when someone who was casually monitoring my reported progress could have extrapolated from a subset of the figures that I would be holding up a milestone at some time in the future. What the figures could not show was that my active monitoring would never allow that to happen.

Let me note that at that time, the user-settable parameter for number of days of work to accumulate was not available (or else had a lower limit than now). If the current parameter and its limits had been available then, none of the amounts I ever had assigned at any one time would have been greater than the upper limit currently allowed for that parameter. That is, my queued amount of work would have been no greater than what anyone else could have requested under the current limits.

Recently, what I have done is to process a normally-assigned-amount (indeed, considerably less than the normally-available upper limit on requests) of work at the same time as I ran other projects, so that:

(A) the average progress of my GIMPS assignments was slower than it would have been if I'd devoted all my system's spare processing power to the GIMPS assignments alone.

(B) the reported progress of my GIMPS assignments reflected (A) -- that is, someone following them over time would have noticed a regular slippage of expected completion dates, but also noticed that I did actually complete assignments steadily even if each took longer than the first-reported estimated time.

C) I've always kept an eye on milestones and made sure that none of my assignments was even close to holding up any milestone.

and I myself have done it (and actually am doing it as we speak - take a look at my early thread about taking out 24 exponents on my birthday last year, and LL'ing them between then and my upcoming birthday - I'm 70% of the way between birthdays, with roughly 68% of the LLs completed). I believe that this is OK...to a certain extent.

I agree.

I would hope that most folks would agree with me that it is unreasonable for a user with one CPU to have a worktodo containing 50 LL exponents.

That would depend on the exponents' sizes and the user's system speed. Also, a user might request exponents by communication from only one CPU, but be actually processing them on multiple CPUs (which, as you reveal a few sentences later, is identical, or at least analogous, to your situation).

I recommend not drawing conclusions from the number of LL exponents assigned to one CPU, especially not judging them unreasonable.

Drawing conclusions from actual reported completions by a user over an extended period of time is, I think, the only reliable basis on which to judge whether that user's progress is satisfactory.

Let us then consider adopting the following rules on exponent reporting, progress, and completion:

I'll post comments on these separately.

[petrw1]

Originally Posted by markr

I'm doing TF from 61 to 62, currently in the 48xxxxx range.

Still???

[markr]

Originally Posted by petrw1

Still???

Still going! Down to somewhere in the 4.6M range now. There are some left above that that are assigned to others for ECM, but eventually they'll become available.

[cheesehead]

Whoops. I forgot to come back two months ago to finish here.

Originally Posted by NBtarheel_33

Let us then consider adopting the following rules on exponent reporting, progress, and completion:

1. All exponents assigned via PrimeNet or PrimeNet Manual Assignment (in the current "classical" range of interest - note that I'm not really concerned with the 332M tests (right now)) must (1) check in with PrimeNet no less than once every 73 days, and (2) show progress in completion of no less than (a) 10% for an LL test or (b) 20% for an LL-D test. Note that this ideally places an upper bound on LL testing time at 2 years, and an upper bound on LL-D testing time at 1 year.

Re: (2)

There are conceivable situations in which a system's reported progress might drop below 10%/20% between two successive reports, yet the system could be making fine progress overall. (Consider successive reported first-time LL progress of 25%, 25%, 2%, 2%, 6%, 20% & 20% = 1.4 years completion.) I recommend not being too strict about (2).

What I recommend instead is looking at the system's past record of on-time completions. Only if that has been spotty should one judge on current assignment progress. Then, it should judge on cumulative progress-so-far, not "how much have you done for us lately" during only the most recent reporting interval.

COROLLARY: PrimeNet assignments no longer need to have an ultimate, one-year expiration date. Either you check all of your assignments in, with appropriate progress, every 73 days (and keep them), or you don't (and lose them).

See my above counterexample and counter-recommendation.

2. (This is the part that would possibly require some work on the PrimeNet infrastructure.) In the case that either or both of (1) and (2) above are not satisfied, on day 74 from assignment or last progress report, two things happen. First, an e-mail to the user owning the exponent(s) in question is dispatched, warning them that if their exponent(s) do not make a satisfactory progress report within 15 days, these exponents will be lost to be reassigned. At the end of day 89 from assignment or last satisfactory report, if the user stays mum, the AIDs of the exponents should immediately be invalidated, and the exponents should be reassigned as regular 1st LLs or LL-Ds, as appropriate.

NO. That's unnecessarily strict and tunnel-visioned. See above.

Secondly, the exponents without proper reports should be displayed in red on the user's PrimeNet assignments report, and the user's PrimeNet summary should display an appropriate message (e.g. "WARNING! Check in exponents now to avoid losing assignments!").

Okay, but I imagine most users who haven't submitted proper reports won't be checking their PrimeNet reports either. :-)

3. (Regarding poaching.) Any and all poaching of PrimeNet LL or LL-D assignments is permitted...

As I've explained elsewhere (in the "New milestone" thread at http://www.mersenneforum.org/showthread.php?t=7082 in the "Data" subforum), there is no need to resort to unethical methods in order to treat the "milestone irritation" problem. See that thread for better proposed solutions than yours.

Note: I'm not accusing you of having unethical motives is proposing your ideas! I think you just haven't analyzed your proposal from the same viewpoint I have, so you haven't noticed the ethical flaws I did.

...subject to the following caveats. (1) No progress report on any exponent, other than such from the exponent's registered owner, shall be acknowledged by PrimeNet. (I believe this is pretty much what happens now, right?)

No, it's not what happens now AFAIK.

(2) In the event of a completion report from a user other than the registered owner, PrimeNet should handle the result in the following manner: (a) If the result is a first LL result and no other LL result yet exists, PrimeNet should treat the result as a DC-in-waiting. The residue should be posted to the exponent's record, however, as a potential DC, and credit for a DC should be given to the submitter. If the registered user never finishes the LL assignment (due to failure to update in 73 days or due to seeing the poacher's residue), promote the DC-in-waiting to a first LL result.

There are proposed solutions in the other thread that don't require changing PrimeNet reports or fiddling with assignment status.

***If the result is a zero residue (and thus the exponent in question likely yields a Mersenne prime), the submitter should receive DC credit, and the registered owner should be contacted at once to arrange for sending save files, etc. The registered owner is to be credited for the prime discovery, or in the case of the EFF Prize, awarded the prize. The poacher gets a "gee, thanks for helping User X by finding her prime for her!" (and what a lesson that would be).

So, in effect your proposal would violate EFF rules in order to justify violating GIMPS rules in order to capitulate to the sense of irritation felt by some, but not all, participants.

Note: I'm not accusing you of having unethical motives is proposing your ideas! I think you just haven't analyzed your proposal from the same viewpoint I have, so you haven't noticed the ethical flaws.

There are proposed solutions in the other thread that don't have those ethical flaws.

(b) If the result is a first DC result and no other DC result yet exists, PrimeNet should treat the result as a Triple-Check-in-Waiting. No credit is immediately assigned to the poacher, but if the registered user doesn't submit their result, or if their result differs from the LL result (hence requiring a triple check), the poacher should later be credited with DC credit for their early triple check.

Such complications arise from the (IMO) mistaken notion that it's necessary to present status reports that aren't in accord with reality.

(Note: I've recently advocated removing some information from displayed reports, which is not the same as displaying status that isn't in accord with reality. If I did do the latter in the past, please feel free to point it out to me, so I can plainly reject my earlier mistakes.)

In fact, we could make all of this a little more punitive on the poacher

As pointed out in the other thread, it's more effective to remove the motivation for rule-breaking behavior than to punish rule-breaking behavior.

[Graff]

Originally Posted by Prime95

Any missed factors for exponents below 2,000,000 could easily be due to a program bug. There were several such bugs in the earliest prime95 versions. These exponents were likely trial factored in the 1996 - 1999 time frame.

You would appear to be correct in this thought. I'm currently factoring
in the 1.5-1.6M range, extending the upper limit from 2^61 (or
occasionally 2^62) to 2^63, and checking the entire range up to that limit.
To date, I have checked 2837 exponents and found 65 factors. Eleven of
these factors are smaller than the previous upper limit recorded by GIMPS.
The smallest of these "missed" factors was for M1618241 at 55.511 bits,
the largest was for M1509727 at 60.912 bits.

Gareth