The fact that the options stepsize and minstep exist suggests that there are known to be cases where they are needed to get accurate results. 

@RohanKarthik 45*x does not satisfy the condition degree(..., x) - degree(..., y) equals 0 or -1.

@Yiannis Galidakis When y is integer, there are many variations possible for the depth of the evaluation. One possibility is to have hy(5, 2, 4) return 2^(2^(2^hy(4, 2, 65533))). Of course, you want to avoid towers of exponents that are too tall to display.

@Yiannis Galidakis The following should work in Maple 13. It only took me 5 minutes to make the changes.

`print/%^`:= (a,b)-> ``(a)^b:
`print/%*`:= (a,b)-> ``(a)*``(b):
`value/%^`:= `^`:
`value/%*`:= `*`:

hy:= proc(n, x, y)
    if n=0 then y + 1
    elif n=1 then x + y
    elif y=0 then 1
    elif y=1 then x
    elif n=2 then `%*`(x,y)
    elif n=3 then `%^`(x,y)
    elif n=4 then 
        if y::posint then `%^`(x, procname(4, x, y-1))
        else `%^`(x, 'procname'(4, x, y-1))
        fi
    elif [n,y]::list(posint) then procname(n-1, x, procname(n, x, y-1))
    else 'procname'(n-1, x, 'procname'(n, x, y-1))
    fi
end proc
:
hy(4, 2, 4);
value(%);
                             65536

@Yiannis Galidakis Your code in the Reply immediately above makes no distinction between numeric and symbolic y, and thus I can't see how it addresses your Question about recursion. Rather than retrofitting my code to Maple 13, it seems like you're ignoring its most important features.

For how long will you be stuck with just Maple 13?

Like I've told you before: When you say that something is not working, show an example of it not working, not just an example of it working! It's okay to show an example of it working if in addition you show an example of it not working.

@dharr Note that in the case of GaussianElimination and LUDecomposition and other "solver" commands, FractionFree refers to the workings of the algorithm, not its output. The output may necessarily contain fractions.

@Scot Gould This issue is caused by an unfortunate ambiguity in the syntax for DataFrame indexing. They can be indexed with positive integers as if they were matrices, or they can be indexed by labels. This causes problems when you use labels that can be mistaken for ordinary indices.

@Ali Hassani Yes, but that lacking in Maple has nothing to do with symbolically solving a single equation or a single system of equations since (as far as I know) there doesn't mathematically exist any parallel algorithm to do it! If the algorithm exists, it is very likely that it can be implemented in Maple.

If you wish to apply the parentheses-adding operator `` to all the items of a list L (of polynomials or anything else), you can do ``~(L). 

@Hitch_Hawk You're welcome, and please don't hesitate to ask other similar questions.

To use a shooting method, there must be two boundary points, and the differential order must be at least two.

@Hitch_Hawk I don't want to confuse you, but don't take your statement "Procedures are the whole equations, while functions are just parts of it" too literally. They're both much more specific than that. A procedure is either of the form proc(...) ... end proc or (...)-> .... The body of the procedure can contain many equations, formulas, loops, conditionals, all the usual stuff. A function is an essentially inert object exactly of the form that I described, and it might not have any mathematical significance.

I think that the contrast that you're trying to make should be between procedures and algebraic expressions. For example x + sin(x) and sin(x) + cos(y) both have type algebraic, but they are not functions (in the formal Maple sense (I use boldface to indicate that I mean this special sense.)). (Once again, Maple's formal usage of algebraic is somewhat idiosyncratic. Neither of those examples are algebraic functions in the mathematical sense.) 

Newton:= proc(f::algebraic, x::(name= complexcons), n::posint)
local Df:= unapply(f/diff(f, lhs(x)), lhs(x)), x1:= rhs(x);
    to n do x1:= evalf(x1 - Df(x1)) od;
    x1
end proc
:
Newton(x^2-2, x=1, 9);

Thanks for the "Best Answer". You'll need 11 or more points to Vote Up; the documentation is wrong about that. But a "Best Answer" gives me more points than a Vote Up anyway, and they don't add together.

Your instructor's advice to always include a decimal point in the initial approximation is not always adequate to ensure that the computations are done in floating point. To be sure, you should use evalf in the update line:

x1:= evalf(x1 - ...);

And, if you do this, then it's not necessary to use the decimal point.

The consequences of not doing the computations in floating point are called expression swell, and it can use up all your memory in surprisingly few iterations.

@mapleatha Note that my Answer agrees with nm's: There is absolutely no programmatic reason to add parentheses. They are not needed to pass the polynomials as arguments to another procedure, and there's no way to add "just" parentheses: they can only be added as ``() or something like that. The only reason to add parentheses is if you want the expressions to be displayed with extra parentheses.