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.

Why do you say that the result that Maple returns is wrong rather than being simply an alternative form of your preferred result? I agree that if I do the integral "by hand" using standard first-year calculus techniques then I get your form. But the two forms are equivalent if you allow negative arguments to ln (which Maple does allow). The imaginary parts cancel for 0 < x < 4. For x = 4, take the limit of Maple's form as x -> 4.