1. Since A has two more rows than columns, the system may be overdetermined. Do you expect that two of the rows of A|b will row-reduce to 0 (or, equivalently, that two of the system's equations are redundant)? Since we're dealing with float coefficients, some small-magnitude entries of the row-reduced matrix may need to be forced to be 0.

2. What is the type of entries of b? floats? polynomials?

3. You said that x[i] are polynomials in kappa. I'd expect them to be rational functions in kappa, not polynomials in general.

Regarding your 2): Maple isn't truncating the terms regardless of how long they are. You can't solve such a problem with floats and expect the residuals to be identically 0. High-degree polynomials (or rational functions) will make this even worse.

Regarding your 1): I doubt that method= solve is exploiting the structure of your A---that its entries are univariate polynomials. I'd solve the problem by imaging at specific numeric values of kappa, solving the resulting systems, and then using CurveFitting:-RationalInterpolation to construct the rational-function solutions. To proceed, I need to know about the overdetermineness.

@David1 You wrote:

• I'm not sure I understand why you gave values to some of the variables.

By giving specific values to some of the variables, and then getting a free variable in solve's solution of the reduced system, Acer shows that there are an infinity of solutions to the original system.

• if you decided that r13=0, r23=0, r31=0, r32=0, r33=1, It means that the rotation matrix R=[r11 r12 r13; r21 r22 r23; r31 r32 r33] is actuall a rotation around the z axis (and also more possible matrices for the case that det(R)=-1). there are of course infinite such rotations.

• Are you saying that there are infinite solutions? because I'm pretty sure there should be finite number of solutions to my original problem.

Your two paragraphs above seem contradictory: The first admits that there may be an infinity of rotations allowed by your system; the second denies it.

• I didn't understand the last row of zeros (still new with Maple).

This shows that the whole infinitude of solutions given by solve taken with Acer's initial assignments do in fact satisfy the original system. In other words, the residuals are exactly zero.

Do you have some name or reference for the algorithm that solves any system of polynomials (numerically)?

@David1 The thumb-up thing is a ridiculous (*footnote) bug. Thumbing-up has in reality required 15 (or at least more than 10) reputation points for years, even though it is claimed to only require 10. The same thing applies to the potential-spam flag that appears on your posts: They should go away when you get to 10, but they actually don't go away until you're over 10. Someone must've mixed up "less than" and "less than or equal" in the code.

Anyway, I just upped your reputation to 15, so feel free to give Tom that thumbs-up.

(*footnote): It's ridiculous because it's been around for so long---through several updates of MaplePrimes code---yet it's so easy to fix.

I've always found it confusing that Maple's two-argument arctan requires the imaginary part as the first argument and the real part as the second argument. To my intuition, that's reversed.

This looks like a very major bug (*footnote). My very preliminary testing shows that the bug is manifest only for small P ( < 0.1), and that it still occurs even if one tries to workaround by using option method= discrete to Statistics:-Sample.

There's no need to compare to results from the Geometric distribution. It is obvious simply from your Sample of the NegativeBinomial that there is a bug.

*footnote: It's a very major bug because it produces results that are grossly numerically wrong apparently for only a small range of parameter values.

@Adam Ledger What you are calling "mod", as in Knuth's definition, is performed in Maple by irem (integer remainder). Maple's mod is a whole computation environment which is an extreme generalization of this, allowing for finite fields, polynomials and matrices over them, and other algebraic structures. If you just want to compute integer remainders as is done by "mod" in some other languages, then I suggest that you completely forget about Maple's mod and use irem instead.

Please provide more details. Are you trying to build an HTTP calculator that uses Maple? Or are you trying to interact, from within Maple, with such a calculator that already exists?

@Preben Alsholm

I had mixed up realcons with numeric. The relevant difference is that Pi is realcons but not numeric. If you wish to retain the style of my procedure, which you say is elegant, then you can get the evalf in there by using it in a coerce parameter modifier, like this:

at:= (x::coerce(numeric, evalf), yy)->
   if [x,yy]::list(numeric) then 
      `if`(x=0, Pi/2, arctan(yy/x) + `if`(x<0, Pi, 0))
   else
      'procname'(_passed)
   end if
:

@awass The only practical difference between Preben's procedure and mine is his use of evalf.

@Giulianot 

DirectSearch:-SolveEquations will allow arbitrary inequalities, and fsolve will allow variables to be restricted to ranges.

@Giulianot The inclusion of the output from every command in your worksheets does not add much useful content to the posts, and that voluminous output makes the posts difficult to read and scroll through. So, I request that you use menu commands Edit -> Remove Output -> From Worksheet before posting.

@gaurav_rs The choice of algorithm is often restricted by the type of the most-complicated coefficient (worst case) rather than by the average case. In your case, would that be a rational function in two variables (p and q) with rational-number coefficents? You mentioned algebraic numbers. Do you have any that are not rational (such sqrt(2))?

On the other hand, the efficiency of the algorithm (both speed and memory) is often greatly influenced by the average case of the coefficients.

If your worst case is a rational function in two variables with rational-number coefficients, and you have no irrational numbers, then I'd guess that it could be done in a few minutes for n=300 (just guessing).

What type of coefficients do your equations have? rational numbers? algebraic numbers? polynomials? There are many solution methods in the LinearAlgebra package. The efficiency of the solution is usually greatly influenced by choosing an algorithm that's appropriate for the coefficient type.

@tolliob Is the phenomenon reproducible? If not, then it may have been due to a big garbage collection from your prior computation.

@Mac Dude As I said above, the previous approach (described in section 8.6) only allows for one overload (or rebind) of an operator to be in effect at a time. Plus, you're forced to use with or a use statement to get that single rebind. IMO, that's an onerous restriction for which the object approach is a major improvement.