@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.

@artfin The size of the file isn't the problem. The problem is that the output of the program is 17 plots. How am I to decide which you think are correct? Or if you think that two of them differ even though they shouldn't, how am I to decide which two those are?

Modify the code to just produce two plots. There's no need to include the plots in the file; I can run the code and generate the plots. Then the file size will be minimal. And I'm pretty sure that you don't think that the problem is with the grey spheres in the background, so don't plot them. This is how we debug this situation: We gradually eliminate the things that are the same. If the output is still different, then the trouble lies in the code that remains.

I'm not saying that you should remove the unnecessary code. Just comment it out.

Please upload a worksheet that contains your code whose output contains (in the worksheet itself) exactly two plots which are different but which you think should be the same. If your plot consists of subplots, then your output should consist of only two subplots that are different.

If you believe that one of the plots is correct, indicate which one. However, it's fine if you can't decide.

It would be helpful if you could add the following two comments somewhere in your code:

1. "I'm (reasonably) sure that the divergence between the two plots doesn't occur above this point in the code."
2. "I'm (reasonably) sure that that the divergence between the two plot does occur above this point in the code."

If you can't figure out where to put those comments, that's okay.

@brian bovril By the way, the Pi and the 1/2 and even that the cakes are round are irrelevant. The problem can be solved simply by squaring the diameters.

@TomM So your technique for estimating the degree and the ldegree involves about the same computational effort as a minor expansion and is thus practically impossible for a larger matrix.

Like I said, the unifloat algorithm is nearly guaranteed to produce a dense polynomial. If you know a priori that the polynomial is not dense, then unifloat is a bad algorithm to use.

Your title "equal diameter division" is confusing or misleading; how about "Equal division of unequal cakes"?

The numeric case presented is a very special case. The numbers 15, 20, 25 are a Pythagorean triple. It is only because of this that cutting the cakes in half is a viable solution. Of course, that produces six pieces, but it can be accomplished with a single planar cut if you stack the cakes. The five-piece solution involves an uneven cut of the middle cake, and a bisection of the large cake. It's easy to see that there's no four-piece solution.

The general problem is interesting, and I think that it's amenable to a computer solution if the m and n are not too large. The diameter aspect is just a slighly obfuscating factor---it just means that you need to square the original numbers before proceeding. So, you might as well just ignore that aspect because it adds no mathematical complexity to the probem. So, recasting the problem more mathematically: Given m positive numbers whose sum is 1, find a way to cut some of those numbers so that the resulting set can be partitioned into n subsets each with sum 1/n. Find a way to do this that minimizes the cardinality of the overall set.

@emendes In this case, it's easy to make both your code and Kitonum's code more concise by eliminating the redundant use of the symbolic constants true and false. The expression `if`(r, false, true) is equivalent to not evalb(r) in the vast majority of cases, which is equivalent to simply not r in the vast majority of cases. There's some subtlety about this in the case of inequalities, but that's not what you're dealing with here.

@Kitonum You're misinterpretting the output of evalb. The mechanism by which Maple attempts to prove things is is. Consider these cases:

evalb(a=x);
     false
is(a <> x);
      false
is(a = x);
     false
`or`();
     false
`and`();
     true
evalb(a < x);
     a < x
is(a < x);
     false

The only thing that evalb(a <> x) is telling you is that a and x don't share the same memory address.