@ What can be done in evalhf or compiled code is extremely limited. In particular, there are no lists, sets, tables, or symbolic varaibles. There's no point in encouraging such usage because then there'd be little point in using a CAS.

@taro 

The expression x^(2*a) is a function composition of the form f(x, g(2, a)). All such cases are handled by expand, to whatever extent they've been programmed in. In particular, see showstat(`expand/power`).

The order that factors are placed in a product or whether extra parentheses are used makes no difference to Maple: The expressions are seen as exactly the same. Indeed, the expressions are identical and stored at the same address, so there's only one copy kept.

However, the ability to use subs or eval for this problem, is, as I pointed out earlier, based on a quirk of the internal representation. That internal representation has changed in the past, and it may change in the future. Thus, I wouldn't rely on a method that uses subs or eval. You are right to worry about it. The subtlety of this issue shows why it can extremely difficult to maintain backwards compatibility.

Yes, some algebraic simplifications are more tedious with Maple than with a pencil. But with Maple the chance of making a mistake is close to 0.

@Kitonum The applyrule method is great. Vote up!

@taro Thank you. I'm sorry that my technique is so complicated. Kitonum's first method is simpler but only works because of a lucky quirk in Maple's internal representation of expressions: The 2 is stored separately from the rest of the exponent. I think that Kitonum's second method, using applyrule, is the best alternative.

@Kitonum I considered trying what you did, but I decided against it because I didn't think that ex was a syntactic subunit of the exponent. Notice that it doesn't appear in indets(e, anything). However, looking at dismantle(e), I can see that it is. It's the PROD(5) on line 5, and it's distinct from the coefficient 2 on line 20.

SUM(5)
   POWER(3)
      NAME(4): g
      SUM(3)
         PROD(5)              #This is ex
            SUM(7)
               NAME(4): sigma
               INTNEG(2): -1
               NAME(4): k
               INTPOS(2): 1
               INTPOS(2): 1
               INTPOS(2): 1
            INTPOS(2): 1
            SUM(5)
               INTNEG(2): -1
               INTPOS(2): 1
               NAME(4): sigma
               INTPOS(2): 1
            INTNEG(2): -1
         INTPOS(2): 2            #This is the coefficient 2
   INTPOS(2): 1
   PROD(3)
      NAME(4): tau
      INTPOS(2): 2
   INTNEG(2): -1

@ Okay, good point. Yes, the semantics of

y[index]:= anything;

differs depending on whether y is a mutable or immutable container. Lists and sets are immutable containers; tables and rtables are mutable containers. It's impossible to change the contents of an immutable container. Any attempt to change the contents results in the creation of a new container with copied and modified contents. The failure to understand this is probably the number-one cause of inefficient Maple code. Maple shouldn't allow the statement above when y is a list, but it does, begrudgingly, and only if y has fewer than 100 elements.

In your most-recent example, it's important to realize that it's not the statement y:= x that causes the list to be copied! It's the statement y[2]:= 3 that makes the copy. This can be verified like this:

restart:
addressof~([x,y]);
     [18446744792117435038, 18446744792117435070]

x:= [1,2,3]:  addressof~([x,y]);
     [18446744792119857038, 18446744792117435070]

y:= x:  addressof~([x,y]);
     [18446744792119857038, 18446744792119857038]  #x and y point to the same object.

y[2]:= 3:  addressof~([x,y]);
     [18446744792119857038, 18446744792119860222]  #x and y point to different objects.

So, regardless of whether x is a Matrix, a list, a name, or just a scalar, the statement y:= x never makes a copy of x; it just makes a new pointer to an existing object. It's behavior is consistent.

What you want to do is very easy with { }, fsolve, and select. But before I show you how to do that, I need to know what you mean by "function value at a root is positive." By the definition of root, the function value at a root is 0.

@MAHMOUDHM Yes, I saw your update. Please make as many changes as you can regarding the advice that you've already received here and, as Acer said, post your update in this thread.

I saw that you made changes regarding my first four points, but that you kept the pi. That was disappointing.

@ Your first sentence got cut off because of the stringent length restriction of the titles of Replies.

Anyway, yes, okay, there's a difference when the left operand of := is subscripted, which I mentioned with my y[..]:= example. Subscripting the left operand doesn't really apply with scalars. Okay, you're substituting concatenation for subscripting; I see the analogy, but I think that it's stretched thin: x[1] and x[2] are two objects in the same container, whereas x1 and x2 are separate containers.

Does it seem to you that Maple is different from any other programming language in this regard? It's been a long time since I've used another language extensively.

@hillbilly True zooming can be done with the viewpoint option to plot3d, and any 2d plot can be done in plot3d. See this Question: http://www.mapleprimes.com/questions/201992-Zoom-Animation-With-Time

@Vic For each of the three systems that you've posted, I get equivalent results from all three methods (msolve, Linsolve, and LinearAlgebra:-Modular-LinearSolve) as shown in the worksheet that I've posted below. If you think that you're getting different results, please post a worksheet showing that. You can use my worksheet as a model for the correct usage of the three solution methods.

Download mod2_sys.mw

@ I don't see any inconsistency. You can do the same thing with Matrices:

x:= <2>:  y:= x:  y:= <3>:  x;

and x will still be <2>. Compare with

x:= <2>:  y:= x:  y[..]:= <3>:  x;

Now x will be <3>.

@Vic What did you do to confirm that this system has a solution? For me, neither msolve nor Linsolve return a solution.

There is no way to send the evaluation procedures to Excel, which couldn't interpret the Maple code anyway. But if you want to send four lists or vectors of y values to Excel, that can be done. In that case, I need to know the ending value of t and the step value of t.

Dr. Subramanian: Your comment makes absolutely no sense to me unless I suppose that you meant to say 2D input rather than 1D input.