It seems to me that you are hoping to separate the printed intermediate results from the final displayed animation. Others have answered that you can do that using the Commandline Interface (CLI, or "TTY") by forcing the plot to its own desktop window (x11 or maplet or window plot devices, etc).

But it seems to me that you also ask whether you could instead change your Maple GUI methodology, again to separate the displayed animation from the intermediate results. My suggestions below relate to (essentially) giving your GUI document block or execution group its own rolling console. (I don't show buffered or scrolling console effects, but those too are possible.)

Here are some suggestions, to allow you to see intermediate statements or results in a timely way, with less clutter. This is just for the Standard GUI, not Classic.

- Put the code which computes and constructs the plot animation in the Code-Edit region inside a procedure, let's call it MakeAnimation.

- Now you can run that by calling MakeAnimation() in a document block or execution group of your worksheet. The return value is the animation.

Ok, now you'll be seeing something similar to your described current scenario in the Standard GUI.

One of your described problems is that every time you do this your document gets plastered with several progress statements or intermediate plots (individual frames from your animation, say). And it's not pleasant to have to delete those by extensive mouse-selection and/or scrolling, etc.

Another problem is that if you are in Document Mode and you are executing the command (MakeAnimation, say) in a Document Block then printing statements (via print, say) don't show intermediate progress until after the whole computation ends.

You can resolve both those problems using Embedded Components. Set up a TextArea component and (instead of using print) use sprintf and DocumentTools:-SetProperty to push the string into the TextArea component. Set up a PlotComponent and (instead of using print or plots:-display) use DocumentTools:-SetProperty to push any intermediate frame into that component. This can work quite nicely, but it requires that manually insert these components from one of the side-panel palettes. And the positions of these components is fixed in the document -- you have to cut and repaste them (or scroll) if you want to use them from a call to your code from much further down in your document.

Another, relatively easy, method is to use the DocumentTools:-Tabulate command to show such intermediate results. It can be use to show both plots as well as math expressions in a region immediately below the normal output area of a DocumentBlock or Execution Group. It won't work from within a Code-edit Region, I think, which is why at the start I mentioned putting your code inside a procedure. (Procedures are useful in other ways, too.)

Here is an example.  tab_examp.mw  It requires Maple 2015. (I used Maple 2015.2)

You could of course use Tabulate in different loops (stages) of your procedure. At an earlier stage you could use it to report on progress of some preliminary computations. And in a later stage you could use it to show only plot frames.

I have more involved examples that build custom assemblies of components using the DocumentTools:-Layout and DocumentTools:-Components from Maple 2015. They are more efficient at runtime. But for simple scenarios I've been getting some useful functionality out of the Tabulate command.

acer

The best way is to use the unambiguous form for entering your operator ("function") definition, eg,

g1 := x -> 2*x;

For your second question, are you looking for the unassign command?

acer

I see the same error if I (unwisely) try your code in 2D Input and choose "function definition" instead of "remember table assignment" when prompted by a disambiguation popup dialogue.

The easiest way to handle the situation -- if all you're trying to do is assign to entries of an existing Matrix -- is to use square brackets for your indexing instead. Ie,

n:=4:

for j from 1 to n-1 do  
P[j]:=Matrix(n); 
for l from 1 to n do 
P[j][l,l]:=1;  
end do; 
end do;

I don't understand why anyone would want to use () "programmer indexing" of Matrices when [] regular indexing would also work. It's so common that some bit of syntax which has ambiguous interpretation causes people run to into trouble.

So perhaps that'll remedy things for you.

Having said that, there are a few more points worth observing:

If you really did use that as 2D Input then please DON'T paste it into posts here as plaintext, ie, as if it were 1D code. 1D and 2D Maple input are like two distinct languages. It makes it unnecessarily hard to debug if the very choice of input mode is obscured in your post. Upload a .mw file if you want to show as example with 2D Input (2D Math).

The 2D Math parser doesn't do execution, so it doesn't know that the P[j] are going to be Matrices. If it did know that P[j] were Matrices then it wouldn't have to disambiguate at all -- the obvious interpretation is that of programmer indexing (which is neither remember table indexing nor operator assignment abomination). This is just another example of why it is poor that 2D Input has ambiguities in its syntax, and why dismbiguation dialogues are a poor attempt at working around such.

acer

These seem to work, for your example, in Maple 2015.2,

plot(unapply(fp,tt), 0..10, useunits);

plot(simplify(fp/Unit(W)), tt = 0..10);

The following also works, and gives the unit as the y-axis label,

plot(unapply(fp,tt), 0..10, useunits=[1, Unit(W)]);

acer

I'm not saying that natural sunlight contains light of the full spectrum, evenly spread out. (It doesn't.)  And I don't know what curve a rainbow follows, and how much of an arc (if circular, say).

So this is just one simplistic way to get a rainbow style effect.

I used Maple 2015.

with(plots): with(plottools): with(ColorTools):

P:=plot3d( ()->1, -1..1, 410..640, style=surface, grid=[100,10],
           color=proc(x,y) Color("HSV",WavelengthToColor(y))[1]; end proc,
           labels=[x,y,z] ):

display(transform((x,y)->[y*x,y*cos(arcsin(x))])(P),scaling=constrained,axes=none);

display(transform((x,y)->[y*x,y*cos(arcsin(x))])(P),scaling=constrained,axes=none,
        view=[default,100..640],size=[640,200]);

acer

Something to get you started with your "simple" procedure.

Download smthg.mw

acer

Regarding your first question, you can removed the big-O term from the result of the taylor command by converting to polynom. For example,

taylor( f(x), x = g, 2 );                 

                                                       2
                     f(g) + D(f)(g) (x - g) + O((x - g) )

convert( taylor( f(x), x = g, 2 ), polynom ); 

                            f(g) + D(f)(g) (x - g)

acer

It's a bug. I have submitted a bug report.

Attached in a revision to your document that includes a way to patch it (only tried against Maple 2015).

Note that the `shading` option appears to already be working OK, ie. not broken. It was the `color` option that was being ignored.

Download feildstr_modif.mw

acer

arctan(-1, -1);

                               3   
                             - - Pi
                               4   

The rtable_scanblock command can return the index (position) or value for both minimum and maximum values of Matrices, Arrays, and Vectors. It's been around since at least Maple 12. It may not be as fast as min[index] in Maple 2015.

Do you really want to know how to make all your code orders of magnitude faster? You don't seem to be making use of any facilities for performance in numeric computation in Maple. Ie, you're not using float[8] Matrices/Array, you use a great many small procedures with no inlining, you don't use evalhf or the Compiler or option hfloat, and so on.

acer

[Following your later edit to the Question:] It's easy enough to get from poly1 to poly3.

restart;

poly1:=(A*B/(A+B)+X)/(X+Y*X/(Y+X));

                            A B     
                           ----- + X
                           A + B    
                           ---------
                                Y X 
                           X + -----
                               Y + X

applyrule( (a::name*b::name)/(a::name+b::name)=f(a,b), poly1 );

                          f(A, B) + X
                          -----------
                          X + f(X, Y)

So that could leave getting from poly2 to poly1.

Hopefully I've interpreted your question properly.

If you can only obtain an explicit representation in terms of one of the two variables (and it's not the one you want...) then you could use the implicitplot command, or you could reflect the result from the simpler plot command about the line x=y.

The first of those ways is more straightforward to remember, but in (numerically) difficult cases the second approach can often produce a cleaner curve while taking less computational resources.

Here's an example. Note that special options like gridrefine are often needed to get implicitplot to produce as smooth a curve, in my experience.

impeq := x = sin(y) + y:

with(plots): with(plottools):

implicitplot(impeq,x=-10..10,y=-10..10,gridrefine=2);

display(transform((a,b)->[b,a])(plot(eval(x,impeq),y=-10..10)),labels=[x,y]);

Download refl.mw

acer

Please spend some more time thinking about all the responses you've received to your earlier, related Questions about these kinds of expressions involving very large exponents and round-off error.

forget(evalf);
Digits:=20:
evalf(y(99.6));
                                 270
                            -1 10   

forget(evalf);
Digits:=300:
evalf(y(99.6));
                          0.0184074142

acer

The vertical bar and the name sn are the result of using the extended typesetting mode. The value is the same in either case. It's the particular mode of prettyprinting (typesetting) of the output that differs.

Download sn.mw

It is possible to disable the typesetting of output on a function by function basis, using the RuleAssistant. Using the dropmenu in that popup assistant one can retain extended typesetting mode in general while changing the typeset look of function calls of particular names such as JacobiSN. I cannot recall right now whether I ever figured out how to do this entirely programmatically without using the popup. But without the means to do it programmatically then this functionality of the assistant seems not very useful to me, since I don't see how to enforce the per-function disabling of output typesetting upon reopening a worksheet.

acer

The result you see for n=5 is correct.

Your simplification of c1 is not strong enough to show that c1=120 when n=5. The result is larger and more complicated by default than that returned by linalg[cond], however. (See my followup comment below.)

I show that the exact LinearAlgebra:-ConditonNumber result is correct for n=5 below, by using an alternative ("stronger", for this example) simplification.

Download trigsimp.mw

acer

There is a collspased (hidden) Execution Group in the Document Block in the Table Cell in the 4th row and 3rd column.

That's the same row whose first column Cell contains "inclination angle of the swash plate".

The problematic Cell curretly shows a TextArea component whose current entry is "1.2".

To reveal it, use the mouse pointer and select the content of that Cell (or an larger selection that contains that Cell). Then, while it is selected, use the main menubar item View->Group and Block Management->Expand Document Block. After that the offending Execution Group will be visible, below the Execution Group that contains the TextArea.

Delete the problematic Execution Group, which contains a call to the Tutor. You can use Ctl-Delete for that. The Select the upper Execution Group's content (the TextArea), and use the menubar item View->Group and Block Management->Collapse Document Block.

That corrects the problem with the Tutor launching every time the sheet is executed in its entirety.

There is another mistake. The Action code on that TextArea component in the Cell in the 4th row and 3rd column contains some code. Right-click on it invoke the "Edit Content Changed Action..." popup menu item, so as to edit that code. The mistake is that it is missing the final end use; line.

acer