[QUOTE=James Heinrich;391505]Actually it's backwards -- the asterisk means that the assignment was started with the target bitlevel but the range was [i]not[/i] completed.

Unfortunately that means that an absence of asterisk either means that the range was definitely completed (newer versions of mfakt*), or that it's an older version of the software that didn't differentiate. You'd have to parse for version number to differentiate between those two cases.[/QUOTE]

Pphhtpptb! Well who designed that? LOL With all due respect to whomever wrote that, seems like adding an asterisk for complete testing in a range would have eliminated that ambiguity.

Oh well... sometimes you never know in advance about stuff like that. I've done things backwards plenty of times.

[QUOTE=tha;391637]The "Manual Testing | Assignments" page serves a new set of assignments during a reload of the page. That means if someone leaves the page open on one of the tabs, every restart of the browser may lead to new assignments being requested. Can a safeguard be build in to prevent that?[/QUOTE]

How likely is that to happen? I know if Chrome closes unexpectedly, it'll ask to restore all your tabs when you start it up (maybe FF, IE, Safari do the same). But is that common? I'm assuming it's happened to you, so it must happen sometimes. :)

The current design of the pages will sometimes use a URL parameter to indicate a "submit" button was pressed, so the page will act on that when parsing. It seems like URL parameters aren't the ideal method, true. I don't remember if the manual assignment page does it that way or not, but I'd guess it does. I suppose an ajax method or something similar would be appropriate so that merely reloading the page won't give you more stuff.

In the meanwhile, don't bookmark the page that comes up with your assignments, and close that tab or browse away when you're done. :smile:

[QUOTE=Madpoo;391650]Pphhtpptb! Well who designed that? LOL With all due respect to whomever wrote that, seems like adding an asterisk for complete testing in a range would have eliminated that ambiguity.

Oh well... sometimes you never know in advance about stuff like that. I've done things backwards plenty of times.[/QUOTE]

Thankfully TF has some nice properties that make these things less of a big deal. If we find a factor, it doesn't matter as far as the compositeness goes whether or not the range was fully completed. For someone planning on finding all factors, it wouldn't be a bad idea to re-do the TF anyway. Even so, the missed factor would likely get picked up elsewhere.

Also, TF results can only be faked to give no factor results. A prime cannot be missed through anything like that.

[QUOTE=Madpoo;391652]How likely is that to happen? I know if Chrome closes unexpectedly, it'll ask to restore all your tabs when you start it up (maybe FF, IE, Safari do the same). But is that common? I'm assuming it's happened to you, so it must happen sometimes. :)

The current design of the pages will sometimes use a URL parameter to indicate a "submit" button was pressed, so the page will act on that when parsing. It seems like URL parameters aren't the ideal method, true. I don't remember if the manual assignment page does it that way or not, but I'd guess it does. I suppose an ajax method or something similar would be appropriate so that merely reloading the page won't give you more stuff.

In the meanwhile, don't bookmark the page that comes up with your assignments, and close that tab or browse away when you're done. :smile:[/QUOTE]

A simply solution for this is to include a timestamp in the GET/POST parameters. Have it server generated and compared to server time. If it's over some amount of time old, disregard the request for assignments. For backwards compatibility, work as normal if the timestamp parameter is missing.

[QUOTE=Mark Rose;391669]A simply solution for this is to include a timestamp in the GET/POST parameters. Have it server generated and compared to server time. If it's over some amount of time old, disregard the request for assignments. For backwards compatibility, work as normal if the timestamp parameter is missing.[/QUOTE]More precisely it is a misuse of the GET / POST verbs. GET is "supposed" to be for requests that do not alter any state, and POST is "supposed" to be for requests that modify state. Note that most (all?) browsers will alert the user if a POST request is being resubmitted, but are silent for GET requests.

[QUOTE=retina;391672]More precisely it is a misuse of the GET / POST verbs. GET is "supposed" to be for requests that do not alter any state, and POST is "supposed" to be for requests that modify state. Note that most (all?) browsers will alert the user if a POST request is being resubmitted, but are silent for GET requests.[/QUOTE]

Absolutely true. I missed that. It should be POST only.

Similar to how it reports DC/LL as C-Verified or C-Unverified...so I know if a DC was successful.
.
.
.
could it report F-First, F-Additional or F-Last (or terms to that effect) so I know if an MP was newly factored, more factored or completely factored.

Manual results page
 

The results from GMP-ECM give errors when manually submitted.

Is there a possibility to adjust it?

Luigi

Does the current server all for manual submissions from Luigi's (ET_) Factor5?

The reason that I am asking, with the minor success that TJAOI has been having with missed factors, I thought about re-running exponents (with no known factors) in the 100M digit range with it up to something like 62 bits.

James has code to ingest said results.

[QUOTE=Uncwilly;392807], I thought about re-running exponents (with no known factors) in the 100M digit range with it up to something like 62 bits.[/QUOTE]

Any chance you would simply be duplicating what TJAOI is doing?
At least up to the 56 or so bits he is at now.

[QUOTE=petrw1;392808]Any chance you would simply be duplicating what TJAOI is doing?
At least up to the 56 or so bits he is at now.[/QUOTE]I am looking at getting the jump on TJaoi and only working on those exponents without a known factor, and in a narrower range. Also, finding a factor in this range could save work in the shorter term than most of Tjaoi's.

[STRIKE]I was doing some re-runs with Prime95 and found an exponent that is taking vastly longer than the others to take from 59 to 60.
I am running v27.7 and Factor5 just finished the number before Prime95. If someone is willing to try the expo on a different build, PM me.[/STRIKE]
<edit>Must have been a glitch that got saved into the interim file. I tried an older version and it stuck to. I exited Prime95, deleted the fxxxxxxxxx and fxxxxxxxxx.bu, then restarted and it went fine.</edit>