You could compare these:

plot(x^2,x=0..1);

plot(x^2,x=0..1,axis=[thickness=3,tickmarks=[thickness=3]]);

plot(x^2,x=0..1,thickness=3,axis=[thickness=3,tickmarks=[thickness=3]]);

acer

You can look at Kitonum's great post about labeled contours (which I suspect could be adjusted to use a legend with color-coded lines/polygons with correspondingly nice legend labels).

And I'd be surprised if this method of displaying a surface beside a colorbar couldn't be adjusted to instead marry a 2D contour plot with a colorbar.

But I never get tired of this subject, so for fun here's yet another way to get some color-coding in a legend. This needs the Standard Java GUI. I ran this below in Maple 18.02.

Download contourlegend1.mw

acer

For the Standard Interface, with typesetting level set to extended.

This doesn't change the structure in memory. It just prints the thing differently. It could be streamlined or customize/extended for other uses.

Download typsetorder.mw

With a variation on the sort predicate (used above) it might also force the relative order of terms with x(t) versus y(t). And so on.

A quite different approach might be to replace the diff calls with individual objects (which each print the diff represented) and then sort according to those (via indirection, to the desired diff order as the sorting key).

acer

If you are really striving to get something like long multiplication (as learned in grade school, say), then you could try something like the following.

Note that it does not discriminate between trailing zeros and other trailing digits. See my querying comments above -- I was trying to figure out what you wanted beyond the meagre example you supplied. I may have surmised wrongly.

Download star1.mw

Now, if those result are acceptable and if you really want the interactive `*` command to behave like that then you could try and enhance something like the following very rough idea. Note that I have not implemented distribution across sums, and also note that overloading arithmetic operators can lead to weird usage problems (because the symbols often server multiple purposes).

Download star2.mw

This is probably a good time to take a step back. What are your underlying, motivating examples that make you think that you want this behavior? Very, very often here on mapleprimes people ask about how to implement a scheme they've cooked up to solve some problem, when there exists some better way. So if, for example, you are "just" trying to deal with roundoff error for non-atomic, composed elementary computations (and noticed that --unlike Mathematica -- Maple does not accomodate specifying an inbound accuracy for float inputs) then you may be better off with a scheme involving intervals/evalr/shake/etc.

acer

I too see the problem. (The "strange characters" seems to be the colon-equals symbols that are rendered below the start of the numerator.

A shorter code to reproduce, for me,

r:=175!/(11111);

acer

If you mean the Fourier package by Karel Srot that is described here on the Application Center then you can try this URL which contains some older zip file links to it.

acer

@Hapseeker What you gave to us a plaintext is, it seems, some 2D Math input in which you are using the statement p_com(z,t):=... to create an operator. Several experts here consider that syntax as dubious at best, because it is ambiguous.

I suggest that instead such an operator is constructed either with the more usual, unambiguous arrow syntax, or something like this if you wish to make use of the assumptions before constructing the body of the operator (without the Re call). The key thing I use in getting the call to Re resolved away in the operator body is the unapply command.

restart;

p_com := unapply(Re(exp(I*omega*t-I*k*(lambda[r]+I*lambda[i])*z)), [z,t])
           assuming omega::real, t::real, k::real, lambda[r]::real, lambda[i]::real, z::real;

One way is to use the freeze command. Eg,

eq := (-Omega^2*a*A[2]-Omega^2*m*B[1]+Omega*A[1]*c[1]+B[1]*k[1])*cos(Omega*t)
      +(Omega^2*a*B[2]-Omega^2*m*A[1]-Omega*B[1]*c[1]+A[1]*k[1])*sin(Omega*t)
      = 0:

fexpr:=subs([sin(Omega*t)=freeze(sin(Omega*t)),
             cos(Omega*t)=freeze(cos(Omega*t))],(lhs-rhs)(eq)):

coeff(fexpr, freeze(sin(Omega*t)));

           2               2                                     
      Omega  a B[2] - Omega  m A[1] - Omega B[1] c[1] + A[1] k[1]

coeff(fexpr, freeze(cos(Omega*t)));

            2               2                                     
      -Omega  a A[2] - Omega  m B[1] + Omega A[1] c[1] + B[1] k[1]

acer

More succinctly,

restart:

assume(b()(x),real);

getassumptions(a(x));

                        {(b()(x))::real}

[edited, all below] And, shorter still,

restart;

assume(b(t),real);

getassumptions(a(t));

                                              {b(t~)::real}

What's happening is that the assumption that b(t)::real involves t, and this semantic baggage of t affects tests of properties of a(t). And getassumptions(a(t)) is simply reporting the semantic baggage of t to the extent that it knows any property related to t.

about(t);

Originally t, renamed t~:
  Involved in the following expressions with properties
    b(t) assumed real
  also used in the following assumed objects
  [b(t)] assumed real

coulditbe( a(t), real );

                                                   FAIL

Whereas in a fresh session,

restart;

coulditbe( a(t), real );

                                                   true

Perhaps another example might help illustrate why this behavior can be useful.

restart;

assume(sqrt(t)>3);   

getassumptions(a(t));

        1/2            1/2
     {t~   ::real, (-t~    + 3)::RealRange(-infinity, Open(0)),

                      1/2
                   (t~    - 3)::RealRange(Open(0), infinity)}

is(t<2);             

                                                  false

acer

@JacquesC I am surprised that you are surprised.

I don't see why you focus on ctx as a keyword parameter of foo. Consider the case where ctx is a required parameter. The requirements on how to use the name ctx when calling bar are the same as for your examples.

The essence of your problem is not in the particular value of parameter ctx when inside foo, but rather it is in the usual rules for how one may not use (the name of) a formal parameter as a name within a procedure. Eveluation of the parameters happens up front, not at each instance they are used within the running procedure.

Are you surprised by how the first example below works? If not then why should keyword parameter values get into procs differently than do required parameters?

restart;

foo := proc( ctx )
         'ctx' = [a,b,c];
       end proc:

foo( 7.3 );
                        7.3 = [a, b, c]

restart;

foo := proc( ctx )
         :-ctx = [a,b,c];
       end proc:

foo( 7.3 );
                        ctx = [a, b, c]

The only thing mildly surprising to me here is that the need to denote a keyword as only a name was not made a strict requirement by design. I have heard %ctx=[a,b,c] or "ctx"=[a,b,c] as suggestions in the past. It would have to be strictly required if it were not going to trip up users, because otherwise many of them will use a shorter syntax like ctx=[a,b,c] by habit simply because it works most of the time. But it's too far late now to enforce such a requirement.

I see the form ':-ctx'=value being used a great deal. I don't see why it would be surprising that the global name is necessary if one wants to use a name (as a name) that happens to also be that of a formal parameter. And mint will tell you that you need the quotes, if you tried it as :-ctx=value instead.

Also the kernel should not be allowed to use the name ctx when passing ctx=value to bar, as if ctx were just a name, if ctx also happens to be the name of a formal parameter. If that were the behaviour then we wouldn't be able to pass sensibly the argument value_of_ctx=blah as well as the argument name_ctx=blech to bar. In other words, the following should be allowed to all work as it does now:

restart;

f := proc( { ctx :: list := [] } )
       g( ctx=[q,r,s], ':-ctx'=[a,b,c] );
     end proc:

g := proc( ListEq, { ctx :: list := [] } )
       [_passed], [_options[1.._noptions]];
     end proc:

f( );

            [[] = [q, r, s], ctx = [a, b, c]], [ctx = [a, b, c]]

f( ctx=[1,2,3] );

         [[1, 2, 3] = [q, r, s], ctx = [a, b, c]], [ctx = [a, b, c]]

I was able to open a .mws file in the MaplePlayer 2015 on 64bit Linux, simply by pasting the name of the .mws file into the input line in the File->Open dialog.

And then the Player displayed the contents of the opened .mws worksheet, including plots previously computed and displayed when I ran the worksheet in a session of the Maple GUI proper.

Note that the MaplePlayer is only designed to execute commands that are in the so-called "action code" behind Embedded Components, and the results of such are then dynamically viewable within embedded PlotComponents and MathContainers. That's how the degree of interactivity in the MaplePlayer is designed. The MaplePlayer will not execute input commands in the sheet that lie outside of Embedded Components.

The .mws format does not support Embedded Components, so there can be no interactive computation if you open a .mws file in the Player. You can however view the contents of such worksheets, including output that was generated in a Maple GUI session.

acer

If you load the MTM package then when you call just subs(...) it will invoke the command MTM:-subs which has a different syntax than the global subs command. You can read about it in the help pages.

restart;
F:=MTM:-fourier(f,x,y):
g:=z^2:
MTM:-subs(F,y,g);
                                    / 2\
                        2 f Pi Dirac\z /

restart;
F:=MTM:-fourier(f,x,y):
g:=z^2:
:-subs(y=g,F);
                                    / 2\
                        2 f Pi Dirac\z /

restart;
with(MTM):
F:=fourier(f,x,y): # will call MTM:-fourier
g:=z^2:
:-subs(y=g,F);
                                    / 2\
                        2 f Pi Dirac\z /

restart;
F:=inttrans[fourier](f,x,y):
g:=z^2:
:-subs(y=g,F);
                                    / 2\
                        2 f Pi Dirac\z /

acer

patient: "Doctor, it hurts when I move my arm like this."
doctor: "Don't move your arm like that."

It's not clear to what degree you want the students to be able to interact with the application, apart from manually rotating them. I'm going to guess that you also want them to be able somehow to specify what plot they are viewing.

It seems as if you are trying to use Embedded Plot Components, from which I surmise that you want to offer a choice of plot for the student to view, in one or more such components. Naturally, if you only ever wanted each Plot Component to hold as its value just its own single 3D plot then you could just zoom then all in by hand, and save the document. By virtue of your asking your question I infer that you want the choice of displayed plot to be changed.

If you want the students to be able to view and manually rotate in the Cloud/Player some plots dynamically constructed with some arbitrary properties (the nature of the spacecurves or underlying equations) then you may be out of luck as far as zooming goes. The zoom quality of a 3D Plot inside a Plot Component is not a property which can be set programmatically. It's also not a property of the plot structure either (in the Maple kernel sense). The zoom level of a plot is, alas, a property of only the plot itself and only in the sense of its internal representation by the GUI/Player/client -- and this is reflected in the XML of a saved .mw file.

Moreover, unlike a plot displayed as regular output in a worksheet/document, the properties of zoom and pan (horiz. or vert. offset)  are not persistent qualities of an Embedded Plot Component. By this I mean that if you use the Plot Component manipulator to zoom or pan, and then you set the `value` of that component to be another plot, then the zoom and pan are reset to default.

So the only way I know to get an effect close to what (I believe) you're after is to pre-assemble a Table cell with multiple Plot Components each containing its own pre-zoomed 3D plot. By using buttons or radio buttons or other Action Code of components you can then selectively toggle on and off the `visible` property of these Plot Components. By only ever having one visible at a time you can mimic the effect of replacing the plot in view. Of course this is only workable if you have only a finite set of such plots that you want view in the same spot.

Here's a simple example, with just two Plot Components inserted from the Embedded Component palette into the same single Table cell. You could of course augment this by inserting even more Plot Components into that cell and then adjusting the code such as I put inside the RadioButtons. It works for me in the MapleCloud, or the Maple Player 2015. Notice that the pre-zoomed quality of the "Plot 1" is retained, each time that particular component is again made visible. I made this using the palettes and right-click menus to edit the button's action code. plotchoice.mw

So, as I mentioned, if you want to have the student be able to view a zoomed 3D plot which is constructed on the fly (according to something arbitrary such as the underlying math, etc) then I suspect it is not currently possible.

In the Maple 2015 GUI (not the Cloud or Player) it is possible to view a 3D plot in a programmatically zoomed state, even if it is generated on the fly. I realize that may not be your students' situation, but I mention it for two reasons. 1) It may be of interest to others reading this, and 2) it allows you to specify a particular numeric value for the amount of zoom (or offset).

This might possibly be of some value to you, if you want to be able to make a collection of 3D plots (inside pre-formed Plot Components, or not) with the exact same degree of zoom.

Here is an example that either embeds a Plot Component containing your pre-zoomd 3D plot into the running worksheet or launches it in a new sheet. You should be able to copy and paste the Plot Component and have its plot retain the zoomed quality. This might help if you want to force a specific numeric zoom level. makescaledplot3d.mw

For fun I'll include another example of embedding into a running Maple GUI worksheet a 3D plot whose view is pre-zoomed (so to speak). This one is an animation. makescalledanim3d.mw

I hope this helps.

BTW, all 3D plots inside Plot Components are not working for me in the Maple Cloud at present when I view with Chrome, although they has worked in the past. They are working for me right now if I use Internet Explorer.

I have previously made Software Change Requests that Plot Components get all of zoom, pan offsets, theta-psi-phi rotation angles, and perspective as properties which can be changed using the SetProperty command.

acer

See the second Calling Sequence example collect(a, x, form, func) on the help page for the collect command, and the paragraph in the Description of that page which mentions it. The option func is applied to the coefficents after collecting is done.

ee := expand( A1*cos(s+t) + A2*sin(s+t) ):

ee;

    A1 cos(s) cos(t) - A1 sin(s) sin(t) + A2 sin(s) cos(t) + A2 cos(s) sin(t)

collect(ee, [A1,A2]);
  
     (cos(s) cos(t) - sin(s) sin(t)) A1 + (sin(s) cos(t) + cos(s) sin(t)) A2

collect(ee, [A1,A2], combine);

                          A1 cos(s + t) + A2 sin(s + t)

acer

@Shinjitm You could also unload only the MTM:-sum and leave the rest of the package members' status the same, by issuing unwith(MTM,sum) . That might help with your wish to use the 2D Input summation symbol.

Note that any other command in MTM which makes use of MTM:-sum should function regardless of whether that individual command is loaded.

"Loading" packages or individual commands just binds the names, for convenient (terser) use. You can call individual command exports using the syntax like MTM:-acos regardless of whether the name acos is bound to a package export (ie. loaded from a package).

You can bind (load) what you wish, or not, either wholesale or piecemeal. In any case you can always access both global commands like :-sum or package exports like MTM:-sum.