Is there a bug in lasieve5f?

[wreck]

I read the progress of G3p697 every day, and it says today with

<core_client_version>7.2.42</core_client_version>
<![CDATA[
<stderr_txt>
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

</stderr_txt>
]]>

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.

[VictordeHolland]

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.

[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.

[jyb]

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.

[Batalov]

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 %

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