@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.

What do you mean by "the metrics"?

@Gillee You can pass almost anything to the inert command Sum, and it'll print it in summation notation on your screen. That's not computation, for which the sum (not capitalized) command is required.