Credit for trial factoring
 

I have just TF an exponent in the range 71:72 and found a factor.
However the only credit I received was:
CPU credit is 0.6650 GHz-days.
I did factor the whole of the exponent, so I would have thought the minimum I would have received would have been 7.0282 GHz-days which is what I received for the previous TF which did not find a factor.

Are found factors being credited differently now? :confused:

P95 does the [U]trial[/U] (not trail :P) factoring by testing the candidates in increasing order. If your factor is at the beginning of the range (i.e. 2^71+k, with a very small k), you may find it in the first minute, or in the first second. Why should you get billions of credit for just few seconds of work? :razz:

When GPUs came into the pool, the logic shifted, the range is divided in modularity classes, and the candidates in each class are processed in parallel using the multitude of cores the GPU has. Therefore, you may be lucky and find a very big factor (close to 2^72) in the first class, in 5 seconds, or work one day, and find a very small factor (close to 2^71), in the last class you crunch.

PrimeNet is not (yet) aware of GPUs, as I said so many times here.

He will give you the credit according with the size of the factor, assuming you found it with P95. It is not possible otherway, without introducing the possibility of cheating (you find a factor with one program, but report it with the other, to get more credit).

So, in the last case described above, you will get small credit for a lot of work, or in the former case described, you will get a huge credit for just few seconds of work.

You were unlucky this time.

LaurV is correct. It will all even out eventually, though.

LaurV and I are what you might call credit whores, but I still attribute more value to "factors found" than "GHz-Days" of credit.

To add on to what LaurV said, you will never receive as much credit for a TF factor as for a non-factor test, as the factor found cannot be above the range searched. The credit should always be between the (using yours as an example) credit from 70-71 and the credit from 71-72 with no factor. In other words, you get more than the previous full bit's credit but less than the current "full bit" depth credit.

[QUOTE=TheMawn;366765]
LaurV and I are what you might call credit whores, but I still attribute more value to "factors found" than "GHz-Days" of credit.[/QUOTE]

Damn right :razz:

[SIZE="1"](*poke* *poke* LaurV)[/SIZE]

[QUOTE=c10ck3r;366767]To add on to what LaurV said, you will never receive as much credit for a TF factor as for a non-factor test, as the factor found cannot be above the range searched.[/QUOTE]

To add on to what c10ck3r said, this is true for Primenet. On GPU72 you get the full credit for the range the factor was found in. As in, if you were assigned work for a candidate from 71 to 74, and found a factor which was at 72.1, you'll get the GHz/D credit for TFing from 71 to 73.

My thinking was (and is) that since the goal of TF'ing is to find factors, those successful should get the full credit for the range they worked up to (and I have no way of determining if the range was fully tested, or only partially. Primenet has this knowledge (or, at least, is told); I don't).

[QUOTE=c10ck3r;366767]To add on to what LaurV said, you will never receive as much credit for a TF factor as for a non-factor test, as the factor found cannot be above the range searched. The credit should always be between the (using yours as an example) credit from 70-71 and the credit from 71-72 with no factor. In other words, you get more than the previous full bit's credit but less than the current "full bit" depth credit.[/QUOTE]
This is not accurate. LaurV was right.

Perhaps this will help clarify:
No factor from 70-71 grants 3.5 GHz-days
A factor in the 70-71 range grants 0-3.5 GHz-days, depending on how long it would've taken Prime95 to find it.
No factor from 71-72 grants 7.0 GHz-days
A factor in the 71-72 range grants 0-7.0 GHz-days, depending on how long it would've taken Prime95 to find it.

Mfaktx searches for factors in a different order than Prime95, meaning sometimes you can do 99% of the work and get 1% of the credit (which is roughly what happened this time), but on the flipside you could find a factor at the 1% mark and get 99% of the credit. In the long run, it averages out so that you get as much credit as you worked for.
This is assuming you have Mfaktx configured to stop after you find a factor. You can search the rest of the bit range if you like, but PrimeNet won't credit you for it, because it's outside PrimeNet's main scope. If you do continue to search, you'll always do 100% of the work for (average) 50% of the credit when finding a factor (since factor found results are a minor portion of your overall TF credit, this is actually pretty insignificant).

Is that primenet bug fixed that would calculate the credit as if it was a F-PM1 (factor found by P-1)?

OTOH, so far I NEVER got less credit for a factor than for completing a bitlevel with NF. Typically, I'd say, it is 100-200% of the credit of an NF for the same range.
As in
[code]
INFO: M65531953 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65459887 submitted; 29.2243 GHz Days credit. (73 -> 74)
INFO: M65771899 submitted; 14.5428 GHz Days credit. (72 -> 73)
INFO: M65771527 submitted; 14.5429 GHz Days credit. (72 -> 73)
INFO: M65771899 submitted; 37.8749 GHz Days credit. (73.3 bit factor)
INFO: M65772071 submitted; 14.5428 GHz Days credit. (73 -> 74)
[/code]or
[code]
INFO: M65532281 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531317 submitted; 29.1925 GHz Days credit. (73 -> 74)
INFO: M65531933 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65531461 submitted; 14.5962 GHz Days credit. (72 -> 73)
INFO: M65532281 submitted; 29.1920 GHz Days credit. (73 -> 74)
INFO: M65531951 submitted; 25.4500 GHz Days credit. (72.7 bit factor)
INFO: M65532283 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531953 submitted; 14.5961 GHz Days credit. (72 -> 73)
INFO: M65531461 submitted; 29.1924 GHz Days credit. (73 -> 74)
INFO: M65532283 submitted; 29.1920 GHz Days credit. (73 -> 74)
[/code]

I've had the same experience as bdot.

So I wasn't hallucinating ....:smile:

[QUOTE=Bdot;366885]Is that primenet bug fixed that would calculate the credit as if it was a F-PM1 (factor found by P-1)?

OTOH, so far I NEVER got less credit for a factor than for completing a bitlevel with NF. Typically, I'd say, it is 100-200% of the credit of an NF for the same range.
As in
[code]
INFO: M65531953 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65459887 submitted; 29.2243 GHz Days credit. (73 -> 74)
INFO: M65771899 submitted; 14.5428 GHz Days credit. (72 -> 73)
INFO: M65771527 submitted; 14.5429 GHz Days credit. (72 -> 73)
INFO: M65771899 submitted; 37.8749 GHz Days credit. (73.3 bit factor)
INFO: M65772071 submitted; 14.5428 GHz Days credit. (73 -> 74)
[/code]or
[code]
INFO: M65532281 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531317 submitted; 29.1925 GHz Days credit. (73 -> 74)
INFO: M65531933 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65531461 submitted; 14.5962 GHz Days credit. (72 -> 73)
INFO: M65532281 submitted; 29.1920 GHz Days credit. (73 -> 74)
INFO: M65531951 submitted; 25.4500 GHz Days credit. (72.7 bit factor)
INFO: M65532283 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531953 submitted; 14.5961 GHz Days credit. (72 -> 73)
INFO: M65531461 submitted; 29.1924 GHz Days credit. (73 -> 74)
INFO: M65532283 submitted; 29.1920 GHz Days credit. (73 -> 74)
[/code][/QUOTE]

This is a known bug, low on the priority list, though with the Web site renovations, it might just finally get some attention.

well.. we never experienced otherwise here, which is [U]normal and correct[/U] according with the time we invested in factoring, in long term averaging.

(sorry for the formatting, I am a bit in hurry)

[CODE]Manual testing 41482733 F 2014-02-14 05:22 0.0 343020020610099313049 0.3125
Manual testing 41483399 NF 2014-02-14 05:22 0.0 no factor for M41483399 from 2^68 to 2^69 [mfakto 0.13-Win cl_barrett15_69_gs_2] 1.4411
Manual testing 35525923 F 2014-02-14 01:16 0.0 1616268328913346819329 3.0502
Manual testing 35525807 NF 2014-02-14 01:16 0.0 no factor for M35525807 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7311
Manual testing 35525141 NF 2014-02-13 23:13 0.0 no factor for M35525141 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7312
Manual testing 41471389 F 2014-02-13 22:17 0.0 343995315434689936607 0.3185
Manual testing 41472661 NF 2014-02-13 22:17 0.0 no factor for M41472661 from 2^68 to 2^69 [mfakto 0.13-Win cl_barrett15_69_gs_2] 1.4415
Manual testing 35524277 NF 2014-02-13 19:05 0.0 no factor for M35524277 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7314
Manual testing 41466101 F 2014-02-13 18:14 0.0 522256853656664233487 1.1870
Manual testing 41466527 NF 2014-02-13 18:14 0.0 no factor for M41466527 from 2^68 to 2^69 [mfakto 0.13-Win cl_barrett15_69_gs_2] 1.4417
Manual testing 35523797 NF 2014-02-13 17:00 0.0 no factor for M35523797 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7315
Manual testing 41463671 F 2014-02-13 16:13 0.0 490020082106298012337 1.0545
Manual testing 35523443 F 2014-02-13 14:57 0.0 2104958803532585306983 5.6160
Manual testing 35523473 NF 2014-02-13 14:57 0.0 no factor for M35523473 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7315
Manual testing 35523259 F 2014-02-13 13:55 0.0 1964303073347245406057 4.9444
Manual testing 35523143 NF 2014-02-13 13:55 0.0 no factor for M35523143 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7316
Manual testing 35516167 F 2014-02-12 23:26 0.0 2049830258650648675937 5.3594
Manual testing 35516353 NF 2014-02-12 23:26 0.0 no factor for M35516353 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs] 6.7329
Manual testing 41431069 F 2014-02-12 15:25 0.0 377275909099099752481 0.5111
Manual testing 41431237 NF 2014-02-12 15:25 0.0 no factor for M41431237 from 2^68 to 2^69 [mfakto 0.13-Win cl_barrett15_69_gs_2] 1.4429
[/CODE]

I have now had a look at the new stats available on mersenne.ca thus:
[URL="http://www.mersenne.ca/exponent/68047649"]http://www.mersenne.ca/exponent/68047649[/URL] which gives a credit of 3.941 Ghz/day rather than the 0.6650 Ghz/day I was awarded

Still confused ...

Shouldn't the credit for finding a factor actually be almost 0.0?
At the moment submitting a factor only includes this as the information.
What is missing is the information that (maybe) additional effort has been spent.
The server implicitly assumes that also everything below has been checked and gives credit for that but IMO this should be reported as well - and that's the submission the user gets the credit for, like:

no factor for M987654321 from 2^77 to 2^77.7777777 (credit given)
M987654321 has a factor: 259086082177383985712319 (=2^77.7777777, no credit given)

[QUOTE=ramgeis;366947]Shouldn't the credit for finding a factor actually be almost 0.0?
At the moment submitting a factor only includes this as the information.
What is missing is the information that (maybe) additional effort has been spent.
The server implicitly assumes that also everything below has been checked and gives credit for that but IMO this should be reported as well - and that's the submission the user gets the credit for, like:

no factor for M987654321 from 2^77 to 2^77.7777777 (credit given)
M987654321 has a factor: 259086082177383985712319 (=2^77.7777777, no credit given)[/QUOTE]
However this does not take into account if there is another factor for the same exponent. Is it 'ethical' to not factor each exponent to the end of the bit depth ...

[QUOTE=ramgeis;366947]
no factor for M987654321 from 2^77 to 2^77.7777777 (credit given)
M987654321 has a factor: 259086082177383985712319 (=2^77.7777777, no credit given)[/QUOTE]
This is exactly what I explained in my initial post, and exactly what the server is doing, because it assumes you did TF with p95, which tests the factor candidates [U]in order[/U]. The problem is that there are programs which do not test the candidates in order: mfaktc, mfakto, blah blah. Imagine you want to find the factors of x=473*z, with z being a big prime, but have a program which tests first the factor candidates which are 1 (mod 3), then the ones which are 2 (mod 3). For whatever reasons, say that the program is faster doing that. So, after filtering, you check if 7, 13, 19, 31, etc is a factor, and you will find first the factor 43, and only (much) later the factor 11. In this case, if you stop after you find 43, and you report it, you will get more credit than you would get by reporting the 11, because the server assume you took them "in order". He doesn't know how much time you spent, or what the program does. [U]He is either not aware that a smaller factor was missed [/U](11) because he is in other modularity class, not yet tested. That is why you always have to report the fact that the bitlevel was "partially tested", smaller factors may exist if the test was done with mfaktX.

And taking the time into account would not be right for the people having faster hardware, or overclocking (i.e. investing more money in electricity!).

The only thing you can take into account is the size of the factor. In time, this "averages" to the right credit. There is no harm done. Sometime you are lucky, finding a big factor fast, because it was in the first class, and get big credit. Sometime is viceversa, the small factor lies in the last tested class. So what?

[QUOTE=LaurV;366953]because it assumes you did TF with p95, which tests the factor candidates [U]in order[/U].[/QUOTE]

Nuh uh. It does not. It too uses factor classes.

Frankly I couldn't care less about how much credit I get for finding a factor. I'll say it again: I am as much of a GHz-Days whore as LaurV but I fully understand that their value is completely meaningless.

If I TF'ed and found 2[SUP]66.1[/SUP] as a factor, why am I getting credited more or less than if the factor was 2[SUP]73.9[/SUP]? I cleared the exponent just the same.

You might argue that [I]finding[/I] the factor was more work so I should be awarded more credit, which is a perfectly legitimate claim. But what of the fact that I [I]saved[/I] two LL tests (or one if we're DC-TF'ing)? Should I be credited for the work I saved? But then DC-TF to [SUP]72[/SUP] should be worth less than LL-TF to 2[SUP]72[/SUP] if a factor is found?

It's all kind of subjective and confusing.

[QUOTE=ramgeis;366947]Shouldn't the credit for finding a factor actually be almost 0.0?
[/QUOTE]
Seems the good times are over, and this has been "fixed" :sad:
[code]
got assignment: exp=65986033 bit_min=72 bit_max=73 (14.50 GHz-days)
Starting trial factoring M65986033 from 2^72 to 2^73 (14.50GHz-days)
Using GPU kernel "cl_barrett15_73"
No checkpoint file "M65986033.ckp" found.
W4 done| ETA | GHz |time/class| #FCs | avg. rate | SieveP. |CPU idle
24.0% | 5h35m | 47.35 | 27.555s | 1.64G | 59.36M/s | 30951 | 2.06%
M65986033 has a factor: 4822533015970008558073

found 1 factor for M65986033 from 2^72 to 2^73 (partially tested) [mfakto 0.13-Win cl_barrett15_73_2]
tf(): total time spent: 1h 46m 16.954s (196.40 GHz-days / day)[/code][code]
20140222_102728 INFO: M65986033 submitted; 0.4389 GHz Days credit.[/code]But that is OK, I've been "overpaid" for a long time :smile: - I just need to change mfakto's GHz-days calculation ...

Just one question: was the mfaktc/o detection also fixed, meaning, can I remove submitting my "dummy no factor mfakto" along with factors without the server changing "F" to "F-PM1"?

[QUOTE=Bdot;367692]
Just one question: was the mfaktc/o detection also fixed, meaning, can I remove submitting my "dummy no factor mfakto" along with factors without the server changing "F" to "F-PM1"?[/QUOTE]
Not fixed. Continue to submit a "no factor" line in front, when you only report factors.

Thanks, I'll keep it.

Did you see a post anywhere that details the new calculation for "F" results? Or, do you happen to know?

[QUOTE=Bdot;367696]Did you see a post anywhere that details the new calculation for "F" results? Or, do you happen to know?[/QUOTE]
If you read my former posts, you will see that for me it always was like it is now. I still can't believe that you could get, for finding a factor, a higher credit than for a "no factor" result, because, in ANY case, no mater what program you used, you spent LESS time to find that factor.

The "logical" procedure to compute the right credit, would be:
A) assuming the factor was found with p95 or some program which tests the factors consecutively, or splits them in classes, but checks all classes in parallel, then the credit is c*(f-s)/(F-s), where c is the credit you get for "no factor", f is the factor you found, F is the highers factor candidate in the interval, s is the starting candidate (the smallest candidate). Or something like that.

B) assuming the candidates are split in classes which are done serial (i.e. one by one, as mfaktx is doing) then if you found the factor in class x, you should get the credit for completing (x-1) from 960 classes, plus the part of the x-class credit till you found the factor.

Only one method should be used, to avoid cheating, or the [B]max credit[/B] between the two can be given (!), in this case there is no tempting to cheat (like finding a factor with one program and reporting it with another program, to get bigger credit), and the users would be happy they got a small bonus for finding a factor. As opposite of the case when no factor is found - no bonus is given. In time, this normalizes anyhow to the right credit (plus a small bonus) for long runners.

Edit: remark that in all cases, finding a factor (except additional bonus which accumulates over time) has to (and it would!) bring you less credit than for a "no factor" result. You just spent less time finding it, regardless the program you used. Of course, a "bonus" can be given because you found a factor, like some constant "c" added to the calculus above. This would be a different story.

However, I believe George/James can enlighten you about the formulas. They (the formula, not the guys) are also somewhere in the source codes, or on the web page, or wiki, I remember I saw them in the past.

I notice that neither George or James have posted in this post, but I still say that the formula for working the factoring credit changed sometime earlier this month, about the time that I initiated this thread. This is what my results history shows.
You obviously have made your statement, and I am unable to argue with you, as I do not have your technical knowledge. However I believe that I am not alone in my thoughts, but don't wish to antagonize anyone at all.
As Bdot said, the good times are over ....

Bdot can easily make typing mistakes in reports like the one in post #8 :razz: He is not a trustful person... :whistle:

[QUOTE=Bdot;366885]OTOH, so far I NEVER got less credit for a factor than for completing a bitlevel with NF. Typically, I'd say, it is 100-200% of the credit of an NF for the same range.
As in
[code]
INFO: M65531953 submitted; 29.1922 GHz Days credit. (73 -> 74)
<snip>
INFO: M65771527 submitted; [COLOR=Red]14.5429[/COLOR] GHz Days credit. ([COLOR=Red]72 -> 73[/COLOR])
INFO: M65771899 submitted; 37.8749 GHz Days credit. (73.3 bit factor)
INFO: M65772071 submitted; [COLOR=Red]14.5428[/COLOR] GHz Days credit. ([COLOR=Red]73 -> 74[/COLOR])
[/code][/QUOTE]

Joking apart, I don't say that the method to calculate the credit did not change. You may be right. Or Bdot may be right. Only George and James can tell. I just say that for me it was ever like that, I never got a bigger credit for a factor, than I would get for a "no factor" in the same bitlevel. And (if no bonus is given) it is normal to get a lower credit, because you spent less time. That is the only thing I said, I don't want to argue with anybody. For me, everything looks normal, as it ever was. I may be getting older, however :yucky:

I however think that you people are trusting too much your scripts and you don't check how much credit PrimeNet REALLY gave you for assignments, those reports like in my post #12. And when you suddenly and inadvertently find out, you are very fast in claiming that "something changed" :razz:

I never spend less time, because I always factor the exponent to the end of its bit level, rather than finishing at the end of the class. So the time spent factoring would be the same time as for an exponent which did not have a factor found.

I have merely made an observation based on a reasonable sample size.

[QUOTE=LaurV;367716]I however think that you people are trusting too much your scripts and you don't check how much credit PrimeNet REALLY gave you for assignments, those reports like in my post #12. And when you suddenly and inadvertently find out, you are very fast in claiming that "something changed" :razz:[/QUOTE]

All of my factors.

Regarding factoring to the end of the bit level even if a factor was found, LaurV (quickly) converted me to stopping.

If the project ever turns into a find-the-factors project (because we have infinity billion GPU's suddenly) then we will want to factor to the end regardless. In fact, partial factoring will be worth zero because you have to redo the whole bit level if you don't know how the classes were set up.

On the other hand, a factor is worth one or two LL tests so maybe it's fair that you get more credit? Actually I think I've brought myself through this thought process before and it got nowhere.

[QUOTE=TheMawn;367725]If the project ever turns into a find-the-factors project ...[/QUOTE]

...then, since PrimeNet doesn't record whether you did a partial or to-the-end search when you found a factor, we'll assume that we need to redo the whole bit range anyway. So nothing is gained by completing the bit range (except in ranges where we are in a find-the-factors mode; but those aren't typically TF'd).

There was another thread which discussed the ethics of performing an incomplete factoring to a bit level and the consensus seemed to be that it was 'better' to do this, rather than just to the class level.
If that consensus has now moved the other way, I am happy to change :smile:

[QUOTE=LaurV;367716]Bdot can easily make typing mistakes in reports like the one in post #8 :razz: He is not a trustful person... :whistle:
[/QUOTE]
Boy, someone's reading my stuff to the dot. Cool, keep going :grin:
[QUOTE=LaurV;367716]
I however think that you people are trusting too much your scripts and you don't check how much credit PrimeNet REALLY gave you for assignments, those reports like in my post #12. And when you suddenly and inadvertently find out, you are very fast in claiming that "something changed" :razz:[/QUOTE]

I briefly thought you could be right with this, and the new web page layout could have tricked the submit_spider. However, the primenet report clearly shows the change between 2014-02-05 and 2014-02-08 (same bad formatting as your #12 :big grin:):
[code]
CPU Name Exponent Result Type Received age days Result GHz-Days
Manual testing 65983289 F 2014-02-25 10:28 0.0 4971076954942570156649 1.0734
Manual testing 65477507 F 2014-02-24 11:44 0.0 12663102147556814658191 12.3600
Manual testing 65986153 F 2014-02-23 10:26 0.0 7240382971298531589289 8.9374
Manual testing 65986033 F 2014-02-22 10:27 0.0 4822533015970008558073 0.4389
Manual testing 65761351 F 2014-02-18 10:35 0.0 10853841280216457006249 5.8362
Manual testing 65753309 F 2014-02-10 10:39 0.0 16189503994930825683457 22.6198
Manual testing 65759651 F 2014-02-09 10:26 0.0 7323761882888134203151 9.2084
Manual testing 65761541 F 2014-02-08 10:25 0.0 8699247776308188055079 12.8198
Manual testing 65761207 F 2014-02-05 10:25 0.0 8375528634063682210849 26.5666
Manual testing 65765723 F 2014-02-04 11:39 0.0 9108843388977589917593 28.3259
Manual testing 65733469 F 2014-02-04 10:39 0.0 7612157239665569840441 24.5716
Manual testing 65771899 F 2014-02-03 21:32 0.0 11646199706640592599871 37.8749
Manual testing 65531951 F 2014-02-01 19:49 0.0 7907998769962613503369 25.4500
Manual testing 65571031 F 2014-01-28 22:10 0.0 8710789282820948395649 27.4696
Manual testing 65541913 F 2014-01-28 10:38 0.0 14605095256947365624183 47.5409
Manual testing 65572421 F 2014-01-21 10:26 0.0 6246733051929437688191 20.4716
Manual testing 65346877 F 2014-01-19 10:38 0.0 11411856718724448587071 37.2628
Manual testing 65371883 F 2014-01-15 11:26 0.0 5894394064099461926527 19.3089
Manual testing 65371703 F 2014-01-14 10:27 0.0 8140547550554612286943 26.1242
Manual testing 65360959 F 2014-01-12 10:39 0.0 15259096434338874034457 49.5223
Manual testing 65360531 F 2014-01-12 10:38 0.0 10252037559785378333881 32.7294
Manual testing 65374669 F 2014-01-12 10:25 0.0 6224352925289852013919 20.4578
Manual testing 65381737 F 2014-01-10 10:26 0.0 5820201298913626509767 19.0386
Manual testing 65319637 F 2014-01-08 21:59 0.0 10309586108828411918503 32.9864
Manual testing 65261507 F 2014-01-07 10:25 0.0 7907603518155528695537 25.5544
Manual testing 65261087 F 2014-01-05 10:26 0.0 8418955939659876734993 26.8796
Manual testing 65264273 F 2014-01-05 10:25 0.0 4917056359367000200921 15.5075
Manual testing 65267087 F 2014-01-04 10:26 0.0 6862351050580977896071 22.5547
Manual testing 65263507 F 2014-01-01 10:26 0.0 6234283038789276522001 20.5263
Manual testing 65266489 F 2014-01-01 10:25 0.0 8599645111057124380439 27.3263
Manual testing 65259373 F 2013-12-30 10:26 0.0 9104963855127898545943 28.5367
Manual testing 65262979 F 2013-12-30 10:25 0.0 9133487627104265977649 28.6012
Manual testing 65248993 F 2013-12-24 10:36 0.0 8871736832475716204039 27.9924
Manual testing 65157737 F 2013-12-23 10:25 0.0 5065687354011880256489 16.1635
Manual testing 65154941 F 2013-12-20 10:26 0.0 8407674051753018332063 26.8949
Manual testing 65157143 F 2013-12-18 10:25 0.0 7136434613407836933433 23.4222
Manual testing 65152141 F 2013-12-16 10:25 0.0 6158131564100228807321 20.3011
Manual testing 65147681 F 2013-12-16 10:25 0.0 5506849441358956254329 17.9348
Manual testing 65149351 F 2013-12-14 10:25 0.0 8796374039777563596913 27.8545
Manual testing 64750783 F 2013-12-11 10:26 0.0 6987103442023177161023 23.1185
Manual testing 64928503 F 2013-12-08 18:09 0.0 6470876830040947559303 21.4239
[/code]@axn: your view confirms the change between 2014-02-03 and 2014-02-19 where you get the same credit for a much bigger factor (of a slightly bigger exponent).

Might I suggest a separate statistic for Total Factors Found (or something to this effect)?

[QUOTE=c10ck3r;368073]Might I suggest a separate statistic for Total Factors Found (or something to this effect)?[/QUOTE]

This is the "successes" in your TF statistics.

EDIT: These were once upon a time displayed in user statistics but it seems they are not, now. Still appear in top producers, though.

[B]EDIT: Forget it, I was not paying attention - nothing has changed (this time).
[/B]

[SIZE=1][QUOTE=Bdot;367692]Seems the good times are over, and this has been "fixed" :sad:
[/QUOTE]
:smile: They are back ... I just submitted 3 factors and got credit like in the good old times


[code]Manual testing 66610373 F 2014-03-07 16:08 0.0 8494034439425749743959 12.1619
Manual testing 65578871 F 2014-03-07 15:48 0.0 17415995573166599970359 25.7533
Manual testing 65587583 F 2014-03-07 15:44 0.0 8610939780518590585921 12.6391[/code][/SIZE]

I received credit of ~20 for my most recent factor in the 66M range.

[QUOTE=TheMawn;367725]

[snip]

On the other hand, a factor is worth one or two LL tests so maybe it's fair that you get more credit? Actually I think I've brought myself through this thought process before and it got nowhere.[/QUOTE]

I'd like the credit for the GHz days saved with this test :lol:

[url]http://www.mersenne.ca/exponent/374011241[/url]

The 13,200 for the TF would be nice but the 2X10^19 for the 136 bit composite factor would be even better....

[QUOTE=Gordon;371477]I'd like the credit for the GHz days saved with this test :lol:

[url]http://www.mersenne.ca/exponent/374011241[/url]

The 13,200 for the TF would be nice but the 2X10^19 for the 136 bit composite factor would be even better....[/QUOTE]

Back on this again, have found two more "double factor" (67 bits each) exponents, up in the 800m range, where just the P-1 will take 56,800 GHz days to run.

The LL test will take 22,068 days, same for the DC.

That alone has saved the project from using over 100,000 days of CPU.

Why then is the credit only 0.05?

and yes I did search but couldn't find any rational explanation

[QUOTE=Gordon;372735]Why then is the credit only 0.05?[/QUOTE]

You get the credit for the work [U]done[/U], not the work [U]saved[/U].

Otherwise everyone would be TFing up in the 999M range, even though, realistically, we'll never [I]ever[/I] do a P-1, let alone a LL, test up there for the reasons you yourself detailed.