[VA] SRC#006- Pi Day 2020 Special: A New Fast Way to Compute Pi

[Valentin Albillo]

.
Hi, EdS2:

(03-18-2020 09:51 AM)EdS2 Wrote:  Thanks for the pointers!

You're welcome. I hope you'll find them interesting.

Quote:Understood, apologies, and I've added a note to that post.

Thanks. Let bygones be bygones.

Quote:It seems to me that any strictly positive starting value less than pi will converge to pi - is that not so?

Yes, and not only for such values less than Pi but also for values up to (but not including) 2*Pi. However, as the strictly positive starting value approaches 0, the number of iterations required to approximate Pi does increase (logarithmically) without limit, as can be easily seen this way: consider that for some epsilon > 0 we have eps+sin(eps) ~ eps + eps = 2*eps as the next value, which means that every iteration the initial eps value is approximately doubling, i.e., growing exponentially, so in a logarithmic number of iterations it will reach "macro" size (say 0.1, 0.2 ...) and afterwards it will converge cubically to Pi.

Quote:About the wonderful and unexpected rnd/rnd code: [...] Hmm. I must be missing something. Here's your posted code:

1 DESTROY ALL @ RANDOMIZE 1 @ FOR K=1 TO 5 @ N=10^K @ S=0
2 FOR I=1 TO N @ IF NOT MOD(IROUND(RND/RND),2) THEN S=S+1
3 NEXT I @ P=S/N @ STD @ DISP N, @ FIX 3 @ DISP 5-P*4 @ NEXT K
[...]
and here's mine, in BBC Basic:

10 FOR K=1 TO 7
20 N%=10^K
30 S%=0
40 FOR I=1 TO N%
50 S%=S%+INT(RND(1)/RND(1)+.5)MOD 2
60 NEXT
70 PRINT N%,1+4*S%/N%
80 NEXT

Evidently something is somehow slightly different.

There are two possibilities. I'm not famiilar with BBC BASIC but it might be the case that integer variables (%) can only hold from -32768 to +32767, so 10^5, 10^6 and 10^7 wouldn't fit in N%. However, I assume that's not the case or you'd noticed pretty quickly.

The second possibility is that you're not implementing the IROUND function correctly. I see you're implementing IROUND(x) as INT(x+.5) but that's not how IROUND works, which actually depends on the current OPTION ROUND setting, namely: OPTION ROUND NEAR/ZERO/POS/NEG.

My code assumes the default setting, OPTION ROUND NEAR, which causes IROUND(x) to round x to the nearest integer and, in case of a tie, to the even value. Thus we have:

      IROUND(4.1) = 4 (4 is nearest)
      IROUND(4.6) = 5 (5 is nearest)
      IROUND(4.5) = 4 (both 4 and 5 are equally near, but 4 is even)
      IROUND(5.5) = 6 (both 5 and 6 are equally near, but 6 is even)


This may or may not explain the difference but I have a question for you: have you entered my unmodified posted code in a physical or emulated HP-71B ? Does it produce the posted results ? If not, could you post the listing and the results you get ?

Regards.
V.