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

@radaar Sure, you could use map for this. In this case, I thought seq looked better aesthetically.

@Ali Hassani This is not a limitation of Maple. As far as I know, the parallel algorithms simply don't exist, but I haven't researched that. If you can find an appropriate algorithm, I will help to implement it in Maple.

There is a Maple-specifc parallelism limitation, but it doesn't apply to the situation that you're describing. The limitation is that many Maple commands were originally written without parallel programming in mind; they use global variables in ways that are incompatible with shared-memory parallelism, and it would require a massive effort to rewrite them. This does not mean that those commands can't be used in parallel. Rather, it means that they can't effectively be used for shared-memory parallelism such as that provided by the Threads package.

I deleted the Question that you asked a few minutes ago because it's essentially a duplicate of this one. Also, these Questions are about Maple alone; don't put it in other categories such as MaplePrimes and MapleLearn. 

Maple's laplace command works primarily by table lookup rather than by integration. Perhaps the problems that you're having show why it was done that way. It's possible for a user to add to the tables for any of the transforms in inttrans. See help page
?inttrans,addtable. 

@pengcheng Xue It's not strange at all; I've seen it hundreds of times. The convergence of Newton's method is sensitive to initial conditions. This is even true (and easy to illustrate graphically) when using it to solve a single algebraic equation in one dimension.

@MapleEnthusiast This is such a trivial modification to my Answer above that I must insist (for pedagogical reasons) that you try to do it yourself. If you've failed after repeated attempts, ask again and I'll show you.

Hint: seq, add, and mul are essentially the same command with the same syntax. The only thing that changes is the associative operator used: add is addition, mul is multiplication, and seq is concatenation with a comma.

In my opinion, I'd modify acer's "Using concatenated names in procedures is poor programming practice" to "Using concatenated names as variables in procedures is poor programming practice". Perhaps acer will agree with this modification. Names are often constructed essentially as strings to achieve a certain displayed effect. It's often impossible to make these local due to the need for concatenation, and there's often no other way to get the displayed effect.