I’m forwarding this to the MUG from a local professor, for comments. The following shows some annoying behaviour in both R.3 and R.4., at least from a pedagogical perspective. While exp(-infinity) is nicely evaluated to zero by Maple, multiply the argument by an assumed postive constant and the exp is no longer evaluated. Any reasonable work-arounds or other comments about how to make Maple a little ”smarter” about this?
Symbolic Evaluation of Limits at Infinity G.D. Stubley Mechanical Engineering Department University of Waterloo Waterloo, ON, N2L 3G1 email: firstname.lastname@example.org
First example works as expected. In this short sample ﬁle we consider the application of boundary conditions at large values (inﬁnite) of the independent variable in solutions to diﬀerential equations. As an example problem, let’s say that the general solution to the diﬀerential equation is:
where c1 and c2 are constants to be determined. For this example assume that the boundary condtions are:
Notice how the limit of exp(-infinity) is correctly set to 0 so that bc2 can be readily solved for c2.
This value for c2 is now substituted into bc1 which is solved for c1 which gives the expected ﬁnal result for f(x).
Second example illustrating the issue at hand. Now let’s consider a second example that diﬀers only in that the argument of the exponential functions is
where Omega is a positive real constant. Notice how we assume and check that Omega is a positive real number.
where c1 and c2 are constants to be determined. It is curious that Omega is not renamed Omega ~ ~ in this expression. Again assume that the boundary conditions are:
Notice how the limit of exp(-Omega*infinity) is not set to 0 so that bc2 is not readily solved for c2.
This gets uglier when c2 is substituted into bc1 which is then solved for c1 to give the unnecessarily complicated ﬁnal result for f(x).
Does this simplify when we Omega an actual value?
While it is reassuring that everything works out OK in the end when actual values are substituted, it does seem that some of the symbolic nature of the solution has been lost.
To my simple way of thinking I would have expected the second example to unfold just as the ﬁrst example did. What has gone wrong?
From a pedagogical perspective, I think it’s better to make the user a little smarter. First, instead of evaluating a function "at" x = -infinity you should be taking a limit as x -> -infinity, which is really what is going on.
Unfortunately, this doesn’t go completely smoothly either:
And Maple can’t solve this for c2.
So it’s up to the user to recognize that this means \(c2 = 0\). The Maple user still requires some mathematical knowledge. This is not necessarily a bad thing...