If you really want to do it in a manner similar to your original posting, then something like this might work for you. I had to guess at the assignments to B12 and B13 as they apparently got chopped off in your original (posted as HTML rather than plaintext I surmise). B11:=x1<=B1 and x2<=B2; E11:=0; B12 := B1>=x1 and B2>=x2; E12 := simplify(int(int(x1-h1+x2-h2,h2=B2..x2),h1=B1..x1)); B13 := B1<=x1 and B2>=x2; E13:=simplify(int(int(x1-h1+x2-h2,h2=B2..U2),h1=B1..x1)); Eobj:= proc(X1,X2) local z; z := map(eval,`if`(B11,E11,0)) + map(eval,`if`(B12,E12,0)) + map(eval,`if`(B13,E13,0)); z := eval(z,{x1=X1,x2=X2}); end proc; B1:=0;U1:=1;B2:=0;U2:=1; eval(Eobj(x1,x2),[x1=-10,x2=-10]); Eobj(-10,-10); plot3d(Eobj,-10..10,-10..10); #plot3d(Eobj(x1,x2),x1=-10..10,x2=-10..10); I feel a bit guilty posting this, as it contains all manner of sins. And I'm not completely sure that it does what you intended. Also, notice that Eobj(x1,x2) will return something possibly useful to you while Eobj(a,b) will produce an error. You might be better off studying Robert's response and changing your approach accordingly. I have an idea that, even if the code above does do what you want, the reasons for it might appear confusing. acer

Could plots ever be passed back and forth from GUI to kernel? Would bidirectional communication of plot structures not allow for both programmatic and graphical interface (eg. mousy) access? Actually, why pass the whole structure back and forth, instead of some pointer to it? And, if that isn't a bad idea, then why wouldn't it have been done years ago? Couldn't this give the first glimpse of CAD functionality? Why can the user now annotate plots, but not get any programmatic access to those effects? acer

That's a quite correct and expected observation, no? In (1D) Maple Notation, the caption is not yet a typeset object. The kernel (even its parser) has not yet seen it. It gets handled in the usual way for Maple, which means that as an argument to plot() it is evaluated prior to being bound to any (local) formal parameter of plot(). The plot() routine does not have special evaluation rules, I believe. So evaluation (and automatic simplification too) are not preempted here. In 2D Math input, the toggling of parts of the caption as "atomic identifier" means that those contents aren't really Maple symbolics as they seem. The typesetter forms them (as something similar to MathML). But the resulting object cannot be manipulated by Maple as a mathematical symbolic object in that state. It's more like an inert piece of display mark-up. The Std GUI knows how to render it nicely, but Maple's kernel sees only a big, strange looking name, I suspect. And that's why one can use the atomic identifier trick to avoid evaluation or even automatic simplification, because the kernel just sees one big name. acer

Couldn't it be trickier than just normalization? What about linear combinations of eigenvectors associated with the "same" eigenvalue? If what's wanted are approximately the same results (across platforms, compilers, implementation platform, optimization flags, etc) then maybe that which will always suffice is always to choose some desired orthogonal basis, project, and normalize. acer

Fabulous. Thanks very much. I knew about that atomic identifier context-menu item, but I wouldn't have imagined to try it within the plot call. Its acting in-place on the input is what makes it work, it seems. It's obviously a very handy mechanism -- that in-place atomic identifier context-menu toggle -- so perhaps it could be more widely referenced in help-pages that refer to 2D Math. acer

I too would like to know the answer to this -- how to get the volume of revolution to be solidly filled. Maybe there is some simple answer. A good solution would be something that would truly look filled, were it transluscent. By that I mean that faking it (say, by assigning the VolumeOfRevolution plot to a variable and then displaying both that and two additional plots of the end-discs) would not always look truly filled. I had first imagined that the following command might do it, Student[Calculus1][VolumeOfRevolution](1/x, x=1 .. 2,axis= 'horizontal', volumeoptions=[filled=true], showfunction=false, 'distancefromaxis' = 0, 'output' = 'plot'); acer

I too would like to know the answer to this -- how to get the volume of revolution to be solidly filled. Maybe there is some simple answer. A good solution would be something that would truly look filled, were it transluscent. By that I mean that faking it (say, by assigning the VolumeOfRevolution plot to a variable and then displaying both that and two additional plots of the end-discs) would not always look truly filled. I had first imagined that the following command might do it, Student[Calculus1][VolumeOfRevolution](1/x, x=1 .. 2,axis= 'horizontal', volumeoptions=[filled=true], showfunction=false, 'distancefromaxis' = 0, 'output' = 'plot'); acer

It seems that there are restrictions here. I am able to add formatted 2D Math output to a plot caption, but not 2D Math *input*. For example, suppose that I do as stated and enter the entire plot command as 2D math. I enter the rhs of caption=ZZZ as, 2 (x+y) Can that be formatted in 2D Math (as it certainly is, as 2D Math input), without the full evaluation that then produces 2 x + 2 y in the caption? I can of course use name-quotes to fake this simple example, but that becomes problematic if the expression is not so simple. There are other examples. In a Document, I can enter mathematical syntax that needn't neceesarily evaluate OK in Maple. One decent reason to do this is for the purpose of discussing mathematics outside of the limited scope of Maple. I can enter, as 2D math input surrounded by text, 1/0 and not get an evaluation and the subsequent division by zero exception. How can one get a 2D Math typeset 1/0 (not faked with name-quotes so it looks like lprint'd input)? acer

That's not an unreasonable guess, that Array might be related to array in that way. But it's not the case. Indeed, calling Array() shows that it is not the inert form of array(). Since it "does" something, it's not inert. An array is a table-based structure with the particular property of having the indices be integers. Maple tables, on the other hand, can be indexed by almost anything. So an array is a special kind of table. The command matrix() and vector() are conveniences, to allow creation of 2D and 1D arrays whose index ranges start at 1. And since arrays are tables, then matrices and vectors are tables too. In Maple, tables follow so-called last-name evaluation, see ?last_name_eval . This behaviour allows them to be passed as arguments to a procedure without having their contents be fully evaluated. This is quite useful. They are of course a mutable datastructure -- their contents can be changed in-place without effecting a full copy of the whole structure. (The Maple list is the opposite, and assigning "into" a list is very inefficient.) So, tables, arrays, matrices, and vectors all have last-name-eval (as it's known for short...). This is why you'll often see somthing like eval(a) at the end of routines that deal with matrices and arrays, so that the actual table is returned (as opposed to, say, the local name which might actually be the "last name"). The last-name-eval property can sometimes cause some difficulties. There's even a joke name for some such situations, last-name-evaluation-disease (lned). On the other hand, last-name-eval solves some matters brilliantly. See my other reply, for a description of rtables, Arrays, Matrices, and Vectors. Those objects, in contrast to tables, do *not* have last-name-eval. The older package linalg is for matrices and vectors, while LinearAlgebra is for Matrices and Vectors. The difference in evaluation rules can make translating a linalg-based user-authored routine to be LinearAlgebra-based a bt tricky. See ?examples,LinearAlgebraMigration . ps. No jokes about "ert" being the opposite of inert, thanks. :) acer

There are several misunderstandings evident in that comment. As a general rule, Maple evaluates arguments before passing them to procedures. That is, before they are bound to the procedure's formal parameters. So this command solve(y = 1^(1/3), y) will receive y=1 as its first argument, because 1^(1/3) evaluates to simply 1. Procedures in the Maple Library which delay this evaluation, by default, are said to have special evaluation rules. See ?spec_eval_rules for more details on that. I don't know where in the help-pages the standard (non-special) evaluation rules are described. But you example also has another problem. Let's change it slightly to solve(y = x^(1/3), y), to avoid the evaluation problem mentioned above. Look at it harder. The equation is already an explicit formula for y. It doesn't make sense to ask more of it. And lastly, y^3=x is not the same as y=x^(1/3). acer

There are several misunderstandings evident in that comment. As a general rule, Maple evaluates arguments before passing them to procedures. That is, before they are bound to the procedure's formal parameters. So this command solve(y = 1^(1/3), y) will receive y=1 as its first argument, because 1^(1/3) evaluates to simply 1. Procedures in the Maple Library which delay this evaluation, by default, are said to have special evaluation rules. See ?spec_eval_rules for more details on that. I don't know where in the help-pages the standard (non-special) evaluation rules are described. But you example also has another problem. Let's change it slightly to solve(y = x^(1/3), y), to avoid the evaluation problem mentioned above. Look at it harder. The equation is already an explicit formula for y. It doesn't make sense to ask more of it. And lastly, y^3=x is not the same as y=x^(1/3). acer

There are some very nice routines in the ArrayTools package. Eg, DataTranspose, Permute, Reshape, etc. But I would also say this: when it comes to permuting and reshaping and rearranging an Array (or rtable), always ask hard whether it really needs to be done. Do you really need the new object, since it takes up memory? Or can you just access the elements according to some formula. Don't transpose A if you can access the entries with the A[i,k,j] syntax in your code. There will still be some situations where you want to actually produce the new transposed object. For example, to pass it externally. Or the decision might come down to how often you need to access the entries. If it's just for a few entries, just once, then access them "formulaically". If you need them all, many times, then creating the new object will remove the overhead of duplicated application of the transforming index forumla or indexing function. It's a bit like rtable indexing functions with *no* (empty) storage. Such an Array or Matrix can have its entries computed only on demand. Which is cool, up to the point that the overhead of calling the indexing function swamps the performance. This is part of an age-old dichotomy, space vs speed. On a related note, wouldn't it be nice if more LinearAlgebra commands accepted transposition flags on their rtable arguments. If so, then one could compute say, A^%T . B without having to actually form A^%T at all. ps. For a lot of fun learning, try ?rtable_ and study the many help-pages for low-level rtable handling. acer