@Carl Love I thank you very much for doing the honorable thing by restoring the original Question.

@Carl Love I thank you very much for doing the honorable thing by restoring the original Question.

@nm I agree strongly about the need for more examples on the help pages. However, here on MaplePrimes, there have been hundreds, perhaps thousands, of Questions about third-order BVPs.

I will Answer your Question below, but you must promise to not ever edit or delete the Question.

@maria182 Please don't ever remove a Question after it has been Answered!

Please don't ever remove or substantially edit a Question that has already been Answered!

Note that the given Answer now makes no sense following your now-"sterilized" Question. I find this incredibly disrespectful to the person who took the time to Answer.

@taro The :- is not attached to the procedure header it comes after; rather, it's attached to the variable it comes before. It means that the following variable is a global variable even if it has a name that would ordinarily be overridden by a local variable or module export of the same name.

@maria182 Like I said above, you need to use exp(...) rather than e^....

t2 := inttrans:-invlaplace(exp(-s)/(s*(1-exp(-s))), s, t);

@maria182 Okay, here is how it can be done with linalg:

Wronsk:= (sol::list(algebraic), x::name)->
     linalg:-det(convert([seq(diff(sol, [x$k]), k= 0..nops(sol)-1)], matrix))
:
Wronsk([exp(x), cos(x), sin(x)], x);

I recommend that you inform your instructor "I saw on MaplePrimes that Maplesoft has been discouraging the use of linalg for many years. It has been replaced by other packages."

@cookee In the vast majority of cases, eval and subs give the same results; however, eval "knows" math and subs does not. So, it's safer to use eval for mathematical expressions and to reserve subs for low-level operations. See ?eval for some examples of when eval and subs are different.

@acer Yes, starting at 2 and using simply the "add x to g" approach leads to divergence to Float(infinity). But some other starting values converge. I think that one of the point of the exercise may be to learn that using this approach will never converge to the root near 2, but many starting values will converge to the other root.

@woodpeck If you need help implementing Acer's correction of your algorithm, I think that the best way is to simply add x to g inside the procedure.

Post an updated procedure when you have one. I have an improved procedure, but I want to see where you get with it before I post it.

Coloring symbols (such as Q__T) is one thing, and coloring functions (such as Q__T(t)) is another. I believe that the former will be much easier than the latter.

If you could post a worksheet, any worksheet that you may find, that has a colored variable in it, I think that I could use that to write a procedure that will color any variable.

@csu_outdoorgeek It was a trivial bug that it would've taken you ages to find on your own. You have an extra space after the first fsolve command. This space is unfortunately interpretted as a multiplication operator, so the fsolve is not being applied to its arguments.

This extra-space problem only applies to Maple's (default) 2-D input. In 1-D input (aka Maple Input), spaces are never interpretted as operators.

Your procedure translated into 1-D input looks like

CAPE:= proc()
local dp, sum, pp, Tt, Ta;
global thetae, cape;
     dp := -10;
     sum := 0;
     for pp from plfc by dp while pt-dp <= pp do
          Tt := fsolve (thetaxx(T, pp)-thetae = 0, T = 200 .. thetae);
          Ta := To*(pp/po)^(R*Gamma/g);
          sum := sum+(Tt-Ta)/pp
     end do;
     Tt := fsolve(thetaxx(T, pt)-thetae = 0, T = 200 .. thetae);
     Ta := To*(pt/po)^(R*Gamma/g);
     cape := -(sum+(1/2)*(Tt-Ta)/pp)*R*dp;
     printf("CAPE (J/kg) = %g\n", cape)
end proc:

except that the text is reddish brown instead of black.

@acer I was working from the OP's code posted on imgur, and my intention was only to implement the iteration-counting mechanism that they had obviously tried to implement.

Yeah, FAIL is better than error now that I think about it.