solve an integration using MapleSoft - integration

Question

I encountered some problems while trying to solve an integration equations using MapleSoft.There are 4 functions that are important. Here is my code defining the functions and trying to solve the problem:
"T is the starting point of the problem where it's given."
{T := proc (t) options operator, arrow; sqrt(t)/(sqrt(t)+sqrt(1-t))^2 end proc;}
"Now I solved for the inverse of function T."
V := proc (t) options operator, arrow;([solve(t = T(y), y, useassumptions)], [0 <= t and t <= 1]) end proc; '
"Only the first solution to the above is the correct inverse as we can see from the plot below."
sol := [allvalues(V(t))]; plot([t, T(t), op(1, sol), op(2, sol)], t = 0 .. 1, legend = [typeset("Curve: ", "t"), typeset("Curve: ", "T(t)"), typeset("Curve: ", "V(t)"), typeset("Curve: ", "V2(t)")]);
"Now I define the first solution as my inverse function called V1."
V1 := proc (t) options operator, arrow; evalf(op(1, sol)) end proc
"As the problem required, I have to find the derivative of V1. I call it dV."
dV := proc (t) options operator, arrow; diff(V1(t), t) end proc
"Then define a new function called F"
F := proc (t) options operator, arrow; -10*ln(1-t*(1-exp(-1))) end proc
"With V1(t), F(t), dV(t) defined, we define a new function U."
U := proc (t,lambda) options operator, arrow; piecewise(t <= .17215, min(IVF(V1(t)), max(0, 12-(1/4)/(lambda^2*dV(t)^2))), .17215 <= t, min(IVF(V1(t)), max(0, 12-(1/4)*.7865291304*lambda^-2))) end proc;
"Next I will be trying to find the value of lambda, such that the"
solve(int(U(t,lambda)*dV(t),t=0..1)= R,lambda)
"where the R will be a real number, let's say 2.93 for now."
I think the code works fine all the way till the last step where I had to solve the integration. I couldn't figure out why.
I was trying to progress further, solving the U, i.e U(t) will be 0 if t<=0.17215 and 12-(1/4)/(lambda^2*dV(t)^2)<=0 or t>=0.17215 and 12-(1/4)*0.7865291304*lambda^-2<=0 and so on so forth. But had problem solving the inequality. For example, solve(12-1/4*lambda^-2*dV(t)^-2<=0,t). The programme runs indefinitely.
Appreciate your input!

Answer 1

I'm guessing that by IVF(V1(t)) you really meant F(V(t)) .
It seemed to me that computation of your dV(t) (and perhaps V(t) sometimes) for very small t might exhibit some numerical difficulty.
And I was worried that using a narrower range of integration like, say, t=1.0e-2 .. 1.0, might mess with some significant contribution to the integral from that portion.
So below I've constructed V and dV so that they raised Digits (only) for greater working precision on (only) their own body of calculations.
And I've switched it from symbolic integration to numeric/float integration. And I've added the epsilon option for that, in case you need to control the accuracy tolerance more finely.
Some of these details help with the speed issues you mentioned above. And some of those details slow the computation down a bit, while perhaps giving a greater sense of robustness of it.
The plotting command calls below are just there for illustration. Comment them out if you please.
I used Maple 2018.0 for these. If you have difficulties then please report your particular version used.
restart;
T:=sqrt(x)/(sqrt(x)+sqrt(1-x))^2:
Vexpr:=solve(t=T,x,explicit)[1]:
Vexpr:=simplify(combine(Vexpr)) assuming t>0, t<1:
The procedure for computing V is constructed next. It's constructed in this subtle way for two reasons:
1) It internally raises working precision Digits to avoid round-off error.
2) It creates (and throws away) an empty list []. The effect of this is that it will not run under fast hardware-precision evalhf mode. This is key later on, during the numeric integration.
V:=subs(__dummy=Vexpr,
proc(t)
if not type(t,numeric) then
return 'procname'(t);
end if;
[];
Digits:=100;
evalf(__dummy);
end proc):
V(0.25);
0.2037579200498004992002294012453548811286405373\
653346413644953624868320875151070347969077227713469370
V(1e-9);
1.0000000040000000119998606410199120814521886485524\
-18
22617659574502917213370846924673012122642160567565 10
Let's plot T and V,
plot([T, V(x)], x=0..1);
Now let's create a procedure for the derivative of V, using the same technique so that it too raises Digits (only internal to itself) and will not run under evalhf.
dV:=subs(__dummy=diff(Vexpr,t),
proc(t)
if not type(t,numeric) then
return 'procname'(t);
end if;
[];
Digits:=100;
evalf(__dummy);
end proc):
Note that calling dV(t) for unknown symbol t makes it return unevaluated. This is convenient later on.
dV(t);
dV(t)
dV(0.25);
2.44017580084567947538393626436824494366329948208270464559139762\
2347525580165201957710520046760103982
dV(1e-15);
-5.1961525404198771358909147606209930290335590838862019038834313\
73611362758951860627325613490378754702
evalhf(dV(1e-15)); # I want this to error-out.
Error, unable to evaluate expression to hardware floats: []
This is your F.
F:=t->-10*ln(1-t*(1-exp(-1))):
Now create the procedure U. This too returns unevaluated when either of its argument is not an actual number. Note that lambda is its second parameter.
U:=proc(t,lambda)
if not ( type(t,numeric) and
type(lambda,numeric) ) then
return 'procname'(args);
end if;
piecewise(t <= .17215,
min(F(V(t)), max(0, 12-(1/4)/(lambda^2*dV(t)^2))),
t >= .17215,
min(F(V(t)), max(0, 12-(1/4)*.7865291304*lambda^(-2))));
end proc:
Let's try a particular value of t=0.2 and lambda=2.5.
evalf(U(0.2, 2.5));
.6774805135
Let's plot it. This takes a little while. Note that it doesn't seem to blow up for small t.
plot3d([Re,Im](U(t,lambda)),
t=0.0001 .. 1.0, lambda=-2.0 .. 2.0,
color=[blue,red]);
Let's also plot dV. This takes a while, since dV raises Digits. Note that it appears accurate (not blowing up) for small t.
plot(dV, 0.0 .. 1.0, color=[blue,red], view=-1..4);
Now let's construct a procedure H which computes the integral numerically.
Note that lambda is it's first parameter, which it passes as the second argument to U. This relates to your followup Comment.
The second parameter of H is passed to evalf(Int(...)) to specify its accuracy tolerance.
Note that the range of integration is 0.001 to 1.0 (for t). You can try a lower end-point closer to 0.0 but it will take even longer for compute (and may not succeed).
There is a complicated interplay between the lower end-point of numeric integration, and accuracy tolerance eps, and the numeric behavior for U and V and dV for very small t.
(The working precision Digits is set to 15 inside H. That's just to allow the method _d01ajc to be used. It's still the case that V and dV will raise working precision for their own computations, at each numeric invocation of the integrand. Also, I'm using unapply and a forced choice of numeric integration method as a tricky way to prevent evalf(Int(...)) from wasting a lot of time poking at the integrand to find singularities. You don't need to completely understand all these details. I'm just explaining that I had reasons for this complicated set-up.)
H:=proc(lambda,eps)
local res,t;
Digits:=15;
res:=evalf(Int(unapply(U(t,lambda)*dV(t),t),
1e-3..1,
epsilon=eps, method=_d01ajc) - R);
if type(res,numeric) then
res;
else
Float(undefined);
end if;
end proc:
Let's try calling H for a specific R. Note that it's not fast.
R:=2.93;
R := 2.93
H(0.1,1e-3);
-2.93
H(0.2,1e-5);
0.97247264305333
Let's plot H for a fixed integration tolerance. This takes quite a while.
[edited] I originally plotted t->H(t,1e-3) here. But your followup Comment showed a misunderstanding in the purpose of the first parameter of that operator. The t in t->H(t,1e-3) is just a dummy name and DOES NOT relate to the t parameter of V and dV, and the second parameter of U, and the integration varaible. What matters is that this dummy is passed as the first argument to H, which in turn passes it as the second argument to U, which is used for lambda. Since there was confusion earlier, I'll use the dummy name LAMBDA now.
plot(LAMBDA->H(LAMBDA,1e-3), 0.13 .. 0.17 , adaptive=false, numpoints=15);
Now let's try and find the value of that root (intercept).
[edited] Here too I was earlier using the dummy name t for the first argument of H. It's just a dummy name and does not relate to the t parameter of V and dV, and the second parameter of U, and the variable of integration. So I'll change it below to LAMBDA to lessen confusion.
This is not fast. I'm minimizing the absolute value because numeric accuracy issues make this problematic for numeric root-finder fsolve.
Osol:=Optimization:-Minimize('abs(H(LAMBDA,1e-3))', LAMBDA=0.15..0.17);
[ -8 ]
Osol := [1.43561000000000 10 , [LAMBDA = 0.157846355888300]]
We can pick off the numeric value of lambda (which "solved" the integration).
rhs(Osol[2,1]);
0.157846355888300
If we call H using this value then we'll get a residual (similar to the first entry in Osol, but without absolute value being taken).
H(rhs(Osol[2,1]), 1e-3);
-8
-1.435610 10
Now you have the tools to try and obtain the root more accurately. To do so you may experiment with:
tighter (smaller) eps the tolerance of numeric integration.
A lower end-point of the integration closer to 0.0
Even higher Digits forced within the procedures V and dV.
That will require patience, since the computations take a while, and since the numeric integration can fail (taking forever) when those three aspects are not working properly together.
I've I edit the body of procedure H and change the integration range to instead be 1e-4 .. 1.0 then I get the following result (specifying 1e-5 for eps in the call to H).
Osol:=Optimization:-Minimize('abs(H(LAMBDA,1e-5))', LAMBDA=0.15..0.17);
[ -7 ]
Osol := [1.31500690000000 10 , [LAMBDA = 0.157842787382700]]
So it's plausible that this approximate root lambda is accurate to perhaps 4 or 5 decimal places.
Good luck.