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

@John SREH In that case, simply change Preben's next to break. This'll end the loop cleanly rather than going to the next value of the loop index.

By the way, it looks like you're numerically integrating (the square of) a numeric dsolve solution. You can get dsolve to do that for you, which'll give you much better error control. I'll expand on this in an Answer below.

@Rouben Rostamian  The command InertForm:-Parse will take an infix expression entered as a string and return an equivalent prefix expression (not as a string). That's most of the work. From there, you can change all `%+` and `%*` to exactly two operands per operator, move the operators to the ends, and remove the parentheses.

I just have some quick and immediate thoughts about this. It's been less than 5 minutes since I started reading this post, so my ideas are not fully formed.

It seems that this RPN requires that each operator have a fixed number of operands. That means that a distinction must be made between unary negation and binary subtraction. These are different keys on most pocket calculators but not in the standard alphabets used for most computer languages, including Maple.

What makes you say that it'll speed up evaluation? I certainly see that RPN can speed up the manual entry of expressions. But all expression evaluations AFAIK are already done with stacks.