Yes, I did mean LinearSolve(U1[1..3,1..4],<0,0,0>), and I'm still getting caught by that darn < issue. How can I know that it's OK? Well, in general I won't know that in advance, but "generically" it works out OK. You'll note that I checked that my answer really did work. Only after doing that can I say that it's OK. The point of not doing LinearSolve(U1, Vector(4)) is that if Maple doesn't detect certain identities, the result would be the 0 vector. The first 3 rows will have rank at most 3 in any case, so the result of my LinearSolve should always have at least one free parameter; if the first 3 rows are linearly independent, there will be exactly one free parameter, and that fact does not depend on detecting the identity. It is possible (but won't happen generically) that the solution of this system will not really exist because the identity makes the denominator 0. If that doesn't happen, what the identity will do is make the product of the fourth row with this solution vector 0.

Yes, I did mean LinearSolve(U1[1..3,1..4],<0,0,0>), and I'm still getting caught by that darn < issue. How can I know that it's OK? Well, in general I won't know that in advance, but "generically" it works out OK. You'll note that I checked that my answer really did work. Only after doing that can I say that it's OK. The point of not doing LinearSolve(U1, Vector(4)) is that if Maple doesn't detect certain identities, the result would be the 0 vector. The first 3 rows will have rank at most 3 in any case, so the result of my LinearSolve should always have at least one free parameter; if the first 3 rows are linearly independent, there will be exactly one free parameter, and that fact does not depend on detecting the identity. It is possible (but won't happen generically) that the solution of this system will not really exist because the identity makes the denominator 0. If that doesn't happen, what the identity will do is make the product of the fourth row with this solution vector 0.

Now I'm confused (this does not imply that I wasn't confused before, just that I now know that I'm confused). I based my statement on Paul Wang's article which doesn't mention the absolute value function when it refers to "Caviness' improved version of Richardson's Theorem", but skimming through Caviness's article it looks like the absolute value is required after all for that result.

Your problem is called premature evaluation. Like most Maple commands, plot starts by evaluating its arguments. In this case that means that Maple tries to evaluate f(x,5) where x is a symbolic variable, and that of course doesn't work. One work-around is to use quotes to delay evaluation:

> plot('f(x,5)', x = 5 .. 10);

Another is to plot a function rather than an expression, with the "x = " left out of the range specification:

> plot((x -> f(x,5)), 5 .. 10);

which can also be done as

> plot(rcurry(f,5), 5 .. 10);

I hope I have this right. Richardson's undecidability result, as sharpened by Caviness, shows there is no algorithm that, given a function G(x) of one variable constructed using rational numbers, pi, addition, multiplication, composition and the sin function, decides whether there exists real x such that G(x) < 0. Thus there is no way to verify whether sqrt(G(x)^2) = G(x) is a correct identity [using the positive square root].

A good example of what's wrong with 2D Math input is implied multiplication. At first sight it looks like a great idea: we can type 3 x y just like we'd write it on a blackboard. But on second thought it's not such a great idea. In 1D math, students can easily accept the idea of using the * key for multiplication: they've been using it on their calculators for years. The rule is extremely simple and consistent: to multiply, use *. And if you forget to do it, Maple gives you a friendly "missing operator or ;" error to remind you. In 2D math, you don't need the *, but you do need a space. Well, sometimes you do: 3x is OK, (a + b)y is OK, but x(a+b) is not OK; 3(a+b) is not OK in Classic but may or may not be OK in Standard, depending on a setting in the Typesetting Rule Assistant. On the other hand, putting a space in sin (a+b), which was OK in 1D math, is not OK in 2D math in Standard but is OK in Classic. What a mess! And none of the "not OK" cases causes a syntax error, they just make your results wrong. Moreover, in these nice italic proportional fonts, it can be rather difficult to tell whether you have a space or not. Try typing f L + eV in 2D math; could you tell at a glance which has a space and which doesn't? So, would you really suggest that a beginner should use 2D math input?

A good example of what's wrong with 2D Math input is implied multiplication. At first sight it looks like a great idea: we can type 3 x y just like we'd write it on a blackboard. But on second thought it's not such a great idea. In 1D math, students can easily accept the idea of using the * key for multiplication: they've been using it on their calculators for years. The rule is extremely simple and consistent: to multiply, use *. And if you forget to do it, Maple gives you a friendly "missing operator or ;" error to remind you. In 2D math, you don't need the *, but you do need a space. Well, sometimes you do: 3x is OK, (a + b)y is OK, but x(a+b) is not OK; 3(a+b) is not OK in Classic but may or may not be OK in Standard, depending on a setting in the Typesetting Rule Assistant. On the other hand, putting a space in sin (a+b), which was OK in 1D math, is not OK in 2D math in Standard but is OK in Classic. What a mess! And none of the "not OK" cases causes a syntax error, they just make your results wrong. Moreover, in these nice italic proportional fonts, it can be rather difficult to tell whether you have a space or not. Try typing f L + eV in 2D math; could you tell at a glance which has a space and which doesn't? So, would you really suggest that a beginner should use 2D math input?

I fully agree with Doug. It's also one of the first things I tell my students, and I've stated my opinions many times, here in newsgroups, and to Maplesoft. I'm only surprised that you find this surprising.

I fully agree with Doug. It's also one of the first things I tell my students, and I've stated my opinions many times, here in newsgroups, and to Maplesoft. I'm only surprised that you find this surprising.

You could set all variables in your polynomial to 0 (please don't call it an "equation", because it doesn't contain =).

> eval(eq, map(`=`,indets(eq),0));

You could set all variables in your polynomial to 0 (please don't call it an "equation", because it doesn't contain =).

> eval(eq, map(`=`,indets(eq),0));

Note that the binary variable _B1 takes the values 0 and 1, while _Z1 takes arbitrary integer values. For _B1 = 0:

> S := 2/3*Pi-4/3*Pi*_B1+4*Pi*_Z1:
  seq(eval(S,{_B1=0,_Z1=z}),z=-3..3);

-34/3*Pi, -22/3*Pi, -10/3*Pi, 2/3*Pi, 14/3*Pi, 26/3*Pi, 38/3*Pi For _B1 = 1:

> seq(eval(S,{_B1=1,_Z1=z}),z=-3..3);  

-38/3*Pi, -26/3*Pi, -14/3*Pi, -2/3*Pi, 10/3*Pi, 22/3*Pi, 34/3*Pi So the smallest positive values are 2/3*Pi and 10/3*Pi.

Yes, this should rate a mention: I'll put it in the "Spelling counts" section.

In Maple 10 and up, you can use [] brackets in the solve command. The result is returned as a list of lists of equations. This has the advantage that you get the a[j] and b[j] equations in that order.

In Maple 10 and up, you can use [] brackets in the solve command. The result is returned as a list of lists of equations. This has the advantage that you get the a[j] and b[j] equations in that order.