20170124, 17:00  #34  
Romulan Interpreter
Jun 2011
Thailand
2^{3}·29·37 Posts 
Quote:
busted! You totally got me here... One more proof that the typos are cleverer than us... They squeeze themselves in the most unexpected places, to produce maximum damages... Last fiddled with by LaurV on 20170124 at 17:02 

20170127, 06:42  #35  
May 2007
Kansas; USA
2^{2}×2,539 Posts 
Quote:
If the project loses some people as a result of this exchange between Mark and me then so be it. He and I have had words before about a lack of parallel testing of changes to PRPnet, PFGW, and srsieve that have created many problems for the project. I have never seen a good parallel test done on any changes that are made. It is intolerable in a very exacting project that software updates are introduced without proper testing procedures. As I stated in my last post, if correct parallel testing vs. a known correct version of srsieve cannot be demonstrated then CRUS will refuse to accept any new work with the new program. If other projects want to run their efforts on an improperly tested program that is their choice but it is not ours. Last fiddled with by gd_barnes on 20170127 at 06:59 

20170127, 06:56  #36  
May 2007
Kansas; USA
23654_{8} Posts 
Quote:
Oh...and as you can tell...I will definitely be the man to criticize improper changes. They used to call me the code breaker at my legacy programming job. My main job was to create tests that broke programs. That is why I get so irritated at a lack of test plans on these code changes. 

20170127, 08:10  #37  
May 2007
Kansas; USA
10011110101100_{2} Posts 
Quote:
I ran a couple of parallel tests on forms with no algebraic factors. No differences were found. But many more parallel tests are needed. I then ran the form 8*86^n+1 for n=1 to 100e3 to P=100e6. This was the very first test that I ran of a form with algebraic factors. On the command line window it showed: Code:
Removed 33333 algebraic factors for 8*86^n+1 as 8=2^3 Removed 33334 algebraic factors for 8*86^n+1 as 8*86^6=14792^3 Code:
(2*86^33330+1)  8*86^99990+1 (2*86^33331+1)  8*86^99993+1 (2*86^33332+1)  8*86^99996+1 (2*86^33333+1)  8*86^99999+1 (14792*86^1431655763+1)  8*86^1+1 (14792*86^1431655764+1)  8*86^4+1 (14792*86^0+1)  8*86^7+1 (14792*86^1+1)  8*86^10+1 (14792*86^2+1)  8*86^13+1 (14792*86^3+1)  8*86^16+1 (14792*86^4+1)  8*86^19+1 (14792*86^5+1)  8*86^22+1 Checking in the factordb confirmed that none of these "14792*86^n+1" factors is correct. It showed that the factor of 14792*86^n+1 is actually a factor of 8*86^(3n+6)+1 meaning that the factor of 14792*86^n+1 is nothing more than an elaborate form of 8*86^(3n)+1. In other words 14792*86^n+1 should only remove n==(0 mod 3) but that is already removed by 8*86^(3n)+1 so...14792*86^n+1 is not something that should even be considered. Second problem: 14792*86^1431655763+1 is obviously not a factor of 8*86^1+1. Serious display problem there. I then ran 8*86^n+1 with my favorite old known bugfree version of srsieve. Of course it left quite a few "bad" pairs that are n==(0 mod 3) but it left FAR more "good" pairs that are n==(1 mod 3) in the file. Mark, I think the code needs a whole lot of work and testing. This is the kind of problem that caused the program to incorrectly remove many good k/n pairs before when you were working on removing the algebraic factors for squares. I hope this demonstrates why I am so frustrated with the lack of testing. As a project admin I should not have to test every program change that comes our way but it looks like I have no choice. In this case even if you fix this problem I can't help but wonder how many other problems like this that there are in the code. An extensive test plan is needed to test every change that you made in multiple ways. Last fiddled with by gd_barnes on 20170127 at 08:45 

20170127, 13:48  #38 
"Mark"
Apr 2003
Between here and the
5,807 Posts 
I ran a number of tests, especially ones pointed out by Serge, but it is not possible for me to test every possible combination. If someone will provide a list of k*b^n+c for me to test with, I will gladly do so.
As I stated previously a quick verification of the algebraic factors can be done by running algebraic.log thru pfgw. BTW, this was caused by an underflow, i.e. an unsigned value that went below 0. Last fiddled with by rogue on 20170127 at 14:43 
20170129, 07:51  #39  
May 2007
Kansas; USA
2^{2}×2,539 Posts 
Quote:
It doesn't require that you test every possible combination. Just a very basic test would have caught these problems. That was the very first simple algebraic test that I tested after running a couple of parallel tests for bases without algebraic factors. Nothing needs to be run through anything to see that 14792*86^n+1 does not remove n==(1 mod 3) from 8*86^n+1. 14792=86^3 so it is just another form of k=q^3, which removes n==(0 mod 3). Surely this is obvious to you. 14792*86^n+1 should not even be considered because 8*86^(3n)+1 already has 2*86^n+1 has a factor, which removes n==(0 mod 3). The 1st and main problem is that it is removing all n==(1 mod 3). Take a look at what I posted and see for yourself. Of course the display issue in the algebraic factors files is an underflow problem. The display issue is the 2nd problem that I pointed out. There is no reason for me or anyone else to test anything else when such a blatant error exists in the code. n==(0 mod 3) should be removed. n==(1 mod 3) should not. I suggest that you test 8*86^n+1 and post a new program when these two problems for this one test have been fixed. No one here will trust your code if it can't pass such a simple test. k=q^3 is one of the easiest cases. Last fiddled with by gd_barnes on 20170129 at 08:12 

20170130, 00:34  #40 
"Mark"
Apr 2003
Between here and the
5807_{10} Posts 
Ok. I've taken the new routines and compiled them outside of srsieve and ran thru k from 1 to 1050 and b from 2 to 1050 and n from 1 to k + 10 for both +1 and 1 forms. It pumped out over 43e6 algebraic factors that I used pfgw to verify. This revealed three bugs which should now be fixed (presuming I patched sriseve correctly). The source and executable have been posted.

20170131, 10:28  #41 
May 2007
Kansas; USA
2^{2}·2,539 Posts 
Sounds like a lot of good testing.
Features on GFN's: 1. Do we really want to completely remove GFN's from sieving? Some people may want to sieve for them. I realize that srsieve is not the best siever for them but completely removing GFN's gives the impression that they are always composite, which is not the case. My suggestion is to remove your code for GFN's and let the program sieve them like it always has. 2. It did not write anything to algebraic.log about the removal of the GFN. Should it be doing that? So far I've tried a lot of different powers including k's with multiple powers (such as k=2^30) and it looks good. I still have plenty of parallel testing to go. Last fiddled with by gd_barnes on 20170131 at 11:16 
20170131, 10:40  #42 
May 2007
Kansas; USA
10156_{10} Posts 
Some bugs:
1. It continues trying to sieve a sequence even if all terms have been removed and it doesn't seem to go very fast even though no terms remain. The same problem occurs for both algebraic factors and GFNs. When finished it just writes a file with the standard header line and nothing else. This could result in quite a bit of extra CPU time if the sieve depth is deep. Examples: 8*1000^n+1 or 10*1000^n+1. 2. It crashes every time I try to feed it an already sieved file. Old srsieve had no problem with this. I even tried random sieve files with no algebraic factors and it still crashed. We need to be able to feed it our existing sieve files and have it remove algebraic factors for us. Also for other projects such as repeatdigit sequences where c not = 1 or 1 neither sr1sieve nor sr2sieve can be used for additional sieving. Example sieve file: http://www.noprimeleftbehind.net/cru...100K400K.txt Question: If we're doing this, shouldn't we go all the way with it? I think that others have made that statement in this thread. Why are only c=1 and 1 being considered for algebraic factors? For example srsieve can easily sieve 4*6^n121. 4*6^(2n)121 factors to (2*6^n11)*(2^6^n+11) so all even n should be removed but since c>1 and c<1 are not being considered that is not the case. This will be a tremendous effort to get completely correct. I'm still not in favor of it. You seem to think that the code changes will be easy but they never are. Serge already found one bug, I have now found 3 bugs (1 previously and 2 now), and you found 3 more bugs. That's 7 bugs already and I'm just getting started on testing. When I look at all of the multiple srsieve version changes that were previously made for just removing squares it makes me cringe trying to do this. We have to comprehensively test this before an official version is posted. Last fiddled with by gd_barnes on 20170131 at 11:57 
20170131, 14:15  #43  
"Mark"
Apr 2003
Between here and the
5,807 Posts 
Quote:


20170131, 14:24  #44  
"Mark"
Apr 2003
Between here and the
5,807 Posts 
Quote:
I do not know how I introduced #2, because the changes are for new sequences only. As to your last question, I hadn't considered supporting abs(c) != 1. Let me work out the other issues before I do that. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
RSP Sieve Files for k*2^n1 from PrimeGrid  pinhodecarlos  Riesel Prime Search  90  20200711 15:38 
Generalizing algebraic factors on Riesel bases  gd_barnes  Conjectures 'R Us  31  20100406 02:04 
Constructing a sieve for trial factors  davieddy  Math  48  20090707 19:42 
program to verify factors found by sr(x)sieve?  mdettweiler  Software  16  20090308 02:06 
Algebraic factors  henryzz  ElevenSmooth  13  20071218 09:12 