I made a program for finding a triple integral of an f(x,y,z) function over a general region, but it's not working for some reason.
Here's an excerpt of the program, for when the order of integration is dz dy dx:
(B-A)/N→D
0→V
Dsum(seq(fnInt(Y₅,Y,Y₉,Y₀),X,A+.5D,B,D))→V
For(K,1,P)
A+(B-A)rand→X
Y₉+(Y₀-Y₉)rand→Y
Y₇+(Y₈-Y₇)rand→Z
Y₆→ʟW(K)
End
Vmean(ʟW)→V
Variables used explained below:
Y₆: Equation of f(x,y,z)
Y₇,Y₈: Lower and upper bounds of the innermost integral (dz)
Y₉,Y₀: Lower and upper bounds of the middle integral (dy)
A,B: Lower and upper bounds of the outermost integral (dx)
Y₅: Y₈-Y₇
N: Number of Δx intervals
D: Size of Δx interval
P: Number of points on D to guess the average value of f(x,y,z)
ʟW: List of various values of f(x,y,z)
V: Volume of the region of integration, then of the entire triple integral
So here's how I'm approaching it:
I first find the volume of just the region of integration using Dsum(seq(fnInt(Y₅,Y,Y₉,Y₀),X,A+.5D,B,D)). Then I pick a bunch of random (x,y,z) points in that region, and I plug those points into f(x,y,z) to generate a long list of various values for w = f(x,y,z). I then take the average of those w-values, which should give me a pretty good estimate for the average "height" of the 4D solid that is the triple integral; and by multiplying the region of integration "base" with the average w-value "height" (Vmean(ʟW)), it should give me a good estimate for the hypervolume of the triple integral.
It should naturally follow that as the number of (x,y,z) points tested increases, the value of the triple integral should more or less converge to the actual value.
For some reason, it doesn't. For some integrals it works fantastically, for others it misses by a long shot. Good example of this is ∫[0, 2] ∫[0, 2-x] ∫[0, 2-x-y] 2x dz dy dx. The correct answer is 4/3 or 1.333..., but the program converges to a completely different number: 2.67, give or take.
Why is it doing this? Why is the triple integral converging to a wrong number?
EDIT: My guess is—assuming I didn't make any mistakes, for which there are no promises—that the RNG algorithm used by the calculator can only generate numbers slightly greater than 0 and is throwing the program off, but I have no way to confirm this, nor to account for it since "slightly greater than 0" isn't quantified.
