I have previously submitted a Software Change Request (SCR) that the three angles (as well as the projection value) be made properties of a Plot Component, and this case at hand is typical.

In the past I have made do with the method member vv suggested: 3 sliding components where the plotting call makes use of their values for the orientation option. Of course that does not help with the case of right-click-drag rotation by hand in the Plot Component itself.

It's not very efficient but some data can be pulled off the plot in the Plot Component. It wasn't always the case I believe, but in recent Maple versions when a 3D plot in a Plot Component is rotated manually the orientation is preserved in the PROJECTION(...) substructure when the PLOT3D structure is retrieved from the component using DocumentTools:-GetProperty. (I say not efficient, because this involves making the GUI send the whole structure to the kernel which then has to call indets on it. It should in principle be more efficient to have a new mechanism which sent just one or more of the three angles.)

Here is an example of what I mean. It's unfortunate that it requires a separate Button or other Component (with an associated Action) to grab the data. It would be nicer if we could hook up the click-and-drag code to the manual rotation of a 3D plot, but I don't think that's currently possible.  proj.mw

So a question arises, can we decode the first 9 values in the PROJECTION substructure so as to attain the equivalent three angles theta, psi, phi? I suspect that the 10th value is the projection setting, which can be adjusted using the right-click context menu of a 3D plot. I do not see it explained in the help page on plot structures.

 [edit] It's possible that this is enough to deal with this Question, without decoding the meaning of the values. The "updating" code could yank out the current PROJECTIONS substructure, then create the new 3D plot using its current method, and then substitute that PROJECTIONS into that new 3D plot structure (while also removing any ORIENTATION substructure) before setting it as the value of the Plot Component.

http://lmgtfy.com/?q=.tar.gz

acer

How about isolating for x(s), and then dividing the equation by theta(s)?

After that, you might simplify as you see fit.

isol15.mw

acer

You should google numeric integration rules.

Maple offers several different numeric integration methods, some of which are adaptive. There's no reason why they should poll the integrand at values in an ascending order. Why do you think they ought to??

See the help page for evalf/Int and pay particular attention to the mehtods listed for 1D numeric integration as well as the section "Outline of the Numerical Integration Polyalgorithm (1-D Integrals)". Your example first is first tried with the _d0ajc method using hardware floats, and after that fails (due to non-evalhf'ability) it goes to the _Dexp method (via the routine `evalf/int/quadexp`).

You can get a lot of information about the process by setting infolevel[`evalf/int`] or by tracing through the various routines. Note that if you want to retry in the same session then you have to clear the relevant remember tables using the forget command, or else the prior result may be returned without recomputation.

Download evalfint.mw

acer

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