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
[2016-04-14 12:08:29 CEST] WIEFERICH: Range 503526600000000000 to 503526700000000000 completed
[2016-04-14 12:08:29 CEST] Total Time: 1:02:58 Total Work Units: 2 Special Results Found: 0
[2016-04-14 12:08:30 CEST] WIEFERICH: Returning work to server prpnet.primegrid.com at port 13000
[2016-04-14 12:08:30 CEST] WIEFERICH: INFO: Test for range 503526600000000000:503526700000000000 was accepted
[2016-04-14 12:08:30 CEST] WIEFERICH: INFO: All 1 test results were accepted
[2016-04-14 12:08:31 CEST] WALLSUNSUN: Getting work from server prpnet.primegrid.com at port 13001
[2016-04-14 12:08:32 CEST] WALLSUNSUN: PRPNet server is version 5.4.0
Hi! Welcome to PrimeGrid's Wall-Sun-Sun Prime Search.
Not prime: p = 190356740005303423 c10 = 50092126817982148 c11 = 82617567320012135
This implies a bug in the software.
[2016-04-14 12:08:52 CEST] : Could not open file [wwww.log] for reading. Assuming user stopped with ^C
[2016-04-14 12:08:52 CEST] Total Time: 1:03:21 Total Work Units: 2 Special Results Found: 0
[2016-04-14 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 W-S-S 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 near-square 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 Wall-Sūn-Sūn property.
/JeppeSN |
|
|
|
I removed the save file, but the problem re-occurred already on my next W-S-S:
Hi! Welcome to PrimeGrid's Wieferich Prime Search.
Searched to 503558900010866700 (100.00 done)
Primes tested 2562781123. Checksum 00000000e033b5b8. Time 2298.415016
[2016-04-14 16:11:02 CEST] WIEFERICH: Range 503558800000000000 to 503558900000000000 completed
[2016-04-14 16:11:02 CEST] Total Time: 0:38:44 Total Work Units: 1 Special Results Found: 0
[2016-04-14 16:11:02 CEST] WIEFERICH: Returning work to server prpnet.primegrid.com at port 13000
[2016-04-14 16:11:02 CEST] WIEFERICH: INFO: Test for range 503558800000000000:503558900000000000 was accepted
[2016-04-14 16:11:03 CEST] WIEFERICH: INFO: All 1 test results were accepted
[2016-04-14 16:11:03 CEST] WALLSUNSUN: Getting work from server prpnet.primegrid.com at port 13001
[2016-04-14 16:11:04 CEST] WALLSUNSUN: PRPNet server is version 5.4.0
Hi! Welcome to PrimeGrid's Wall-Sun-Sun Prime Search.
Not prime: p = 190395740002865591 c10 = 75027449115583043 c11 = 115516310808659482
This implies a bug in the software.
[2016-04-14 16:11:23 CEST] : Could not open file [wwww.log] for reading. Assuming user stopped with ^C
[2016-04-14 16:11:23 CEST] Total Time: 0:39:05 Total Work Units: 1 Special Results Found: 0
[2016-04-14 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 CPU-version of WWWW.
Using Intel(R) Core(TM) i7-3630QM 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@Nbg Volunteer moderator Volunteer tester Project scientist
 Send message
Joined: 5 Feb 08 Posts: 1188 ID: 18646 Credit: 503,272,356 RAC: 769,238
                     
|
done your test on an ubuntu-linux 64bit i7-2600K with the verbose-flag
[14.04.2016 17:56:17][sysadm@SysadmAtNbg1:~/prpclient-5.4.0a-linux_64/prpclient-2]
$ ./wwww -p190356740000000000 -P190356750000000000 -tWallSunSun -s1000 -v
wwww v1.3, a program to search for Wieferich and Wall-Sun-Sun 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: 3749*2^1555697+1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13520 ID: 53948 Credit: 241,933,287 RAC: 321,017
                          
|
I'm seeing the same thing under windows. wwww.exe produces that error while wwwwcl.exe and wwwwcl64.exe do not.
____________
My lucky number is 75898524288+1 |
|
|
rogueVolunteer developer
 Send message
Joined: 8 Sep 07 Posts: 1219 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: 1219 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: 1219 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: 769 ID: 55391 Credit: 697,713,232 RAC: 138,469
                      
|
I do not know what it means, but I note that the number mentioned is a near-square 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 = (q-p)/2
N = A^2 - D^2 = [(p+q)/2]^2 - [(q-p)/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 near-square 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 = (q-p)/2
N = A^2 - D^2 = [(p+q)/2]^2 - [(q-p)/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 (q-p) 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 "near-square" there. /JeppeSN |
|
|
|
Getting the following using wwwcl.exe with an RX 480 on windows
[2016-07-15 05:27:15 EDT] WALLSUNSUN: received [End Greeting]
[2016-07-15 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.
[2016-07-15 05:27:19 EDT] : Could not find completion line in log file [wwww.log]. Assuming user stopped with ^C
[2016-07-15 05:27:19 EDT] Total Time: 0:00:05 Total Work Units: 0 Special Results Found: 0
[2016-07-15 05:27:19 EDT] Client shutdown complete |
|
|
|
Getting the following using wwwcl.exe with an RX 480 on windows
[2016-07-15 05:27:15 EDT] WALLSUNSUN: received [End Greeting]
[2016-07-15 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.
[2016-07-15 05:27:19 EDT] : Could not find completion line in log file [wwww.log]. Assuming user stopped with ^C
[2016-07-15 05:27:19 EDT] Total Time: 0:00:05 Total Work Units: 0 Special Results Found: 0
[2016-07-15 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 always-functioning 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 CPU-only machines. |
|
|
RogerVolunteer developer Volunteer tester
 Send message
Joined: 27 Nov 11 Posts: 1137 ID: 120786 Credit: 267,649,308 RAC: 7,841
                    
|
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 |
|
|