Nearly every day I have some situation where I need to manually terminate an mserver.exe, so specific cases where this happens are hardly worth mentioning. The design flaw is that interruptions don't work while kernel code is executing.

@vv I think that kernel and external code can't be interrupted. In other words, interruptions can only occur while transitioning from one Maple-level statement to another. Nearly all floating-point evaluations of transcendental functions pass the job off to the kernel procedure `evalf/hypergeom/kernel`.

@Kitonum You're missing a parse command. The final result should be a list of two-element lists.

@erik10 For the word in your language, did you include the extra space and backquotes, like I did? So, I used `Slope `, not `Slope` or Slope.

@Carl Love My Answer above is wrong, and those who gave it a thumbs up should retract them. The set {unames()} doesn't necessarily contain the prefixes; it merely coincidentally contained them in the cases that I tested. I've thought of a way to correct this, which I'll post later today; I need to go to sleep now.

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.