mersenne.ca

[James Heinrich]

Originally Posted by Ensigm

Minimal TF effort aka "min. TF" as shown in the factor entry seems to be quite different from the efforts shown in the TF history entry. For example, for M113317913 the "min. TF" shows 8.4409 GHz.d, whereas the total effort up to 2⁷³ is already roughly 8.4409*2, and the TF effort in 73-74 bits is greater than 8.4409GHz-days too, considering the fact that the factor is close to 2^74. This couldn't be correct, unless the GHz-days in the factor entry and in the TF history are calibrated differently (which is also confusing).

Thanks for bringing this to my attention. The "Min. TF Effort" under the Known Factors section was being calculated incorrectly. In this particular example it was previously displaying 8.44 when it should be 30.22

[Viliam Furik]

I have tried to use the tool with these search parameters:

4,000,000 - 4,999,999; Probability 0 - 10 %; Order by probability

It returns an empty table, but it shouldn't. M4087873 is listed with 2.799 % probability, meaning it should appear in the table.

If I understand the working of the tool correctly, it should return lots of exponents. If I don't, please correct me.

[James Heinrich]

Originally Posted by Viliam Furik

I have tried to use the tool with these search parameters:
4,000,000 - 4,999,999; Probability 0 - 10 %; Order by probability
It returns an empty table, but it shouldn't. M4087873 is listed with 2.799 % probability, meaning it should appear in the table.

Thanks, there was a bug that prevented some exponents from appearing when they should.

[Ensigm]

Originally Posted by James Heinrich

Thanks, there was a bug that prevented some exponents from appearing when they should.

There might also be a bug with LL status. If you search with parameters 4e7-5e7, 0%-10%, 1 test, more than 500 results will show up, however all exponents under 5e7 are already double-checked.

[James Heinrich]

Originally Posted by Ensigm

There might also be a bug with LL status.

No bug, I just don't have reliable access to that data.

[masser]

Please see the screen shot: almost every other row has strange output.

Before anyone asks, I was considering the estimate of successful trial factoring (1/bit-level) vs. the anecdotal estimate (1/100). If someone were to do tiny amounts of P-1, only reporting the factors found, could that be enough to reduce the odds of successful trial-factoring to the supposedly observed result?

[James Heinrich]

Originally Posted by masser

Please see the screen shot: almost every other row has strange output.

"You're not using it right"
The calculation iterates through many combinations of bounds, at each step aiming to get a bit closer at the next iteration. This works well when the process starts reasonably near the optimal bounds, it (as you can see) works very poorly (in the current implementation) when you start with bounds for ~5% and try to aim for 0.33%. I'll have to play with it and see what I can figure out. Thanks for reporting.

[Ensigm]

Originally Posted by masser

Before anyone asks, I was considering the estimate of successful trial factoring (1/bit-level) vs. the anecdotal estimate (1/100). If someone were to do tiny amounts of P-1, only reporting the factors found, could that be enough to reduce the odds of successful trial-factoring to the supposedly observed result?

"You're not doing it right"

A tiny P-1 of (B1, B2)=(9500, 143000) has a 0.33% prior possibility of finding a factor of 105000001 that is larger than 2⁷⁶ , according to the same tool you were using. However, to reduce the trial factoring success rate of the next bit level by 0.33% (or 0.3%), you need a P-1 run that has a prior probability of 0.33% (or 0.3%) to find a factor from 2⁷⁶ to 2⁷⁷. A P-1 run of (B1, B2)=(450368, 11259212) has a 3.22%-2.91%=0.31% probability of finding a factor in that bit range. It costs 6 GHz-days, which is quite close to a "normal" P-1, not a "tiny" one.

Conclusion: Based on calculations provided by mersenne.ca P-1 probability tool, unreported tiny P-1 runs may play a factor (no pun intended) in the phenomenon of observed TF success rate being short of prediction, but they are very unlikely to be the main reason.

[gLauss]

M20825573 does not show my (unnecessary) PRP run, which I reported a few days ago. There seems to be a bug. Please compare the output of mersenne.ca with mersenne.org.

[Uncwilly]

Originally Posted by gLauss

M20825573 does not show my (unnecessary) PRP run, which I reported a few days ago. There seems to be a bug. Please compare the output of mersenne.ca with mersenne.org.

I can see it. It is in the table below the LL details.

[gLauss]

Originally Posted by Uncwilly

I can see it. It is in the table below the LL details.

Yes, but it doesn't show up on the top right in "Latest Primenet details". It isn't important, but to me it looks like a bug. And I assume there are not many numbers which have both LL/DC and PRP, so it could be an interesting edge case.