Wikipedia has a basic definition, which in turn is related to Cylindrical Algebraic Decomposition (or CAD). It is a process by which "quantifiers" are eliminated from formulas in ordered fields. In this case, root-solving involves eliminating an existential quantifier -- and your parameters would involve universal (for all) quantifiers too. Unfortunately, unlike Mathematica, Maple has no such algorithm built-in. However, there is a way to access it (via PVS -- see Ruth Hardy's work).

Wikipedia has a basic definition, which in turn is related to Cylindrical Algebraic Decomposition (or CAD). It is a process by which "quantifiers" are eliminated from formulas in ordered fields. In this case, root-solving involves eliminating an existential quantifier -- and your parameters would involve universal (for all) quantifiers too. Unfortunately, unlike Mathematica, Maple has no such algorithm built-in. However, there is a way to access it (via PVS -- see Ruth Hardy's work).

The symbolic determinant of a 2-3 parameter, 15*15 (or more) matrix is going to be HUGE unless your matrix is very very special. Then solving it will also be a very difficult problem. Let's assume you really do want the zeroes of N [but I doubt you really do, I suspect that this is just a step in a larger computation]. In general, even if the entries of M are polynomials, the zeroes of N will be nasty algebraic functions -- will that be useful to you? If I were to do this myself, I would compute an LU decomposition of M, and while the algorithm progresses, I would record the various divisions that occur [each one of these will be a factor of the determinant]. This leads to much smaller expressions. Also, since you get to know that some expressions are non-zero as you progress, that helps further computations. Another avenue is to use some fancy technology that I've developped (see this paper, in particular the Gaussian Elimination example). But actually, the best way to deal with this would be for you to tell us more about the actual problem you're trying to solve! Then we might be able to suggest an entirely different way to attack it (with Maple) that would be more efficient.

If you add a non-degeneracy condition to your system, viz that none of V,Y,Z, nor G,X1,X2,X3 are equal to zero, ie eq4 := s*V*Z*G*X1*X2*X3-1=0; then solve({eq1,eq2,eq3,eq4},{V,Y,Z,s}); (even though the solution in s is obvious), that should help, if there are solutions at all. But this kind of non-linear system with that many parameters usually has "wallpaper" as an answer. So while Maple most certainly has algorithms to solve this, they might not terminate in a very very long time. Certainly my computer does not have enough memory to let them run long enough to find an answer. [Once a Maple program starts swapping, you may as will kill it, it will not likely ever terminate in your lifetime].

Now up to 45 points, so 2 more (non-existant!) blog posts. Very weird. Hacker attack?

You are correct, and I did that on purpose. If A contains several arctan expression(s), then the original question was ill-posed, and some of the answers above will break. My solution will return all the possibilities correctly - even in the case of 0 arctan expressions. It is then simple to have the caller of this routine decide what to do if there is not exactly one arctan expression in the input. This is what I meant by 'robust'.

You are correct, and I did that on purpose. If A contains several arctan expression(s), then the original question was ill-posed, and some of the answers above will break. My solution will return all the possibilities correctly - even in the case of 0 arctan expressions. It is then simple to have the caller of this routine decide what to do if there is not exactly one arctan expression in the input. This is what I meant by 'robust'.

The forward quotes are unevaluation quotes, so that 'NULL' is unevaluated, rather than inert. Inert forms refer either to things like Int (the version of int which does nothing) or the result of ToInert. What is going on here is that expression sequences automatically flatten, so that (1,2), (3,4) is equal to 1,2,3,4. This is also true with NULL, so that 1, NULL, 3 equals 1,2, and thus NULL, NULL equals NULL! By delaying evaluation, one can assign 'NULL' to a which, once evaluated, gives NULL. This kind of uneval gymnastics is very fragile, mostly because just enough core maple functions have special evaluation rules that most library routines will have weird corner cases.

I get the same behaviour as you do, and this used to work. Looks like someone made a mistake when they updated the site. Now that the business day in the EST timezone is about to start, I would expect this to be fixed soon.

var := cat(`index/`, foo);
assign(var, proc() ... end proc);

will allow you to assign to the contents of a variable. However, note that var will *also* be assigned in this process [which is weird, but usually not a big deal].

List arithmetic is one of those dubious features that was introduced (in 94 or 95) in an early attempt to improve linalg. While it did help, it really was a band-aid rather than a serious implementation. With Maple 6, proper data-structures [Vector and Matrix, all based on rtable] were introduced, along with LinearAlgebra. But list arithmetic, while barely documented, had made it into the wild, and backward-compatibility fears reared it ugly head, so it was left in. This is why assigning to small lists is also still in there, even though it causes way more grief to hapless programmers who usually meant to use an Array but (by mistake) use a list and their program seems to "work" anyways. Only later do they get bitten by the fact that that does not scale.

If you change the definition for kappa to kappa := y -> piecewise(y=[0,0], 5, 1/len(y)); then it works just fine. Also, it is a good idea to use add rather than sum in this case [though that is not the primary source of your problem here]. Note that you may also be better off using Vectors rather than lists, as Vector arithmetic is more predictable than list arithmetic.

At least, it is consistent with a lot of the rest of Maple. The Matrix constructor always builds a new Matrix. When creating the A Vector, every entry is created by a _call_ to Matrix, so you get different objects. When creating B, every entry is filled with the same (constant) object, in this case a Matrix; so the call to Matrix happens only once. That the initializer for A is called for every entry, and that for B only once, is the only possible design decision with respect to the semantics of Maple. The next question is, should Matrix always return a 'new' Matrix? Here again, there is not much choice! If Matrices were not mutable, one could safely return the same, but unfortunately most people expect to be able to assign to entries of a Matrix. While that is a possible design, it has two drawbacks: it is unfamiliar, and it is inefficient in an interpreted language. So it is not really a viable design.

It is safer still to use diff(f(x),[x$n]) since that works properly for n=0 too.

seq was introduced first, but it did not always interact very well with all other commands. So $ was introduced (in Maple 4.0, ie around 1985) with somewhat different evaluation rules, in an attempt to make things better. But a lot of time has passed, and even though $ was introduced to be a more convenient notation than seq, the funny evaluation rules of $ did not keep up with the evolution of the rest of Maple. Through that evolution, seq become more "useful", as it interacts better with modern Maple than $ does. So much so that, some years ago, $ was eradicated from use in the library and exchanged for seq. But $ was never (officially) deprecated, nor fixed (backwards compatibility fears). So it still exists, still shows up in textbooks, manuals and tutorials, yet is not used by Maplesoft developers. Go figure.