20210216, 04:32  #518 
Romulan Interpreter
Jun 2011
Thailand
83·113 Posts 
Ok, so I took your list and put it in Excel, sorted it by expos from low to high, then used a concat formula to generate PrimeNet links from those exponents:
Code:
=CONCATENATE("https://www.mersenne.org/report_exponent/?exp_lo=",exponent,"&exp_hi=&full=1&ecmhist=1") Code:
Sub follow_all_links() For i = 4 To 1413 Range(Cells(i, 5), Cells(i, 5)).Select Selection.Hyperlinks(1).follow NewWindow:=False, AddHistory:=True Next End Sub Clicked them one by one , which took about 30 minutes, and looked for ranges and bitlevels, also looked for people who missed the factors, for the missed factors. All in all, it seems that TJAOI took it by themselves to raise the bitlevel for the smaller exponents, which was done most probably using mfaktc (!), as this doesn't follow the "syntax" of his "by q" reports. So, he extended:  100k to 500k to 66 bits  500k to 1M to 67 bits  1M to 3.8M to 68 bits, and after that finished, he started again from 3M to 69 bits, which is still on the way, he only found one factor of 69 bits for a low3M expo, the rest are all 68 bits  5M+ to 69 bits, all where it was the case (expos over 10M or so were all higher from the GIMPS/GPU72, TF and DCTF efforts). In this quest, he found 780 "futile" factors, in the sense that finding them took in the best case double the time to do LL, and in the worst case, about 300 times the time to do LL test. So, in all these cases, GIMPS took the right path of doing LL, there should have been no argument to go to TF. Remember that TF is worth if you can do it in (2/bitlevel) of the time you do the LL. Because, if you TF to, say, 69 bits, you will find a factor (i.e. eliminate one exponent) in about 69 TF trials, so if you can do 2 LL tests (including DC) in this time, then you better do LL. If your TF takes the same time like one LL, then you are 35 times slower. So, from this reason, the work he did was "futile", or "wasted", ignoring the fact that "having factors is nicer". However, he also found 8 "missed factors for "under 10M" exponents, which, if found at the right time, would have saved GIMPS few good weeks of work, considering the computers 2022 years ago (when these ranges were LLed). These exponents are: 6811111, 7024807, 7028183, 7043441, 7047839, 7763923, 8154967, 9371851. Between 10M and 100M, with very few exceptions, the exponents were (as said) already TFed higher, so he didn't try to raise the bitlevels, he worked "under" the line, and he found 40 missed factors in 41 exponents (the one not included is 99043661, a case where he just worked the next available bitlevel, like everybody does, and found a factor, so here he didn't "save" work, in the restricted sense, someone would have done the TF and find a factor, probably). Most of missed factors are under 59 bits (or 61 bits for larger expos) so there is no way to know who missed the factors, but for the few where the missing factor was in 6469 bits (and we can see who the "looser" was ), names we already know from the past (i.e. bad hardware, cheaters, or just unlucky guys haha) pop up regularly: KYOJI_KAMEI (4 times), 1997rj7 (twice), Amy Pond (twice), BJB (twice), bgrasman (once), anonymous crunchers (67 times). Some of the missed factors were found after the LL was done, so that's a pity, no work saved. But for the rest, TJAOI saved about 30 to 60 LLs and PRPs together, by finding missing factors of the exponents which were "ready for LL or PRP". By finding those missed factors, the long LL/PRP was avoided. (The approximation is because I didn't look exactly if there was one PRP, or one LL, or two LLs, to be done, for each exponent where a factor was found, so I just pulled the numbers out of my... sleeve). For the 100M to 108M exponents (current front) he also found a lot of factors, but these are "normal work", he took the next bitlevel, like everybody else does, and was lucky to find a factor. These do not count. I don't know if he did the lower bitlevels too, but if he did them or not, this is not mentioned in the DB (as much as I can access). There are however 2 exceptions, 104447657 and 107179573, where he reworked skipped bitlevels and found missed factors. The factor for the first of these two was missed by some user unknown to us, called "Risto A. Paju", and the second was missed by our friend axn . Now, that's interesting, I know that there was a version of mfaktc in the beginning which had a bug, causing it to miss factors if you did multiple bitlevels at once and didn't set the parameters in the ini file to do them one by one. I don't remember what version that was, because it would be interesting to retest these two exponents with it. That's because in both cases, the user did 2 and respective 3 bitlevels at once. Then I would have a reason to blame axn (I am waiting so long for that... ). Another interesting test would be to see if the actual mfakt[co] finds the respective factors when launched with different bitlevel range and internal settings related to it. I may do that in the future, just for my own peace of mind, who knows, we may uncover some unknown bug, but right now I don't have the time and the resources. Remark that in both these cases, the PRP test was saved, therefore TJAOI contribution is quite welcome, otherwise some poor soul would have wasted days (with a Rvii) or weeks (with an average CPU) to PRP them. Exponents over 108M, here we are talking a different language. Here TJAOI saved many coreyears, if not corecenturies of PRP work by finding missed factors . Of course, it is still arguable how useful that is, because unless some math or hardware revolution, I don't see GIMPS doing PRP for 800M exponents too soon... That is for the next century people to tackle it. Out grandgrandchildren... Anyhow. It would seem from this list that TJAOI only worked "under" the bitlevel line, because the remaining 571 exponents, they are missed factors, ALL of them. That's a total of 2.5 to 3 million GHzDays of PRP saved. Some factors very low, so we don't know who the "loser" was, but where we could see, the "known" names repeat again and again. There are lots of Richard and sasaki3 taking the first two "loser" places and linded coming third or so (here the positions may be different, I didn't count exactly, but these guys for sure missed a lot of factors, you may wonder if they were not some jokers), but also a nice mention and forth place for our friend Chris (Architects Cubed  to his excuse, it appears the results are quite old, so in a certain point in his agitated life, he either had a bad GPU, or he tried to game the system ). Is there any incentive to recheck the work done by these people in the range, at the time? (just asking). Last fiddled with by LaurV on 20210216 at 05:18 
20210216, 08:01  #519 
"Seth"
Apr 2019
269 Posts 
Thanks James for creating and running the query!
Thanks LaurV for the analysis. 
20210226, 09:28  #520 
"Seth"
Apr 2019
269_{10} Posts 
I've been doing P1 and ECM for some of the exponents with most factors and I'm tired of having to copy past 6+ factors for worktodo lines like this
"Pminus1=N/A,1,2,55343,1,<B1>,<B2>,0,"66411601,1538203343,3625187873,...,1427955430411051703585041" @James. If it was easy I would appreciate if mersenne.ca listed the worktodo.txt line for Pminus1 work so I could easily copy paste that line (instead of having to copy paste each factor individually)? It's a pretty niche request so totally understand if it's not easy or there's no logical place to put this. 
20210226, 12:40  #521  
"James Heinrich"
May 2004
exNorthern Ontario
3326_{10} Posts 
Quote:


20210226, 14:01  #522  
"Seth"
Apr 2019
269 Posts 
Quote:


20210226, 14:12  #523 
"James Heinrich"
May 2004
exNorthern Ontario
2·1,663 Posts 

20210226, 19:51  #524  
Dec 2016
111010_{2} Posts 
Quote:


20210226, 20:52  #525 
"James Heinrich"
May 2004
exNorthern Ontario
3326_{10} Posts 

20210227, 09:48  #526 
Romulan Interpreter
Jun 2011
Thailand
24A3_{16} Posts 
If not complicate, please allow zero for the minimum number of factors. Let the default as it is (1 to 11) but allow me to change to 0 if I want 1277 to be in the list if I request exponents from 1000 to 2000

20210227, 12:44  #527  
"James Heinrich"
May 2004
exNorthern Ontario
2·1,663 Posts 
Quote:
My page is specifically for the kind of assignments that are hard to find on PrimeNet: for exponents that have oneormore factors and are therefore no longer interesting to GIMPS.. Last fiddled with by James Heinrich on 20210227 at 12:45 

20210227, 13:25  #528 
Romulan Interpreter
Jun 2011
Thailand
9379_{10} Posts 
Nope. That's a different story. I don't want any assignments, I just want to see them. Doing this on the page you link will end me with a bunch of unwanted assignments. There is a way, but not the one you pointed. Right now, one can use factorDB, fill in 2^n1 for the range they want and filter out those which are FF. If you don't want to see the primes or those with no factor, you filter out the "P"s and "C"s, and keep only the "CF"s, which would be your current feature. As one can do that with or without "C" and "P", and with or without composite exponents too, that method is more comprehensive than your new page, but it has few main disadvantages too, first it is too slow, then fDB doesn't store (very) large expos, so it is limited to low ranges (which are the only one interesting me, anyhow, right now, for the scope of this discussion). Changing those to any type of "assignments" is as simple as a single concat formula in excel.
Last fiddled with by LaurV on 20210227 at 13:26 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Small inconsistencies between mersenne.org and mersenne.ca factor databases  GP2  mersenne.ca  44  20160619 19:29 
mersenne.ca (ex mersennearies.sili.net)  LaurV  mersenne.ca  8  20131125 21:01 
GaussianMersenne & EisensteinMersenne primes  siegert81  Math  2  20110919 17:36 
Mersenne Wiki: Improving the mersenne primes web site by FOSS methods  optim  PrimeNet  13  20040709 13:51 