[VA] SRC #013 - Pi Day 2023 Special

[Valentin Albillo]

.
Hi, J-F and DavidM,

(03-27-2023 03:48 PM)J-F Garnier Wrote:  

(03-27-2023 02:28 PM)DavidM Wrote:  I hadn't noticed that the final Count value I listed in the table in post #22 was a bit off until Valentin sent me a note about it. We both assumed a typo, but it turns out not to be. The program I posted definitely produces the Count value specified for an input of 999,999,999,999 [...]

I didn't notice this discrepancy !
However ... running Valentin's 2nd solution also returns the same wrong value:

1 DESTROY ALL @ INPUT T @ SETTIME 0 @ U=-1 @ S=T @ FOR K=2 TO SQR(T) @ N=K @ F=1
2 D=PRIM(N) @ IF NOT D THEN S=S+U^F*IP(T/(K*K)) ELSE IF MOD(N,D*D) THEN F=F+1 @ N=N/D @ GOTO 2
3 NEXT K @ DISP USING "2(3DC3DC3DC3D,2X),2(Z.8D,X),5DZ.2D";T,S,SQR(6*T/S),ABS(PI-RES),TIME

>RUN
?1E12-1
999,999,999,999 607,927,102,272 3.14159265 0.00000000 178.90

Shocking ! I didn't notice at the time I posted my two original solutions because I never saw the wrong count, just the correct one. A little trip down the memory lane reveals what happened and why I didn't saw it:

When I ran my solution 2 for various N, the last one I entered at the input prompt was 1E12, exactly, without the " -1" used to make it the largest 12-digit integer 999,999,999,999. The program merrily run and output this:

>RUN
      ?1E12
            WRN L3:IMAGE Ovfl
            ***,***,***,*** 607,927,102,274 [...]

and I thought, "Gosh, the image 3DC3DC3DC3D caters only for 12 digits and 1E12 = 1,000,000,000,000 which has 13, thus the image overflow. But the output count, 607,927,102,274, is fully correct as per tables, so no problem."

Thus, instead of changing the already sizeable image, and as Moebius(1E12) = 0 (because 1E12 is divisible my many squares 4, for instance,) it's adding nothing to the tally, so the count for 1E12-1 must be the same value, 607,927,102,274, and thus I simply posted the input as 1E12-1 to avoid the ungainly IMAGE overflow, fully expecting that the program would produce the exact same value as the one computed for 1E12 proper so I didn't bother to check it out by actually running it again.

Alas, as J-F discovered, it does not, possibly because of some rounding error, but the solution is quite simple because the only operations which can result in such errors are the square root (which is innocent) and divisions. A little examination reveals that the culprit is IP(T/(K*K)) at line 2, and changing it to (T DIV (K*K)), like this:

      2 D=PRIM(N) @ IF NOT D THEN S=S+U^F*(T DIV (K*K)) ELSE IF MOD(N,D*D) THEN F=F+1 @ N=N/D @ GOTO 2

completely solves the problem (177 bytes):

1 DESTROY ALL @ INPUT T @ SETTIME 0 @ U=-1 @ S=T @ FOR K=2 TO SQR(T) @ N=K @ F=1
2 D=PRIM(N) @ IF NOT D THEN S=S+U^F*(T DIV (K*K)) ELSE IF MOD(N,D*D) THEN F=F+1 @ N=N/D @ GOTO 2
3 NEXT K @ DISP USING "2(3DC3DC3DC3D,2X),2(Z.8D,X),5DZ.2D";T,S,SQR(6*T/S),ABS(PI-RES),TIME

>RUN
      ?1E12-1
           999,999,999,999  607,927,102,274 [...]

Probably something like this may be affecting DavidM's program and the solution might possibly be along the same lines.

Best regards.
V.