Register FAQ Search Today's Posts Mark Forums Read

2022-12-06, 15:03   #2685
Serpentine Vermin Jar

Jul 2014

D3916 Posts

Quote:
 Originally Posted by Andrew Usher It's hard to believe no one has noticed, but for the past 2 weeks the contributions of TJAOI's main factor search have been categorised incorrectly. The smallest exponents are being recorded as ECM and P-1 rather than TF; as he actually does ECM (but not P-1) this is especially problematic. It seems to be PrimeNet's fault, so I am posting it here, but I claim no knowledge of why it is occurring, but it should not be. Any fix needs to be retroactive to Nov. 24 (the first day the problem occurred), so the sooner it is addressed the better.
Could you provide an example exponent I can look at? Thanks.

 2022-12-07, 00:03 #2686 Andrew Usher   Dec 2022 22·3·19 Posts If you need one to examine the non-public information, try M9891151 which has a bogus 'ECM' factor followed by a real ECM factor a week later. The problem is also easily seen when seeing the list of TJAOI submissions on 'recent results', or on mersenne.ca where I found it.
2022-12-07, 16:37   #2687
Serpentine Vermin Jar

Jul 2014

5·677 Posts

Quote:
 Originally Posted by Andrew Usher If you need one to examine the non-public information, try M9891151 which has a bogus 'ECM' factor followed by a real ECM factor a week later. The problem is also easily seen when seeing the list of TJAOI submissions on 'recent results', or on mersenne.ca where I found it.
Ah, I see. I'll defer to George for the confirmation on this, but my understanding is that, in the absence of any other info to the contrary, if a factor is found for smaller exponents (I don't remember what the threshold is), the assumption is that it was found via ECM and not TF.

TJAOI uses some custom code to find factors and are not typically assigned, so there's no information on what actual method was used to find it (ECM, TF, etc). The raw result line that was submitted is literally just this:
M9891151 has a factor: 222093838040213055689

I don't know if this answers your question or not, but I think that's all that's happening. We have no way of knowing independently how these factors were found so it's just a basic categorization based on exponent size.

Again, I'll defer to George (or James might know also) on if I'm right about that.

^^^ I just dug into the code and I'm pretty sure I followed the threads correctly and the threshold for "unknown" factors like that will assume ECM up to 16M if the # of bits in the factor is > 55. If the # of bits is <=55 then it assumes TF although honestly, I wouldn't expect we'd find any more of those.

I mean, it'd be nice if TJAOI's code would include the basic details that other clients do, like if it's doing TF, include the bits from/to, and if it's ECM include the bounds, etc. but a factor is a factor.

EDIT: While I'm at it, I'll point out that if the factor is for an exponent above 16M, there's a lookup table that sets the cutoff level between P-1 and TF based on the exponent size and the current work on where TF bit levels are at. The code will lookup the exponent, find the current set point for TF work and if the factor is below that bit length, it assumes TF, and if above, it assumes P-1 with B1=800000.

Again, this is just a basic assumption when the client didn't provide any information on how the factor was found. Primenet will guess and dump it into TF, ECM, or P-1 as a best guess.

Last fiddled with by Madpoo on 2022-12-07 at 16:50

 2022-12-08, 02:09 #2688 Andrew Usher   Dec 2022 22×3×19 Posts I could see that the categorisation was based on exponent size, but I didn't think it important because it's a problem no matter what the cause is. Again it is new, starting Nov. 24, which is why I put it in this thread. TJAOI also does ECM and 'normal' TF, and does send the usual data for those, or at least it shows up here so I assume he does. Recent examples of the former are M1704023 (before Nov. 24) and M1700173 (after); a most-recent example of the latter is M3190001 (no factor 69-70). The results of his main exhaustive search, though, are necessarily sent without data. They were consistently and correctly classified as TF before, and it has been going for 9 years and 7 million factors. Given this volume I would think it justified to have unique rules for him if necessary. The search should reach 2^68 in a year to a year and a half, and if the current rules persist there will be then something like 10,000 misclassified factors, seriously hurting the integrity of data.
2022-12-08, 03:49   #2689
Serpentine Vermin Jar

Jul 2014

5·677 Posts

Quote:
 Originally Posted by Andrew Usher I could see that the categorisation was based on exponent size, but I didn't think it important because it's a problem no matter what the cause is. Again it is new, starting Nov. 24, which is why I put it in this thread. TJAOI also does ECM and 'normal' TF, and does send the usual data for those, or at least it shows up here so I assume he does. Recent examples of the former are M1704023 (before Nov. 24) and M1700173 (after); a most-recent example of the latter is M3190001 (no factor 69-70). The results of his main exhaustive search, though, are necessarily sent without data. They were consistently and correctly classified as TF before, and it has been going for 9 years and 7 million factors. Given this volume I would think it justified to have unique rules for him if necessary. The search should reach 2^68 in a year to a year and a half, and if the current rules persist there will be then something like 10,000 misclassified factors, seriously hurting the integrity of data.
I might be wrong but I think the majority of TJAOI's ECM work is done with an actual Prime95 client (or something similar) and generates result lines like this:
Sigma=5076590238072261, B1=250000, B2=40000000.UID: TJAOI/<computer>, M1704023 has a factor: 45384828955033547860769118689 (ECM curve 40, B1=250000, B2=40000000)

While on the other hand there are also results like this that get categorized as ECM just because of the exponent size:
M1700173 has a factor: 21625696793728370834753

What you're suggesting is that you think TJAOI's results that don't specifically say ECM are actually TF? I just wonder on what you base that assumption... I mean, you might have info I don't (I don't know who TJAOI is or what program(s) they use) or it's been discussed elsewhere on the forum.

As far as being correctly classified as TF previously, were those also smaller exponents as well, under 16M? Or is this just a case of TJAOI recently getting back into sub 16M exponents and doing additional TF work?

Let me provide a counter argument... there are also recent results of theirs that look like this:
M13142747 has a factor: 219733566685284169823 (TF:67-68)

It's below 16M but it clearly specifies the TF bit range so it's classified as TF, not ECM.

Maybe what you see is actually a change in the program TJAOI uses where it's no longer sending that TF:xx-xx info? I guess you'd have to ask them. The server works with the data it gets...

EDIT: It does look results after Nov 23rd no longer have a TF range. But at the same time, it's not possible to blanket assume that results that look like this are results of TF work:
M616181 has a factor: 164860426011387836137182710616911

That's a 108 bit factor so I think it's safe to say it's ECM, especially on M616181, or I guess it could be P-1? Or it's a result of feeding primes into whatever massive sieve algorithm and see what exponents are a hit for it. :) That's an extreme case, but what if one was found that happened to be around 67-68 bits. I don't think it's a safe assumption unless we hear from TJAOI themselves and get some clarification, but that's just me.

Last fiddled with by Madpoo on 2022-12-08 at 04:03

 2022-12-08, 05:26 #2690 Andrew Usher   Dec 2022 22·3·19 Posts It has indeed been discussed at length on this forum: https://www.mersenneforum.org/showthread.php?t=19014 - also, I could have deduced it myself from the pattern of factors. If he's stopped sending bit levels for his main search, it may be an attempt to be more accurate, since it doesn't use bit levels. What he does is test every prime +/- 1 mod 8, in increasing order, to see if it divides a Mersenne (presumably factoring p-1) and any new factors of one <1G get sent in. He started this 9 years ago from zero and has been sending results across the entire range of exponents ever since; except for one early glitch he's never missed a factor. However, nowadays the exponents <2M don't see any because, thanks to TJAOI himself, they've all been taken to ECM t25 or better. So, of his factors without a bit level, any that fit in this increasing sequence are (beyond reasonable doubt) TF, while any larger are ECM (he does no P-1). A cutoff even as high as 2^68 would almost always be correct until his search gets there, and would count as a fix (recording a small ECM factor as TF is anyway much less serious than the reverse). To my knowledge no one has been able to communicate with TJAOI at all; I imagine George would know for sure.
2022-12-08, 06:22   #2691
Serpentine Vermin Jar

Jul 2014

1101001110012 Posts

Quote:
 Originally Posted by Andrew Usher It has indeed been discussed at length on this forum: https://www.mersenneforum.org/showthread.php?t=19014 - also, I could have deduced it myself from the pattern of factors. If he's stopped sending bit levels for his main search, it may be an attempt to be more accurate, since it doesn't use bit levels. What he does is test every prime +/- 1 mod 8, in increasing order, to see if it divides a Mersenne (presumably factoring p-1) and any new factors of one <1G get sent in. He started this 9 years ago from zero and has been sending results across the entire range of exponents ever since; except for one early glitch he's never missed a factor. However, nowadays the exponents <2M don't see any because, thanks to TJAOI himself, they've all been taken to ECM t25 or better. So, of his factors without a bit level, any that fit in this increasing sequence are (beyond reasonable doubt) TF, while any larger are ECM (he does no P-1). A cutoff even as high as 2^68 would almost always be correct until his search gets there, and would count as a fix (recording a small ECM factor as TF is anyway much less serious than the reverse). To my knowledge no one has been able to communicate with TJAOI at all; I imagine George would know for sure.
I'll have to leave it to George to decide how to handle those exponents then. I'm not up to speed on the math behind it or why it would matter.

I haven't really kept up on the forum thread discussing those results so I don't know how much was known about the work involved, or how it was determined the method used to find those factors. Whatever the case, it's cool that they're doing all that work. George might be able to contact the user and find out about the missing TF bit level info.

 2022-12-08, 13:54 #2692 Andrew Usher   Dec 2022 E416 Posts If you can do so quickly, go ahead. The factors will keep piling up. It seems the best single place to see the problem and the solution is https://www.mersenne.ca/userfactors/ecm/recent/bits and page down.
2022-12-08, 21:15   #2693
Serpentine Vermin Jar

Jul 2014

5×677 Posts

Quote:
 Originally Posted by Andrew Usher If you can do so quickly, go ahead. The factors will keep piling up. It seems the best single place to see the problem and the solution is https://www.mersenne.ca/userfactors/ecm/recent/bits and page down.
George just took care of it on the Primenet server. James will need to make any corrective changes on his mersenne.ca site (he's been cc'd on that as well).

 2022-12-09, 02:32 #2694 ATH Einyen     Dec 2003 Denmark 343910 Posts In the new table the lines with any LL ERR has the wrong sum (it is correct in the old version). It is the "NO-LL" column that is wrong in the new version: Code:  Start Count P | F DC |LL/PRP ERR NO-LL 112000000 54004 34922 8385 1150 1 9545 https://www.mersenne.org/primenet/ 112000000 54004 | 34922 8385 1150 1 9546 https://www.mersenne.org/sp_report_primenet_gimps_summary.txt 115000000 53913 34889 2487 174 3 16357 https://www.mersenne.org/primenet/ 115000000 53913 | 34889 2487 174 3 16360 https://www.mersenne.org/sp_report_primenet_gimps_summary.txt 131000000 53484 33177 15 187 7 20091 https://www.mersenne.org/primenet/ 131000000 53484 | 33177 15 187 7 20098 https://www.mersenne.org/sp_report_primenet_gimps_summary.txt 150000000 52996 32678 8 12 1 20296 https://www.mersenne.org/primenet/ 150000000 52996 | 32678 8 12 1 20297 https://www.mersenne.org/sp_report_primenet_gimps_summary.txt Last fiddled with by ATH on 2022-12-09 at 02:33
2022-12-09, 03:10   #2695
Serpentine Vermin Jar

Jul 2014

5·677 Posts

Quote:
 Originally Posted by ATH In the new table the lines with any LL ERR has the wrong sum (it is correct in the old version). It is the "NO-LL" column that is wrong in the new version...
I'm not surprised. I re-did how it's calculated and that part did have me confused. I wasn't sure if an error/suspect result should count as "untested" or not. I should have looked closer at some of the rows that had an example to look at.

I'll check on that again and try to get it fixed up soon, but it may not happen right away.

 Similar Threads Thread Thread Starter Forum Replies Last Post ewmayer Lounge 39 2015-05-19 01:08 ewmayer Science & Technology 41 2014-04-16 11:54 cheesehead Soap Box 56 2013-06-29 01:42 cheesehead Soap Box 61 2013-06-11 04:30 Dubslow Programming 19 2012-05-31 17:49

All times are UTC. The time now is 05:52.

Tue Feb 7 05:52:19 UTC 2023 up 173 days, 3:20, 1 user, load averages: 1.22, 1.04, 1.02