mersenneforum.org Is there a bug in lasieve5f?
 Register FAQ Search Today's Posts Mark Forums Read

 2014-10-10, 11:05 #1 wreck     "Bo Chen" Oct 2005 Wuhan,China 22×41 Posts Is there a bug in lasieve5f? I read the progress of G3p697 every day, and it says today with Code: 7.2.42 boinc initialized work files resolved, now working -> ../../projects/escatter11.fullerton.edu_nfs/lasieve5f_1.10_x86_64-pc-linux-gnu -> -a -> -f -> 4300382000 -> -c -> 2000 -> -R -> ../../projects/escatter11.fullerton.edu_nfs/G3p697.poly -> -o -> ../../projects/escatter11.fullerton.edu_nfs/G3p697_4300382_0_0 total yield: 307, q=5416705 (8.61870 sec/rel, 100.05000 % done of 2000) called boinc_finish ]]> the url is http://escatter11.fullerton.edu/nfs/...ultid=37988006 As I understand , the q should between 4300382000 and 4300384000. Notice that 4300382000 is larger than 2^32=4294967296. Is there anybody could confirm this? May be it is only a printf error.
 2014-10-10, 11:25 #2 VictordeHolland     "Victor de Hollander" Aug 2011 the Netherlands 49816 Posts I'm no expert on this subject, but from what I can tell, this is completely normal behaviour. For big NFS jobs it's sometimes useful (even necessary??) to use LP>32bit.
 2014-10-10, 15:12 #3 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 33·73 Posts Absolutely all sievers report the current q the same way, and the last current q that is reported is a value above the upper limit (but no calculations are done for it: the for-loop was just exited because "q < q_upper" condition became false and the total yield line is printed for the last time outside the loop). The "% done" as coded recently could have been capped at 100% before printf()ing but wasn't. It doesn't matter for any intents or purposes.
2014-10-10, 17:21   #4
jyb

Aug 2005
Seattle, WA

31448 Posts

Quote:
 Originally Posted by Batalov Absolutely all sievers report the current q the same way, and the last current q that is reported is a value above the upper limit (but no calculations are done for it: the for-loop was just exited because "q < q_upper" condition became false and the total yield line is printed for the last time outside the loop). The "% done" as coded recently could have been capped at 100% before printf()ing but wasn't. It doesn't matter for any intents or purposes.
Sure, but I think his point was that the special q values should have been between 4300382000 and 4300384000, but it was reporting q=5416705, which isn't explained by pointing out that the last q reported is above the upper limit.

Wreck's supposition was correct, that the special q values being above 32 bits made the difference here. But the problem is only with the output. The printf which gives this report truncates the special q value to 32 bits (4300384001 is the first prime able 4300384000, and it is 5416705 (mod 2^32)). The code otherwise deals with special q as a 64-bit value.

 2014-10-10, 18:02 #5 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 100100001011012 Posts Ah! I thought it was % done that was the problem. ;-) Note that "% done" is one of the features that BOINC-ified binaries usually have added to them - that goes into the wrapper and shows up in progress bar in your BOINCmanager. The fact that all huge projects sieve above 2^32 is of course undisputed; we also know that the produced relations are valid (or else the previous huge projects wouldn't have finished). Right, right. Then you have to ask Greg - the BOINC-ified sievers are all his babies. You are probably right that it is 4300384001 printf'ed as %u not an %lld. And it is "2001" (4300384001-4300382000) that divided by 2000 that would have resulted in 100.05000 % Code: main(int argc,char **argv) { unsigned long long i,i1,i2,j,k,N; i = 4300384001ULL; printf("%u %lld\n", i, i); exit(0); } _________ # gcc aa.c -o aa # ./aa 5416705 4300384001 Last fiddled with by Batalov on 2014-10-10 at 18:14