Author 
Message 

What do you make of this:
i! Welcome to PrimeGrid's Wieferich Prime Search.
Searched to 503526700010213880 (100.00 done)
Primes tested 2562843580. Checksum 00000000ad9dd6e0. Time 2376.860668
[20160414 12:08:29 CEST] WIEFERICH: Range 503526600000000000 to 503526700000000000 completed
[20160414 12:08:29 CEST] Total Time: 1:02:58 Total Work Units: 2 Special Results Found: 0
[20160414 12:08:30 CEST] WIEFERICH: Returning work to server prpnet.primegrid.com at port 13000
[20160414 12:08:30 CEST] WIEFERICH: INFO: Test for range 503526600000000000:503526700000000000 was accepted
[20160414 12:08:30 CEST] WIEFERICH: INFO: All 1 test results were accepted
[20160414 12:08:31 CEST] WALLSUNSUN: Getting work from server prpnet.primegrid.com at port 13001
[20160414 12:08:32 CEST] WALLSUNSUN: PRPNet server is version 5.4.0
Hi! Welcome to PrimeGrid's WallSunSun Prime Search.
Not prime: p = 190356740005303423 c10 = 50092126817982148 c11 = 82617567320012135
This implies a bug in the software.
[20160414 12:08:52 CEST] : Could not open file [wwww.log] for reading. Assuming user stopped with ^C
[20160414 12:08:52 CEST] Total Time: 1:03:21 Total Work Units: 2 Special Results Found: 0
[20160414 12:08:52 CEST] Client shutdown complete
I suppose I just remove "work_WALLSUNSUN.save" and get to work again? Or is the file of interest to anyone?
Latest PRPNet client, MacOSX 10.11.4, CPU version
(Although we're talking a MacBook Pro, I don't think this has to do with overheating. I use only 1 of 4 cores.)




Oh, and I should have said this: I have finished at least 50 WSS and 50 WF tasks on this machine before.




I've had this happen before and removed the .save file and the wwww.log file and restarted the sieve program. You apparently stopped work at some point but it did know to send one completed unit.
Cheers Rick 



I do not know what it means, but I note that the number mentioned is a nearsquare semiprime:
190356740005303423 = 436274273 * 436323551
= (436298912  24639) * (436298912 + 24639)
= 436298912^2  24639^2
Since it is a composite number, it should have been sieved away and not have been tested for the WallSūnSūn property.
/JeppeSN 



I removed the save file, but the problem reoccurred already on my next WSS:
Hi! Welcome to PrimeGrid's Wieferich Prime Search.
Searched to 503558900010866700 (100.00 done)
Primes tested 2562781123. Checksum 00000000e033b5b8. Time 2298.415016
[20160414 16:11:02 CEST] WIEFERICH: Range 503558800000000000 to 503558900000000000 completed
[20160414 16:11:02 CEST] Total Time: 0:38:44 Total Work Units: 1 Special Results Found: 0
[20160414 16:11:02 CEST] WIEFERICH: Returning work to server prpnet.primegrid.com at port 13000
[20160414 16:11:02 CEST] WIEFERICH: INFO: Test for range 503558800000000000:503558900000000000 was accepted
[20160414 16:11:03 CEST] WIEFERICH: INFO: All 1 test results were accepted
[20160414 16:11:03 CEST] WALLSUNSUN: Getting work from server prpnet.primegrid.com at port 13001
[20160414 16:11:04 CEST] WALLSUNSUN: PRPNet server is version 5.4.0
Hi! Welcome to PrimeGrid's WallSunSun Prime Search.
Not prime: p = 190395740002865591 c10 = 75027449115583043 c11 = 115516310808659482
This implies a bug in the software.
[20160414 16:11:23 CEST] : Could not open file [wwww.log] for reading. Assuming user stopped with ^C
[20160414 16:11:23 CEST] Total Time: 0:39:05 Total Work Units: 1 Special Results Found: 0
[20160414 16:11:23 CEST] Client shutdown complete




The number 190395740002865591 has properties similar to those of 190356740005303423 which I just described. I.e. it is a composite number, although a semiprime, and the two prime factors are quite close to each other. /JeppeSN 



The problem is reproducible from the command line! Saying:
.\wwww.exe p190356740000000000 P190356750000000000 tWallSunSun s1000
gives:
Not prime: p = 190356740005303423 c10 = 50092126817982148 c11 = 82617567320012135
This implies a bug in the software.
It does look like a bug in the CPUversion of WWWW.
Using Intel(R) Core(TM) i73630QM CPU @ 2.40GHZ under Windows 8.1.
/JeppeSN
Addition (edit): To me it seems like we have reached a region where every WSS work unit will fail under the CPU program. Can anyone disprove that hypothesis? 


Sysadm@NbgVolunteer moderator Volunteer tester Project scientist
Send message
Joined: 5 Feb 08 Posts: 1127 ID: 18646 Credit: 369,776,087 RAC: 385,597

done your test on an ubuntulinux 64bit i72600K with the verboseflag
[14.04.2016 17:56:17][sysadm@SysadmAtNbg1:~/prpclient5.4.0alinux_64/prpclient2]
$ ./wwww p190356740000000000 P190356750000000000 tWallSunSun s1000 v
wwww v1.3, a program to search for Wieferich and WallSunSun primes.
Searching for WallSunSun primes between 190356740000000000 and 190356750000000000.
The largest prime in the sieve is 436298977 (using 23164636 primes) using
approximately 115104 KB of memory.
Not prime: p = 190356740005303423 c10 = 50092126817982148 c11 = 82617567320012135
This implies a bug in the software.
____________
Sysadm@Nbg
my current lucky number: 3299*2^1441747+1
PSAPRPNetStatsURL: http://ugf.de/PRPNet/



Michael GoetzVolunteer moderator Project administrator Project scientist
Send message
Joined: 21 Jan 10 Posts: 10745 ID: 53948 Credit: 127,937,747 RAC: 116,091

I'm seeing the same thing under windows. wwww.exe produces that error while wwwwcl.exe and wwwwcl64.exe do not.
____________
Please do not PM me with support questions. They will usually go unanswered. Ask on the forums instead. Thank you!
My lucky number is 75898^524288+1 


rogueVolunteer developer
Send message
Joined: 8 Sep 07 Posts: 1150 ID: 12001 Credit: 18,565,548 RAC: 0

The sieving code in wwwwlikely has a bug. I would have to modify the source to use the same sieving code that is used by wwwwcl. 



The sieving code in wwwwlikely has a bug. I would have to modify the source to use the same sieving code that is used by wwwwcl.
Thank you. Does this require a new client?
I'm having the same issue on two Win7 machines which have been successfully running these tasks on CPU's for years.
____________
Warped



rogueVolunteer developer
Send message
Joined: 8 Sep 07 Posts: 1150 ID: 12001 Credit: 18,565,548 RAC: 0

Just an updated wwww.exe.
Is there any reason you can't run the GPU version? 



Thanks for the clarification. Will you let us know if and when such an updated binary becomes available?
I can't wait to... find the first WSS prime I guess :)
And no, this computer does not have a GPU that I can use for this purpose. 


rogueVolunteer developer
Send message
Joined: 8 Sep 07 Posts: 1150 ID: 12001 Credit: 18,565,548 RAC: 0

I can make no promises to fixing the code anytime soon. Someone else with some software expertise could do it. 


compositeVolunteer tester Send message
Joined: 16 Feb 10 Posts: 562 ID: 55391 Credit: 408,869,082 RAC: 605,528

I do not know what it means, but I note that the number mentioned is a nearsquare semiprime:
190356740005303423 = 436274273 * 436323551
= (436298912  24639) * (436298912 + 24639)
= 436298912^2  24639^2
/JeppeSN
All odd semiprimes can be expressed as the difference of squares of the average of the 2 odd primes and half the difference of the 2 odd primes. The square terms in the expansion cancel out, leaving the semiprime as the sum of the remaining terms.
N = pq
A = (p+q)/2
D = (qp)/2
N = A^2  D^2 = [(p+q)/2]^2  [(qp)/2]^2 = (p^2/4 + pq/2 + q^2/4)  (p^2/4  pq/2 + q^2/4) = pq




I do not know what it means, but I note that the number mentioned is a nearsquare semiprime:
190356740005303423 = 436274273 * 436323551
= (436298912  24639) * (436298912 + 24639)
= 436298912^2  24639^2
/JeppeSN
All odd semiprimes can be expressed as the difference of squares of the average of the 2 odd primes and half the difference of the 2 odd primes. The square terms in the expansion cancel out, leaving the semiprime as the sum of the remaining terms.
N = pq
A = (p+q)/2
D = (qp)/2
N = A^2  D^2 = [(p+q)/2]^2  [(qp)/2]^2 = (p^2/4 + pq/2 + q^2/4)  (p^2/4  pq/2 + q^2/4) = pq
Sure, this elementary trick works every time you have a quantity written as a product of two whole numbers with the same parity. For odd N you can actually consider N=1*N (also works if N is prime) and realize that the odd numbers are the differences of consecutive perfect squares. So the only part of my post that was really interesting, was that (qp) seems to be quite small compared to either p or q in all of the cases where I saw WWWW failing (by including a composite candidate N). That is what I meant by the loose term "nearsquare" there. /JeppeSN 



Getting the following using wwwcl.exe with an RX 480 on windows
[20160715 05:27:15 EDT] WALLSUNSUN: received [End Greeting]
[20160715 05:27:15 EDT] WALLSUNSUN: closing socket
wwwwcl v2.2.5, a GPU program to search for Wieferich and WallSunSun primes
Sieve started: (cmdline) 209642090000000000 <= p < 209642100000000000
Fatal Error: Not prime: p = 209642095000000129 c10 = 6286 c11 = 23123. The code must have a bug.
Fatal Error: Not prime: p = 209642095001473153 c10 = 19839 c11 = 25000. The code must have a bug.
[20160715 05:27:19 EDT] : Could not find completion line in log file [wwww.log]. Assuming user stopped with ^C
[20160715 05:27:19 EDT] Total Time: 0:00:05 Total Work Units: 0 Special Results Found: 0
[20160715 05:27:19 EDT] Client shutdown complete 



Getting the following using wwwcl.exe with an RX 480 on windows
[20160715 05:27:15 EDT] WALLSUNSUN: received [End Greeting]
[20160715 05:27:15 EDT] WALLSUNSUN: closing socket
wwwwcl v2.2.5, a GPU program to search for Wieferich and WallSunSun primes
Sieve started: (cmdline) 209642090000000000 <= p < 209642100000000000
Fatal Error: Not prime: p = 209642095000000129 c10 = 6286 c11 = 23123. The code must have a bug.
Fatal Error: Not prime: p = 209642095001473153 c10 = 19839 c11 = 25000. The code must have a bug.
[20160715 05:27:19 EDT] : Could not find completion line in log file [wwww.log]. Assuming user stopped with ^C
[20160715 05:27:19 EDT] Total Time: 0:00:05 Total Work Units: 0 Special Results Found: 0
[20160715 05:27:19 EDT] Client shutdown complete
AMD gpus no longer work on wwwwcl (at least in Windows) due to driver changes in 2015. 14.12 is the last alwaysfunctioning driver that I've found, which is sadly too old for your new 480. Win 10 is right out.
As soon as I can get a 1070 near MSRP or a cheap used 970, I'll be pulling my 7950s and going all NV. Wish I didn't have to, but that's where the performance, efficiency and compatibility seem to lie nowadays.
____________
Eating more cheese on Thursdays. 



The sieving code in wwwwlikely has a bug. I would have to modify the source to use the same sieving code that is used by wwwwcl.
Thought about this again.
Given the text output from Sysadm@Nbg's post above, maybe the sieve simply does trial divisions by all primes 3, 5, 7, 11, ..., 436298977? I have verified that there are indeed exactly 23164636 such primes (not counting the even prime 2).
Then, this successfully sieves away all composite numbers as long as our range lies below 436298977^2, or approx. 19035679e10.
However, as soon as we go beyond that, some composite numbers all (both) of whose prime factors exceed 436298977, will occur, and they are not stopped by the sieve.
This appears to explain the numbers in the error messages we saw.
So maybe to fix the "bug", simply make the list of primes for trial division longer? That seems simple enough.
/JeppeSN 



I, too, hope for a quick resolution here.
I'd love to go back to alternating between WSS and WF work units on my CPUonly machines. 


RogerVolunteer moderator Project administrator Volunteer developer Volunteer tester Project scientist
Send message
Joined: 27 Nov 11 Posts: 984 ID: 120786 Credit: 217,209,271 RAC: 229,443

Anyone knows where the CPU wwww.exe source code lives?
I have the GPU wwwwcl.exe source code. 



Anyone knows where the CPU wwww.exe source code lives?
I have the GPU wwwwcl.exe source code.
Maybe somewhere on this page? Just a guess.
https://sourceforge.net/p/prpnet/code/HEAD/tree/source/
____________




Me:
The sieving code in wwwwlikely has a bug. I would have to modify the source to use the same sieving code that is used by wwwwcl.
So maybe to fix the "bug", simply make the list of primes for trial division longer? That seems simple enough.
OK, that was silly of me. Certainly the output from Sysadm@Nbg shows that the CPU app wwww had chosen this list of primes in a way such that all primes not exceeding the square root of pmax (the upper endpoint of the range to test) were included. It is easy to verify that the largest prime (as displayed with the verbose option) is picked (correctly it seems) based on pmax.
In Sysadm@Nbg's example we had the range:
between 190356740000000000 and 190356750000000000
and the square root of the upper bound is sqrt(190356750000000000)=436298922.76. The preceding prime is 436'298'921, and the next prime is 436'298'959. Wwww chose a larger prime, 436,298,977, which should be fine.
The error:
Not prime: p = 190356740005303423 ...
But 190356740005303423 = 436274273*436323551, so of course the smaller (left factor) prime is small enough that this composite p value should have been sieved away. In other words, my naive hypothesis was wrong. I can only agree, there is some bug in the sieve.
/JeppeSN 

