You could use a nonzero transparency for the surface. Or you could use plottools:-transform to raise B to the surface (or use P_Pi2 for the third element of the spacecurve) instead of using it just as a background. Or plot B as a transparent cylinder. Or all of the above.

acer

I sometimes do this sort of thing as follows:

restart;

cav1 := proc (a)

     printf("degree = %f\n", a);

     printf("radian = %d\n", evalf((1/180)*a*Pi));

end proc:

cav1(260);
  degree = 260.000000
  radian = 
  Error, (in fprintf) integer expected for integer format

stoperror(lasterror);
            ["integer expected for integer format"]

And now when I call cav1(260) once again the debugger stops at the problematic line, which happens to be in fprintf not cav1. So at the debugger prompt I'd then enter where so as to see how it got from the user-defined procedure (cav1) to the current location. After entering where the debugger shows something like,

TopLevel: cav1(260)
	[260]
cav1: printf("radian = %d\n",evalf(1/180*a*Pi))
	["radian = %d\n", 4.537856054]
printf: fprintf('default',args)
	[default, "radian = %d\n", 4.537856054]
fprintf:
   1   iolib(9,args)

which I think makes it more clear which statement in cav1 led to the problem.

acer

@Mac Dude I see a few different kinds of oddness in your document.

One kind is the rhs of assignment statements, where the lhs is like "H :=" in 2D Math black, and the rhs is what I'd normally expect to see as the 2D Output (ie. its echoes the assignment big, being like "H := ...." but all in blue). This kind seems to be fixable by right-click contextmenu action to convert the whole input to 1D, and then back to 2D Input. Minor touch up to turn Physics[Vectors][Norm] back into just a marked up Norm may be desired, etc.

A second kind was the same effect by on non-executable 2D Math, inline in a paragraph of text say.

A third kind seems to be where normally black 2D Input is partially in blue.

I think I could fix up the second and third kind too, as a one-off fix. But I should ask some questions.

- How did the Document arrive at this state? Do you think that it was because a Maple 2015 Document was reopened and saved in Maple 15, or some such thing?

- What are you hoping for here? A fixed document, or a reliable way to re-fix if the problems resurface? I believe that I can do the former, but not the latter. (I figure that you might accomplish most the former too, if just by rewriting...)

- Is the third class of oddness described above a problem for you, or just my imagination? Did you ever have Equation Labels turned on, when authoring this?

- I didn't see instances of 2D output completely separate from any input (which is what I'd originally imagined, document unseen, based only on your description). Did I overlook another kind of problem?

You mentioned the XML of a .mw file. 2D Input and Output can get stored in the XML with two blobs of base64 encoded dotm (.m), one for the math expression and one for the typeset quantity. For example when the typesetting mode is "extended" then both of those can be utilized. You document appears to have Input for which the encoded expression is OK but somehow the associated encoded typeset blob has been clobbered with the encoded typeset blob of some Output. (That sort of detail helps me, and may help me repair, and it may provide hints to us, but otherwise I offer it just as detail -- I don't expect you to have to act upon it.)

I'll be visiting this site seldomly over the next 7-10 days. Please add a note if you need a fix up fast, even if only for some portion.

Using Maple 13.01,

Download convertQ.mw

acer

What are you trying to ask, when you write, "compute this equation"?

is( (x^2)^(0.5) = x ) assuming x>0;

                                    true

simplify( (x^2)^(0.5) ) assuming x>0;

                                      x

is( (x^2)^(1/2) = x ) assuming x>0;

                                    true

simplify( (x^2)^(1/2) ) assuming x>0;

                                      x

acer

I'm guessing that you mean the Standard GUI.

You could change (the color of) the Character Style for "2D Output", and then save that as a new style set and make it your new default. See here for a style set overview.

acer

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