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

It is not a rational function (one polynomial divided by another), and thus it's not clear what is meant by "proper" fraction (one whose denominator has greater degree than its numerator).

I see no relationship between your Question and its title, "Numeric Formating". What did you mean?

@omkardpd Please post the code in which this happens.

@Earl Your worksheet won't upload because of special characters in its filename. I recall seeing a semicolon in it. Try making it something simple like RiverCrossing.mw.