:bow::bow::bow:

We are not worthy!

Even though we are indeed not worthy, I'll make a low-priority title-change request:

On the Factoring Effort report ("Factoring Limits" under "Results Queries"), extend the title

"PrimeNet Factoring Effort on Mersenne Numbers"

to be

"PrimeNet Factoring Effort on Mersenne Numbers for which no factor is known"

to hint at why some exponents -- the ones for which factors been found -- are not listed

[quote]The exponent status page will now do this.[/quote]:D:D:D (i like how it only queries the assignments in your workload only)

[QUOTE=petrw1;152695]Mind you, the first 100 LMH results were all .0009 each so 100 would only be 0.09 points not 4.4. Something is ODD here.

And it does NOT look like you have deleted any results of mine yet.

I have to do some detailed analysis to see where the 100 are missing from...stay tuned.[/QUOTE]

Appears to be my mistake on the points total :redface: I recalculated all the results (there are NONE missing yet) and I do get a total within 0.05 of your total (I chalk that up to rounding as I only have access to 4 digits of points.)

However, still not sure why the Results Lifetime and 365 days summary shows 1,600 more results than I really have.

[QUOTE=Prime95;152280]Hope you can read PHP code.[/QUOTE]Hi George, I believe I have found a bug in your code :surprised
It shouldn't affect much in the near future, but...

The problem is that PHP integers are 32bit-signed. Which is fine most of the time, but you get into problems when bitshifting large values. Such as this line:[code]$est += $tf_timing * (1 << ($i - 48)) * 1680.0 / $exponent;[/code]Once $i gets to 79 you end up with negative values and [i]credit_cpu_TF_no_factor()[/i] will return approximately zero when calculating TF to 2^79. The quick-and-easy fix is to change your bitshift to a call to PHP's [url=http://php.net/pow]pow()[/url] function which will typecast to float as needed:[code]$est += $tf_timing * pow(2, ($i - 48)) * 1680.0 / $exponent;[/code]I don't know if anyone has returned factoring results for 2^79 or 2^80 yet (by default exponents > M420400000), if so please check what they were credited as, it's likely wrong.

[QUOTE=James Heinrich;153207]I don't know if anyone has returned factoring results for 2^79 or 2^80 yet, if so please check what they were credited as, it's likely wrong.[/QUOTE]

Fixed last week. Yes, someone did TF one exponent to 2^79 only to get -100 GHz days.

[QUOTE=petrw1;151897]COOL!!! Worked great for me ... even merging 3 into 1 (in two passes of two).

[/QUOTE]

Not sure it will be safe to merge these two:
[CODE]
Jessie Intel Pentium 4 2.40GHz
GUID C0455DED94A2996003B6CAD901BDB92F
Windows,Prime95,v25.7,build 3 2.394 2008-12-16 19:01 T 52.2420 TF 26547371 LL LL, 85.20% 2008-12-19 17:36 2008-12-16 19:00 50 3

Jessie Intel Pentium 4 2.40GHz
GUID C0455DED94A2996003B6CAD901BDB92F
Windows,Prime95,v25.7,build 3 2.394 2008-12-16 19:01 T 52.2420 TF 59107781 TF 0.00% 2008-12-19 17:36 2008-11-12 13:32 36 3 [/CODE]

This CPU was never involved in a duplicate until today. HOWEVER, unlike the others they are virtally identical except for the current assignment which, by the way, in the second case actually belongs to James Hintz.
They even have the same GUID.

My fear is that if I merge them the points will be added and therefore duplicated.

PLEASE ADVISE....

P.S. My Quad still shows up as a second entry as a PIII Xeon after each reboot. I'll see if 25.8.4 fixes that. I can and do merge them when this happens but it resets my Reliability/Confidence numbers so I will never get 'preferred' assignments.

This is a bug in the CPUs web page. Don't try to merge them - they are the same CPU.

FIXED....
 

[QUOTE=Prime95;153627]This is a bug in the CPUs web page. Don't try to merge them - they are the same CPU.[/QUOTE]

Duplicate is gone now.
Thanks

Could we possibly have a feature added to the Manual Testing assignment page to let us request a specific assignment? I know that this can already be done with a PrimeNet-connected client (that is, by entering an assignment into worktodo.txt manually, and then next time the client communicates with the server if reserves the assignment if it's not already reserved by someone else), but there is currently no such way to do this for manual testing.

Over in the LMH subforum, in the "65.1M-66.0M to 2^64" thread at [URL]http://www.mersenneforum.org/showthread.php?t=11159[/URL], mdettweiler made a new-feature suggestion (a way to request manual assignments of a specific range of exponents, but skipping exponents already assigned to others) [I](edit: there it is just above here)[/I] that ties right in with something I was thinking about earlier:

Here's the way I described my proposal in the "LL vs. DC ... am I reading this right?" thread at [URL]http://www.mersenneforum.org/showpost.php?p=151166&postcount=5[/URL]

[quote=cheesehead;151166]Proposal:

A new PrimeNet function, [I]conditional specific assignments[/I].

A conditional specific assignment would be requested by someone _for a specific exponent_ and type of assignment (TF, P-1, L-L, DC ...). Then PrimeNet would:

if that exponent was not currently assigned to anyone else (for any purpose), then assign it as requested (and return a code indicating that success),

else

return a code indicating that the conditional assignment request was refused.

(Exponents in ranges not currently available for assignment would be in the latter category.)

The refusal return code could be elaborated:

the exponent was already assigned to someone else for some purpose,

the exponent previously had been L-Led (first-time or later) by the requestor of a conditional L-L assignment -- to prevent two L-L test assignments to the same person on an exponent,

the exponent is already assigned to the (apparently forgetful) requestor :-),

range not currently available for assignment,

and so on.

This wouldn't [I]prevent[/I] anyone from doing whatever they can do now, such as performing two L-Ls on the same exponent or doing a test on an exponent currently assigned to someone else; it would just provide folks a better means to avoid doing so accidentally or unknowingly, by cooperating with PrimeNet instead of going around it by perusing a report then forcing a manual communication to squat on an exponent (hoping that PrimeNet had not assigned it since the report's epoch, but not having any assurance of that).[/quote]Now, PrimeNet already does something like that internally, but what we're proposing is to make it explicitly external on the Manual Assignments page.

While my proposal above is about single exponents, it could be extended to a range of exponents, I think. The stuff about return codes isn't essential.