HP71B Integral Questions

[Albert Chan]

(02-07-2020 03:49 AM)Wes Loewer Wrote:  But the standard trapezoid method evaluates the endpoints while the rectangle midpoint method does not. As you said, the endpoints are not evaluated, which points to the midpoint method. The 50g definitely uses Romberg extrapolation of midpoints and gives very similar results as above. Setting the number format to FIX 5, you get:

result = 3.14156045554, IERR = -3.14153979546E-5

I could be wrong, but I would be very surprised if they changed up the algorithm for the 71b.

Sorry for the confusion.
I thought 65535 sample points failed convergence is enough to show INTEGRAL uses trapezoids, not midpoint rectangles.
Here are the actual numbers, and its extrapolations.

Midpoint numbers, for g(u)=3/sqrt(4-u^2), u = -1 to 1, converged quickly.
Note: table required 127 sample points, since previous iteration numbers cannot be reused.
Note: we can get midpoint numbers from trapezoids: M_n = 2 T_2n - T_n, even if T₁ were wrong.

Code:

1     3                       
2     3.098386677 3.131182236                 
4     3.129937562 3.140454524 3.141072676             
8     3.138610555 3.141501553 3.141571355 3.141579270         
16    3.140842484 3.141586460 3.141592120 3.141592450 3.141592502     
32    3.141404814 3.141592257 3.141592644 3.141592652 3.141592653 3.141592653 
64    3.141545675 3.141592629 3.141592653 3.141592654 3.141592654 3.141592654 3.141592654

Trapezoids, with assumption of T₁ = 0, failed convergence.
Last result = 3.141560455, matching HP71B INTEGRAL result.

Code:

1     0                           
2     1.5         2                       
4     2.299193338 2.565591118 2.603297193                 
8     2.71456545  2.853022821 2.872184934 2.876452994             
16    2.926588003 2.997262187 3.006878145 3.009016132 3.009535987         
32    3.033715243 3.069424323 3.074235132 3.075304291 3.075564245 3.075628788     
64    3.087560028 3.10550829  3.107913888 3.108448471 3.108578449 3.108610721 3.108618775 
128   3.114552852 3.123550459 3.124753271 3.125020563 3.125085551 3.125101687 3.125105714 3.125106721
256   3.12806688  3.132571556 3.133172962 3.133306608 3.133339102 3.13334717  3.133349184 3.133349687
512   3.134828298 3.137082105 3.137382808 3.137449631 3.137465878 3.137469912 3.137470919 3.13747117
1024  3.138210109 3.139337379 3.139487731 3.139521142 3.139529266 3.139531283 3.139531786 3.139531912
2048  3.139901289 3.140465016 3.140540192 3.140556898 3.14056096  3.140561968 3.14056222  3.140562283
4096  3.140746949 3.141028835 3.141066423 3.141074776 3.141076807 3.141077311 3.141077437 3.141077468
8192  3.141169795 3.141310744 3.141329538 3.141333715 3.14133473  3.141334982 3.141335045 3.141335061
16384 3.141381223 3.141451699 3.141461096 3.141463184 3.141463692 3.141463818 3.141463849 3.141463857
32768 3.141486938 3.141522176 3.141526875 3.141527919 3.141528173 3.141528236 3.141528251 3.141528255
65536 3.141539796 3.141557415 3.141559764 3.141560286 3.141560413 3.141560445 3.141560453 3.141560455

The reason for skipping end points is just an optimization, which work for most cases.
If f(x) is finite at the end points, g(u) has end-points = 0, because of (1-u^2) factor.
If f(x) is infinite at the end points, but grow slower than the shrinking (1-u^2), we still have 0 at the end-points.

For other cases, well, at least it returned a negative IBOUND ...