[VA] SRC #010 - Pi Day 2022 Special

[Ángel Martin]

(03-18-2022 12:25 AM)Valentin Albillo Wrote:  In short, Ángel, try to use these two additional correction factors but, if you don't get the desired expected, significant improvements, it might be the case that you're running against the limits of the HP-41 accuracy, as happened with Free42 Decimal above, and then it's just a case of finding the sweet spot and see if the additional terms do any good to achieve the sweetest one possible.

Indeed the two additional correction factors make a huge difference: once added to the code the sweet spot for 10-digit pi now occurs with N=35 terms, giving the "exact" same value returned by the native "PI" function, i.e. 3.141592654.

Here's the new table for your reference: (also includes the execution time using a default settings on V41, definitely not TURBO mode)

Code:

n       result          |Delta%|        Time
5       3.141630979    1.21992E-05    0.000174
10      3.141593984    4.23352E-07    0.000297
15      3.141592834    5.72958E-08    0.000438
20      3.141592696    1.3369E-08    0.000568
25      3.141592666    3.81972E-09    0.000698
30      3.141592658    1.27324E-09    0.000829
35      3.141592654    0               0.00096
40      3.141592652    6.3662E-10      0.001088
45      3.141592651    9.5493E-10      0.001219
50      3.14159265      1.27324E-09     0.001337
55      3.141592648     1.90986E-09     0.001468
60      3.141592644     3.1831E-09      0.001606

What a difference!

BTW the previous version had a glitch that shifted the number of terms by one, now duly corrected. This is now old history but it skewed the results in about 50-60 terms due to cumulative errors, but that's immaterial now with the new version posted here.

(03-18-2022 12:25 AM)Valentin Albillo Wrote:  ... And J-F Garnier's idea of taking logs and then taking advantage of the built-in LN1+X function in order to enhance accuracy is brilliant, congratulations ! ... Perhaps Ángel might use it to achieve better results with its HP-41C MCODE version.

Yes, I've changed the approach to using a summation instead of a product - even if in the MCODE realm there's not much of a difference at the end of the day: you may gain some accuracy in the sums (instead of multiplications) but you lose some in the final Log/Exp conversions. BTW, on the LN1+X, well such function exists for 10-digit accuracy but does not have a 13-digit counterpart - simply because it's not needed in MCODE, where we have access to the "real" things with calls to [LN13] and [ADDONE] of course.

Lovely end-game even on the 41, thanks again!

ÁM

"It's not the size of the wand but the skill of the wizard what counts"