Sorry, I didn't explain well what I meant to convey. The help-page ?$ mentions that one may have to be careful due to possible (unwanted) premature evaluation when using $. It seemed to me that that warning would be better if it were accompanied by more examples. Take the concatenation example. In that case, the x and the i are being concatenated prematurely, before maple instantiates i at value 1 and 2. Hence one gets xi,xi instead of x1,x2. In the case of mutable objects like tables or rtables (eg. Vectors), only one instance of the object will be created, even if it is repeated or assigned to multiple names. It's the same cause, that the object is created by an evaluation that happens prematurely (before the instantiation of i). By (careful) use of unevaluation quotes, one can delay the evaluation of the expression until after each instance is created. > (x,y) := Vector(1) $i=1..2: > x[1]:=17:x[1],y[1];evalb(x=y); 17, 17 true > (x,y) := 'Vector'(1) $i=1..2: > x[1]:=17:x[1],y[1];evalb(x=y); 17, 0 false I too prefer not to use $, unless the circumstances are very simple. I find that the efficiency gained over using seq() is irrelevant compared to the extra care which is needed to be kept in mind. acer

Yes, your M1 and M2 are the same object. > evalb(M1=M2); true This is not specific to rtables. It relates to lack of usual evaluation of the expression when using $. Other examples, > i $ i=1..2; 1, 2 > x||i $i=1..2; xi, xi > cat(x,i) $i=1..2; xi, xi > (x,y) := table([]) $i=1..2: > x[foo]:=bar: > y[foo]; bar It would be good if this were mentioned on the ?$ help-page. As it is, there is only mention of a side-issue, that uneval quotes may be necessary to avoid premature evaluation. acer

One can follow what happens, in the debugger. Below, I followed some of what happens for the example solve(abs(-sin(x)/x+1) = 1, x). One routine in which action takes place here is `solve/rec2`. It sets up a SYSTEM, first, as, [[{abs(-sin(x)/x+1) = 1}, {}, {x}, {}, true, false, 1, {x}]] Then, it makes calls to SolveTools:-Transformers[i] on SYSTEM. The transformers, i, which seems to affect this example include Abs and Inequality (I think). The Abs Transformer turns SYSTEM into this, [[{z+sin(x)/x-1, z-1, 0 < z}, {}, {x, z}, {}, true, false, 1, {x}], [{z-sin(x)/x+1, z-1, 0 < z}, {}, {x, z}, {}, true, false, 1, {x}], [{z+sin(x)/x-1, z, z-1}, {}, {x, z}, {}, true, false, 1, {x}]] The Inequality Transformer then turns it into this, [[{z+sin(x)/x-1, z-1, 0 < z}, {}, {x, z}, [{z = 1, x = 0}], true, true, 1, {x}], [{z-sin(x)/x+1, z-1, 0 < z}, {}, {x, z}, [{z = 1, x = 0}], true, true, 1, {x}], [{z+sin(x)/x-1, z, z-1}, {}, {x, z}, {}, true, false, 1, {x}]] That SYSTEM finally gets passed to SolveTools:-MakeSolutions, which returns [{x = 0}, {x = 0}]. One would have to know what the members in the system format mean, to know whether either Transformer is doing something unjustified. One could also follow it into SolveTools:-MakeSolutions, but I haven't done that.. acer

> fsolve(sin(x)/x-1=0,x=Pi); 0. That's not so good. acer

In Maple 11.00, > restart: > s:=solve(x^3-3*x+1 = 0): > seq(is(convert(i,trig), 'real'), i = s); true, true, true However, one can still confuse is(), even to the point of a spurious false instead of FAIL, > is( simplify(radnormal(rationalize(s[1]))), real); false In this example, there is also this form of s[1], which is clearly real, > simplify(convert(s[1],trig),trig): > lprint(%); 4^(1/2)*cos(2/9*Pi) > seq(simplify(eval(x^3-3*x+1,x=simplify(convert(i,trig),trig))),i=s); 0, 0, 0 There'll be room for a long time, for strengthening is() and simplify(). acer

In Maple 11.00, > restart: > s:=solve(x^3-3*x+1 = 0): > seq(is(convert(i,trig), 'real'), i = s); true, true, true However, one can still confuse is(), even to the point of a spurious false instead of FAIL, > is( simplify(radnormal(rationalize(s[1]))), real); false In this example, there is also this form of s[1], which is clearly real, > simplify(convert(s[1],trig),trig): > lprint(%); 4^(1/2)*cos(2/9*Pi) > seq(simplify(eval(x^3-3*x+1,x=simplify(convert(i,trig),trig))),i=s); 0, 0, 0 There'll be room for a long time, for strengthening is() and simplify(). acer

A good prize would be something of value to the recipient. Of course, it's difficult to guess in advance what will be of value to any of a group of relatively unknown people. But one thing that the especially good mentoring contributors on mapleprimes might share as a valuation is a high regard for properly working maple. Maybe a valuable prize would be a promise of a bug fixed in the next major release, of the recipient's (reasonable) choice. acer

Converting gamma to a local is not easy if it's not obvious or well-documented enough for new users to discover it. Suppose that one wants to be able to get the nice typeset 2D Math greek symbol for gamma to appear (and be used as a variable) in 2D input regions. How would one do that, precisely, after the convert(gamma,`local`) assignment to vargamma? acer

Converting gamma to a local is not easy if it's not obvious or well-documented enough for new users to discover it. Suppose that one wants to be able to get the nice typeset 2D Math greek symbol for gamma to appear (and be used as a variable) in 2D input regions. How would one do that, precisely, after the convert(gamma,`local`) assignment to vargamma? acer

It should be easy for Maplesoft to allow support for a nice 2D typeset symbol which can be used as a variable even when the maple system already uses the name somehow. The user should not have to unprotect the name in order to do this, since in general that may cause the maple engine untold problems. For example, it should be possible to teach maple to typeset, say, vargamma as the 2D greek symbol in maple input and output. The same thing should go for 2D typeset Pi, which some branch of science may wish to use as a variable name. The extension prefix "var" may not be a good choice, as it is already used to distinguish two forms of symbol epsilon. But all that ought to be needed is some convention that is simple, consistent, and documented in order to give these 2D symbols safely back to the user as variables. acer

It should be easy for Maplesoft to allow support for a nice 2D typeset symbol which can be used as a variable even when the maple system already uses the name somehow. The user should not have to unprotect the name in order to do this, since in general that may cause the maple engine untold problems. For example, it should be possible to teach maple to typeset, say, vargamma as the 2D greek symbol in maple input and output. The same thing should go for 2D typeset Pi, which some branch of science may wish to use as a variable name. The extension prefix "var" may not be a good choice, as it is already used to distinguish two forms of symbol epsilon. But all that ought to be needed is some convention that is simple, consistent, and documented in order to give these 2D symbols safely back to the user as variables. acer

If one wishes to use maple to do such mathematics then it helps to understand its conventions. Compare, sols:=seq(RootOf(_Z^5+1,index=i),i=1..5); evalf(sols); with, x:= (-1)^(1/5); convert(x,RootOf); This should illustrate how maple considers (-1)^(1/5), as the first 1/5th root of -1 going counterclockwise from the positive real axis. Maple needs a convention for such things. It's pretty natural to talk here on mapleprimes with maple's conventions in mind. In that context, I think that I'm correct when stating that (-1)^(1/5) is not real. That's maple's default. For more explanation, see the sections on principal roots at, http://mathworld.wolfram.com/CubeRoot.html http://en.wikipedia.org/wiki/Nth_root There is a mechanism in maple which allows some operations to take place with only the reals in mind. Eg, with(RealDomain): x:= (-1)^(1/5); acer

If one wishes to use maple to do such mathematics then it helps to understand its conventions. Compare, sols:=seq(RootOf(_Z^5+1,index=i),i=1..5); evalf(sols); with, x:= (-1)^(1/5); convert(x,RootOf); This should illustrate how maple considers (-1)^(1/5), as the first 1/5th root of -1 going counterclockwise from the positive real axis. Maple needs a convention for such things. It's pretty natural to talk here on mapleprimes with maple's conventions in mind. In that context, I think that I'm correct when stating that (-1)^(1/5) is not real. That's maple's default. For more explanation, see the sections on principal roots at, http://mathworld.wolfram.com/CubeRoot.html http://en.wikipedia.org/wiki/Nth_root There is a mechanism in maple which allows some operations to take place with only the reals in mind. Eg, with(RealDomain): x:= (-1)^(1/5); acer

What you wrote, Robert, adds clarity to the Description section of the help-page ?module . Thanks. At first I found the eleventh paragraph of the Description in ?module somewhat mysterious, especially the references to mimicking procedure evaluation and an "invocation step". Perhaps it is during this invocation step that any encountered `return` statements cause the instantiation to stop. The statement in that help-page, "You can think of a module as the result of invoking a procedure that ``returns'' some of its local variables (its exported locals)" is interesting. But alongside the final form of body of the module, which as you say consists of assignment statements containing the "final" instantiated values of the variables, the statement seems unusual. The Description doesn't seem to me to fully describe what's going on, and what the consequences are. Perhaps the help-page makes it clear to everyone else. I think that some more illustrative Examples might improve it. acer

(-5)^(2/5) is not real and is not the same as - 5^(2/5) . acer