My point, and Robert's as well in the post below, is that there are no solutions if a0, a1, a2, c1, and c2 are considered as symbols.  Solving the system taking all the symbols as unknowns helps explain why that is the case.

---

John May
Mathematical Software
Maplesoft

My point, and Robert's as well in the post below, is that there are no solutions if a0, a1, a2, c1, and c2 are considered as symbols.  Solving the system taking all the symbols as unknowns helps explain why that is the case.

---

John May
Mathematical Software
Maplesoft

You can always call solve(sys, {m,n,k});

However, I think that your system is overdeterminined - too many equations and not enough unknowns.

If you call solve(sys); you'll see that there are only solutions for certain values of the parameters: c1 can vary but c2 = 0, a1 = 0, a2 = 0, and  a0 = 1.

---

John May
Mathematical Software
Maplesoft

You can always call solve(sys, {m,n,k});

However, I think that your system is overdeterminined - too many equations and not enough unknowns.

If you call solve(sys); you'll see that there are only solutions for certain values of the parameters: c1 can vary but c2 = 0, a1 = 0, a2 = 0, and  a0 = 1.

---

John May
Mathematical Software
Maplesoft

What I wrote was incorrect.  The first entry is not a bound.  I confused myself by looking at an uncharacteristic example.

Robert is right, the first entry is 0 by default.

---

John May
Mathematical Software
Maplesoft

What I wrote was incorrect.  The first entry is not a bound.  I confused myself by looking at an uncharacteristic example.

Robert is right, the first entry is 0 by default.

---

John May
Mathematical Software
Maplesoft

I agree. Roots should either call fsolve on floating-point input, or at least use a numeric check instead of an exact check. 

This same issue came up last week in another context (which is why I knew exactly what was causing the problem) and I have made the current maintainer of the Student packages aware of it.

---

John May
Mathematical Software, Maplesoft

As Scott points out, Roots should be called with the numeric option if you have floating point input: Student:-Calculus1:-Roots(sin(3*alpha)-.34, alpha = 0 .. 12, 'numeric'); Without the numeric option, Roots is calling 'solve' (instead of fsolve) and this solves the input converted to rational numbers: convert(sin(3*alpha)-.34, 'rational'); However, after it has the solutions, it calls evalf on them and sends the numerical solutions back to Roots(). Roots then plugs each solution back into the original floating point expression and checks whether they are exactly equal to 0. With the way floating point works, you have to be pretty lucky for the numerical roots to actually give you 0.0 when you plug them back in. Try it: seq(eval(sin(3*alpha)-.34, alpha=sol), sol=Student:-Calculus1:-Roots(sin(3*alpha)-.34, alpha = 0 .. 12, 'numeric')); If you are interested in the exact solutions instead of the numerical ones, you should not put floats in your input: Student:-Calculus1:-Roots(sin(3*alpha)-34/100, alpha = 0 .. 12); --- John May Mathematical Software, Maplesoft

This option was added to solve in Maple 10; if you are using Maple 9.5 or earlier it will give you an "Invalid arguments to solve" error. -- John May Mathematical Software, Maplesoft

Instead of using _EnvAllSolutions, I prefer to pass the AllSolutions option to solve: solve(cos(x/2) = 1/2, x, AllSolutions); it does the same thing, but it is more localized. -- John May

Unfortunately, right now, to get all of the solutions you also need the AllSolutions option: solve({y=2*x-5,y=2*x^2+2*x-21},{x,y},Explicit,AllSolutions); {x = -2*2^(1/2), y = -4*2^(1/2)-5}, {x = 2*2^(1/2), y = 4*2^(1/2)-5}

Unfortunately, right now, to get all of the solutions you also need the AllSolutions option: solve({y=2*x-5,y=2*x^2+2*x-21},{x,y},Explicit,AllSolutions); {x = -2*2^(1/2), y = -4*2^(1/2)-5}, {x = 2*2^(1/2), y = 4*2^(1/2)-5}

Some of the weirdness seen in int in this thread comes from a subtle issue in the elliptic integrator (and thus it affects a lot of integrals with square-roots of trig functions). Maple is often pretty good at applying the fundamental theorem of calculus to compute definite integrals even in a case when the indefinite integral it returns is discontinuous. For the problem above where f:=2*cos(t)^5*sqrt(2*cos(t)^2-1);a:=-Pi/4; b:=Pi/4; Maple tries a couple different technique. Unfortunately it happens to return the buggy answer:

 int(f,t=a..b): evalf(%);
#                                      0.

 evalf(Int(f,t=a..b));         
#                                  1.735501148

which as I mentioned, comes from an issue with trig substitution in the elliptic integrator:

 `int/definite/elliptic`(f,t,a,b,{});
#                                       0

 `int/definite/ftoc`(f,t,a,b,{}); evalf(%);
#                                      1/2
#                                  25 2    Pi
#                                  ----------
#                                      64
#
#                                  1.735501148

As you can see, there is an internal integrator "ftoc" that gets the right answer. However, "ftoc" it is a lot slower than "elliptic" (1/10s vs. 2s on my machine) and that probably gives you a hint as to why "elliptic" is the first algorithm tried here.

It looks like the reason assuming doesn't work has to do with the fact that the assumptions are being made on symbols that live inside the function and so assuming can't "see" them. If you do: R:=rho(lambda); int(R, lambda = 0 .. infinity) assuming h>0, c>0, T>0, k>0; Everything works dandy. This also works RHO:=(c,k,h,T,lambda)->8*Pi*h*c/(lambda^5*(exp(h*c/(lambda*k*T))-1)); int(RHO(c,k,h,T,lambda), lambda = 0..infinity) assuming h>0, c>0, T>0, k>0; I am not certain whether this is a bug or a feature of assuming.

It looks like the reason assuming doesn't work has to do with the fact that the assumptions are being made on symbols that live inside the function and so assuming can't "see" them. If you do: R:=rho(lambda); int(R, lambda = 0 .. infinity) assuming h>0, c>0, T>0, k>0; Everything works dandy. This also works RHO:=(c,k,h,T,lambda)->8*Pi*h*c/(lambda^5*(exp(h*c/(lambda*k*T))-1)); int(RHO(c,k,h,T,lambda), lambda = 0..infinity) assuming h>0, c>0, T>0, k>0; I am not certain whether this is a bug or a feature of assuming.