mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Data > mersenne.ca

Reply
 
Thread Tools
Old 2016-12-17, 18:30   #1
mattmill30
 
Aug 2015

2·23 Posts
Default 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 2016-12-17 at 18:41 Reason: expanded upon the question
mattmill30 is offline   Reply With Quote
Old 2016-12-17, 18:56   #2
GP2
 
GP2's Avatar
 
Sep 2003

50318 Posts
Default

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. Consumer-grade 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 2016-12-17 at 19:00
GP2 is offline   Reply With Quote
Old 2016-12-25, 17:23   #3
mattmill30
 
Aug 2015

4610 Posts
Default

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?
mattmill30 is offline   Reply With Quote
Old 2016-12-27, 08:51   #4
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

9,787 Posts
Default

"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^p-1, 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 2016-12-27 at 08:54
LaurV is offline   Reply With Quote
Old 2016-12-27, 13:09   #5
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

9,787 Posts
Default

SM88 sent me on PM the right link (thanks!) to the "detailed" thread http://mersenneforum.org/showthread.php?t=17126
LaurV is offline   Reply With Quote
Old 2017-01-16, 01:14   #6
mattmill30
 
Aug 2015

2×23 Posts
Default

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?
mattmill30 is offline   Reply With Quote
Old 2017-01-17, 15:27   #7
thyw
 
Feb 2016
! North_America

1308 Posts
Default

Quote:
Originally Posted by mattmill30 View Post
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?
No, the "Stages" isn't changing the results, it's "only" a convinience. (AFAIK)
Essentially it's splitting the assigment for different treatments.
E.g. Separated submissions.
Whole range by ee33t1 67-72
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 2017-01-17 at 15:33
thyw is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
gpuOwL: an OpenCL program for Mersenne primality testing preda GpuOwl 2733 2021-10-13 10:39
User Xolotl has an "LL Success" NBtarheel_33 PrimeNet 11 2016-12-17 10:11
Curious about "strange" user in stats opyrt Prime Sierpinski Project 15 2009-10-15 13:06
"Optional user ID" automatically reset g0vegan PrimeNet 3 2008-11-20 03:58
Would Minimizing "iterations between results file" may reveal "is not prime" earlier? nitai1999 Software 7 2004-08-26 18:12

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


Mon Oct 25 05:50:18 UTC 2021 up 94 days, 19 mins, 0 users, load averages: 1.35, 1.07, 1.02

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.