20161217, 18:30  #1 
Aug 2015
2×23 Posts 
Mersenne.ca "unknown" user trustworthiness
I noticed on M9100919 has been TF'd by an unknown user between 1 and 74.
Does this seem a trustworthy result? It seems a large range to TF without any results being submitted as single ranges. Or is it likely that the user hasn't actually completed this workload? Additionally, does it seem reasonable that the exponent may only have been TF'd to 57 bits, considering the identified factors correlation to bits is: 18201839  24 bits 673468007  29 bits 2202422399  31 bits 7717579313  32 bits 494744158679  38 bits 46595048912743  45 bits 1294891132569841  50 bits 133689306506513711  56 bits 165730994575149041  57 bits Last fiddled with by mattmill30 on 20161217 at 18:41 Reason: expanded upon the question 
20161217, 18:56  #2 
Sep 2003
A1D_{16} Posts 
There are eleven known factors for M9100919, you only listed nine of them.
Two of the factors were discovered with ECM, but it seems to have had only 43 curves, at B1=50,000 (and presumably B2=5,000,000). Might be interesting for someone to do a few more. Edit: someone = me. I couldn't resist queuing it up. With TF you can't be entirely sure that the machine that did it was reliable, even if it was a known user. Consumergrade GPUs might have more errors than CPUs. In any case, it would probably be more useful to do ECM on this exponent rather than any further TF, that would rule out any more small factors faster, or find them if they exist. Last fiddled with by GP2 on 20161217 at 19:00 
20161225, 17:23  #3 
Aug 2015
101110_{2} Posts 
I only listed the factors which were identified by TF because they disprove the "no factor ^1 to ^74" TF which was reported by the unknown user.
If the full ^1 to ^74 range were completed in a single pass, rather than each increment tested individually, would the class count remaining the same  irregardless of the number of ranges being tested  reduce the efficacy of the test? Would someone be able to explain the concept of a class in TF? Why does the class not increase with each additional range tested simultaneously? 
20161227, 08:51  #4 
Romulan Interpreter
"name field"
Jun 2011
Thailand
10,273 Posts 
"class" is the modularity of k to (usually) 4620 in the expression q=2*k*p+1, where q is a factor of m=2^p1, with a prime p.
I say "usually" because other values are possible instead of 4620 (like 420, etc). Yes, the class count will be the same for every bitlevel (1 to 74) but the number of candidates doubles with every bitlevel. The candidates q are divided into classes because there are theorems which say that a factor q can not be 3 or 5 mod 8, and it is always 1 mod 2p, and we look for small prime factors. Depending on the modularity of p to 4620, to have q=2kp+1 prime and 1 mod 8 or 1 mod 8, only some values for k are possible. This eliminates many "classes" for the candidate list, making the factoring process faster. For example, a prime p>11 can not be 3 or 5 or 7 or 11 (mod 4620), because in this case it will not be prime. But it can be 1 or 13, or 17, etc, mod 4620. Say that p is 13 mod 4620. In this case q=2kp+1=26k+1 (mod 4620), and this is not prime if k=1, 7, 10, 13, 16, etc. mod 4620 (divisible by 3), it is not prime if k=4 mod 4620 (divisible by 105), it is not prime if k=11, 18, 32, mod 4620 (divisible by 7) etc.This elliminates a lot of candidates. The k value in q=2kp+1 can only be 0, 2, 3, 5, 6, 12, mod 4620, for q to have a chance to be prime. But you will also see that if k=2 mod 4620, then q=5 mod 8, and there is no way that q divides m, because all factors of m are either 1 or 7 mod 8. So, at the end, if p=13 mod 4620, then k can only be in following 960 "classes" (of modularity to 4620): 0, 3, 12, 15, 20, 23, 27, 35, 36, etc. The other 3660 "classes" are eliminated, we do not need to test them. These things were repeatedly (and deeper, with pari examples and pieces of code) explained in the mfaktc threads. Last fiddled with by LaurV on 20161227 at 08:54 
20161227, 13:09  #5 
Romulan Interpreter
"name field"
Jun 2011
Thailand
10,273 Posts 
SM88 sent me on PM the right link (thanks!) to the "detailed" thread http://mersenneforum.org/showthread.php?t=17126

20170116, 01:14  #6 
Aug 2015
2×23 Posts 
So aside from someone intentionally submitting a misleading TF report (^1 to ^74), is there a possible explanation as to why this TF test failed to identify any of the 9 factors?
e.g. if Stages=0 was set and the bitlevels ^1 to ^74 were tested simultaneously, would the efficacy of the test be diminished which could result in the factors being missed? 
20170117, 15:27  #7  
Feb 2016
! North_America
88_{10} Posts 
Quote:
Essentially it's splitting the assigment for different treatments. E.g. Separated submissions. Whole range by ee33t1 6772 E.g. without sliptting it and finding factors inside the bitranges, and StopAfterFactor isn't 0, you're not sure if the range is fully TFed or stopped before the end(?) from mfaktc.ini Code:
# Allow to split an assignment into multiple bit ranges. # 0 = disabled # 1 = enabled # Enabled Stages make only sense when StopAfterFactor is 1 or 2. # Do not change this in the middle of a run which spans over multiple # bitlevels, in this case mfaktc will ignore the checkpoint file and # restarts from the beginning. # # Default: Stages=1 # possible values for StopAfterFactor: # 0: Do not stop the current assignment after a factor was found. # 1: When a factor was found for the current assignment stop after the # current bitlevel. This makes only sense when Stages is enabled. # 2: When a factor was found for the current assignment stop after the # current class. # # Default: StopAfterFactor=2 Last fiddled with by thyw on 20170117 at 15:33 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
gpuOwL: an OpenCL program for Mersenne primality testing  preda  GpuOwl  2898  20230119 10:15 
User Xolotl has an "LL Success"  NBtarheel_33  PrimeNet  11  20161217 10:11 
Curious about "strange" user in stats  opyrt  Prime Sierpinski Project  15  20091015 13:06 
"Optional user ID" automatically reset  g0vegan  PrimeNet  3  20081120 03:58 
Would Minimizing "iterations between results file" may reveal "is not prime" earlier?  nitai1999  Software  7  20040826 18:12 