Nothing flies out by itself. Yes, I have seen this sort of construction on many occasions. I agree with Doug's comments. I was a Maple novice about 13 years ago, and have learned a lot since then, especially from forums such as this one (by asking questions, by reading other people's answers, and by attempting to answer questions myself).

Nothing flies out by itself. Yes, I have seen this sort of construction on many occasions. I agree with Doug's comments. I was a Maple novice about 13 years ago, and have learned a lot since then, especially from forums such as this one (by asking questions, by reading other people's answers, and by attempting to answer questions myself).

Assuming Jacques is correct that the numerical differences are due to roundoff error, amplified by the fact that there is cancellation of various terms, the reason for the non-determinacy is probably that the order of the terms in the sum is not the same each time. In exact arithmetic addition is commutative and associative, but this is not the case for floating-point arithmetic. When Maple constructs a sum of several terms, the order in which those terms are placed seems to be non-deterministic (presumably it depends on the detailed state of the memory, which in turn depends on what state your other applications and background processes are in at the time). The differences in orderings of the terms are enough to cause your numerical results to vary.

Consider this simpler version.

> S:= solve(sqrt(x) = p, x);
  eval(S, p=-1);

p^2 1 On the other hand,

> solve(sqrt(x) = -1, x);

(No output) Strictly speaking (if we use the principal branch of sqrt) p^2 is the solution of sqrt(x) = p only when -Pi/2 < arg(p) <= Pi/2. However, Maple gives p^2 as the solution without knowing anything about p. And it's probably better to have it do that rather than force you to make an assumption on p, both because of the annoyance factor and because Maple can't always draw the right conclusions from an assumption.

Consider this simpler version.

> S:= solve(sqrt(x) = p, x);
  eval(S, p=-1);

p^2 1 On the other hand,

> solve(sqrt(x) = -1, x);

(No output) Strictly speaking (if we use the principal branch of sqrt) p^2 is the solution of sqrt(x) = p only when -Pi/2 < arg(p) <= Pi/2. However, Maple gives p^2 as the solution without knowing anything about p. And it's probably better to have it do that rather than force you to make an assumption on p, both because of the annoyance factor and because Maple can't always draw the right conclusions from an assumption.

True, this part is not a floating point issue. It is an issue of branches of the square root. With sqrt(-18+6*F)=t, the equation is equivalent to a cubic in t, which has three solutions. However, for p = 6 one of these solutions is a negative number. This can't be a (principal branch) square root. However, when p is unspecified, this solution can't be ruled out.

True, this part is not a floating point issue. It is an issue of branches of the square root. With sqrt(-18+6*F)=t, the equation is equivalent to a cubic in t, which has three solutions. However, for p = 6 one of these solutions is a negative number. This can't be a (principal branch) square root. However, when p is unspecified, this solution can't be ruled out.

It's really pretty simple...

> SPLIT:= (f,x) -> [selectremove](`not` @ has, f, x);

It's really pretty simple...

> SPLIT:= (f,x) -> [selectremove](`not` @ has, f, x);

The problem must be occurring in those 5 to 10 lines between where you define the function and where you try to use it. Now you say the error mentions "table". That's an important clue. I suspect you've assigned a value to r[something], without realizing that what that does is actually create a table and assign it as a new value to r, overwriting the previously assigned value which was your function. The simplest cure for this is to avoid using the same name r for your indexed object that you use for your function.

The problem must be occurring in those 5 to 10 lines between where you define the function and where you try to use it. Now you say the error mentions "table". That's an important clue. I suspect you've assigned a value to r[something], without realizing that what that does is actually create a table and assign it as a new value to r, overwriting the previously assigned value which was your function. The simplest cure for this is to avoid using the same name r for your indexed object that you use for your function.

_Z is just a handy name for a new variable. RootOf(P(_Z)) means some _Z that satisfies the equation P(_Z) = 0. Polynomials have several roots, and an index is one way to keep track of which root you are dealing with. So e.g. RootOf(_Z^2 + _Z + 1, label = 1) would be one solution of _Z^2 + _Z + 1 = 0, and RootOf(_Z^2 + _Z + 1, label = 2) would be the other. If the label is given as a variable such as _L2, that just means that any root would do (but each time the RootOf with index = _L2 appears, it refers to the same root). In your case, what Maple is saying is that for any solution _Z of 1+A+(-Y*A-2*Y)*_Z+(X^2+Y^2)*_Z^2 = 0 you get a solution of your equations with {Cp = _Z/A/w, Rp = -X*A/(_Z*Y-A-1)} To make it look nicer, you might try something like this:

> S := solve(...);
  RootOfs := indets(S, RootOf);
  P := subs(_Z = z, op([1,1],RootOfs));

(this is the equation that the RootOf must satisfy, using z instead of _Z)

> eval(S, op(1,RootOfs)=z);

(this is the solution expressed in terms of z)

Why are you putting square brackets [ ] around the right side of equations equ1 and equ2? Square brackets are used to make a list. That doesn't make any sense here. Without those brackets, fsolve seems to work fine on your system. Perhaps this should be considered a bug: there should be a helpful error message in this situation rather than just fsolve returning unevaluated.

Why are you putting square brackets [ ] around the right side of equations equ1 and equ2? Square brackets are used to make a list. That doesn't make any sense here. Without those brackets, fsolve seems to work fine on your system. Perhaps this should be considered a bug: there should be a helpful error message in this situation rather than just fsolve returning unevaluated.

It's one way to try, but not necessarily a good way. Suppose what you actually want to know is whether the determinant is 0 (which is pretty typical). That's a well-defined question for a square matrix with exact entries, but it becomes problematic for floats. The determinant is a polynomial in the entries of the matrix: if you're very lucky, converting the entries to rationals may hit on a point where that polynomial is exactly 0. More likely, it won't be exactly 0, even if the result "should" be 0 (i.e. the matrix is a floating-point approximation of a matrix whose determinant is 0). It may not even be small, if there are several large eigenvalues. A more stable way to tell would be to use the singular-value decomposition.