View Single Post
Old 2020-10-19, 18:09   #3372
kriesel's Avatar
Mar 2017
US midwest

3·5·17·19 Posts

Originally Posted by LaurV View Post
@kriesel: All you said was clear already. We KNOW than the credit is smaller when you find a factor, IF you stop after the factor is found. And this is normal, as you do less work. The question was what's the credit if you DON'T stop (and finish all the bitlevel). You should still get all the credit, factor or no factor, but this I didn't know if true. On the other hand (and this everybody knows for ages!), the difference between two lines that report respectively "i found one factor and I stopped after that class" and "I found one factor but I still continued the rest of the classes till the bitlevel ended", is just one asterisk (which you can edit with a text editor, if you want to test, or if you want to cheat the system and get more credit). That's what I (and James) am (are) talking about.
LaurV, you are pointlessly belaboring the other case, mfaktO default, stopafterfactor=2 (stop after current class) correctly getting lesser credit, which is not at issue here. What is at issue is mfaktC default stop after current bit level getting credit for only stop after current class, incorrectly reduced.

Mfaktc separately reports the factor(s) and the bit level completed.

I posted an excerpt from mfaktc.ini at showing I DO go to the full bit level regardless, as is mfaktc default configuration.
And examples in and where doing so and finding a factor results in REDUCED credit. Also note in the first attachment of 3367, the more than an hour delay between the factor and the completion of the bit level, on an RTX2080 Super (1 of 3 instances running together).
I can back that up with logging of all classes run after the one or more that contained a factor.
Starting trial factoring M114969319 from 2^75 to 2^76 (66.56 GHz-days)
 k_min =  164300059317240
 k_max =  328600118636496
Using GPU kernel "barrett76_mul32_gs"
Date    Time | class   Pct |   time     ETA | GHz-d/day    Sieve     Wait
Oct 18 14:58 |    0   0.1% |  5.967   1h35m |   1003.89    82485    n.a.%
Oct 18 14:58 |    5   0.2% |  5.620   1h29m |   1065.87    82485    n.a.%
Date    Time | class   Pct |   time     ETA | GHz-d/day    Sieve     Wait
Oct 18 15:35 | 1640  35.5% |  6.534   1h07m |    916.77    82485    n.a.%
Oct 18 15:35 | 1641  35.6% |  6.847   1h10m |    874.86    82485    n.a.%
M114969319 has a factor: 61735152791358058725319
Oct 18 15:36 | 1644  35.7% |  7.137   1h13m |    839.31    82485    n.a.%
Oct 18 15:36 | 1649  35.8% |  7.136   1h13m |    839.43    82485    n.a.%

Oct 18 16:47 | 4616  99.9% |  6.290   0m06s |    952.33    82485    n.a.%
Oct 18 16:47 | 4617 100.0% |  6.689   0m00s |    895.53    82485    n.a.%
found 1 factor for M114969319 from 2^75 to 2^76 [mfaktc 0.21 barrett76_mul32_gs]
tf(): total time spent:  1h 49m 23.377s
In that case it gave neither 100% bitlevel credit, nor 35.6% current-class credit, but 47.1568 / 66.56 = 70.85% instead of the 100% due.

In both example cases I am also using the standard default mfaktc output format.
James has offered to look into the reduced-credit-for-full-bit-level situation which I've also emailed to him.

It ought work correctly for a default mfaktc ini file, and does not, and that is both documented, and independently confirmed.

What is not documented is the asterisk you refer to; where does it go, what does such output look like, how does it differ from mfaktc default output, what custom mfaktc format would generate it, if it's necessary for proper credit why isn't it part of the default mfaktc output format, etc. EXACTLY.

Last fiddled with by kriesel on 2020-10-19 at 18:54
kriesel is online now   Reply With Quote