acer

18951 Reputation

29 Badges

14 years, 276 days

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

Did you want to map factor over the addends of eq? Note that elementwise factor~(expr) is not the same as map(factor,expr) if expr is a sum of terms rather than an indexable data structure.

Also, I don't understand from your description and attachment whether you are trying to operate (or not) on numerator and denominator separately.

Sorry, but I find your description unclear. What are your f(x) and g(x), etc?

restart

eq := (9*gamma_1*Psi^2*Y1(x1)*alpha_21*omega_y^2-3*gamma_1*Psi^3*alpha_21*omega_y^2+3*gamma_1*Y1(x1)^3*alpha_21*omega_y^2-9*gamma_1*Psi*Y1(x1)^2*alpha_21*omega_y^2)*AA/(-alpha_21*omega_y^2+k_1)+I*cd1*omega_y^3*alpha_21*(-Psi+Y1(x1))*A1(T[2])/(-alpha_21*omega_y^2+k_1)+((diff(Phi[2, 1](x1, T[2]), x1, x1, x1))*alpha_21*omega_y^2-(diff(Phi[2, 1](x1, T[2]), x1, x1, x1))*k_1+k_1*Phi[1, 1](x1, T[2])*alpha_21*omega_y^2-alpha_11*Phi[1, 1](x1, T[2])*omega_y^4*alpha_21+alpha_11*Phi[1, 1](x1, T[2])*omega_y^2*k_1+(2*I)*alpha_11*Y1(x1)*(diff(A1(T[2]), T[2]))*omega_y^3*alpha_21-(2*I)*alpha_11*Y1(x1)*(diff(A1(T[2]), T[2]))*omega_y*k_1-(2*I)*k_1*alpha_21*Psi*(diff(A1(T[2]), T[2]))*omega_y-(diff(Phi[1, 1](x1, T[2]), x1, x1, x1))*alpha_21*omega_y^2+(diff(Phi[1, 1](x1, T[2]), x1, x1, x1))*k_1)/(-alpha_21*omega_y^2+k_1)

(9*gamma_1*Psi^2*Y1(x1)*alpha_21*omega_y^2-3*gamma_1*Psi^3*alpha_21*omega_y^2+3*gamma_1*Y1(x1)^3*alpha_21*omega_y^2-9*gamma_1*Psi*Y1(x1)^2*alpha_21*omega_y^2)*AA/(-alpha_21*omega_y^2+k_1)+I*cd1*omega_y^3*alpha_21*(-Psi+Y1(x1))*A1(T[2])/(-alpha_21*omega_y^2+k_1)+((diff(diff(diff(Phi[2, 1](x1, T[2]), x1), x1), x1))*alpha_21*omega_y^2-(diff(diff(diff(Phi[2, 1](x1, T[2]), x1), x1), x1))*k_1+k_1*Phi[1, 1](x1, T[2])*alpha_21*omega_y^2-alpha_11*Phi[1, 1](x1, T[2])*omega_y^4*alpha_21+alpha_11*Phi[1, 1](x1, T[2])*omega_y^2*k_1+(2*I)*alpha_11*Y1(x1)*(diff(A1(T[2]), T[2]))*omega_y^3*alpha_21-(2*I)*alpha_11*Y1(x1)*(diff(A1(T[2]), T[2]))*omega_y*k_1-(2*I)*k_1*alpha_21*Psi*(diff(A1(T[2]), T[2]))*omega_y-(diff(diff(diff(Phi[1, 1](x1, T[2]), x1), x1), x1))*alpha_21*omega_y^2+(diff(diff(diff(Phi[1, 1](x1, T[2]), x1), x1), x1))*k_1)/(-alpha_21*omega_y^2+k_1)

op(0, eq);

`+`

3

map(factor, eq);

3*gamma_1*alpha_21*omega_y^2*(-Psi+Y1(x1))^3*AA/(-alpha_21*omega_y^2+k_1)+I*cd1*omega_y^3*alpha_21*(-Psi+Y1(x1))*A1(T[2])/(-alpha_21*omega_y^2+k_1)-(-(diff(diff(diff(Phi[2, 1](x1, T[2]), x1), x1), x1))*alpha_21*omega_y^2+(diff(diff(diff(Phi[2, 1](x1, T[2]), x1), x1), x1))*k_1-k_1*Phi[1, 1](x1, T[2])*alpha_21*omega_y^2+alpha_11*Phi[1, 1](x1, T[2])*omega_y^4*alpha_21-alpha_11*Phi[1, 1](x1, T[2])*omega_y^2*k_1-(2*I)*alpha_11*Y1(x1)*(diff(A1(T[2]), T[2]))*omega_y^3*alpha_21+(2*I)*alpha_11*Y1(x1)*(diff(A1(T[2]), T[2]))*omega_y*k_1+(2*I)*k_1*alpha_21*Psi*(diff(A1(T[2]), T[2]))*omega_y+(diff(diff(diff(Phi[1, 1](x1, T[2]), x1), x1), x1))*alpha_21*omega_y^2-(diff(diff(diff(Phi[1, 1](x1, T[2]), x1), x1), x1))*k_1)/(-alpha_21*omega_y^2+k_1)

map(proc (u) options operator, arrow; simplify(u, size) end proc, eq);

-3*gamma_1*alpha_21*omega_y^2*(Psi-Y1(x1))^3*AA/(-alpha_21*omega_y^2+k_1)+I*cd1*omega_y^3*alpha_21*(-Psi+Y1(x1))*A1(T[2])/(-alpha_21*omega_y^2+k_1)+((-alpha_21*omega_y^2+k_1)*(diff(diff(diff(Phi[1, 1](x1, T[2]), x1), x1), x1))+(alpha_21*omega_y^2-k_1)*(diff(diff(diff(Phi[2, 1](x1, T[2]), x1), x1), x1))-2*omega_y*((I*alpha_11*(-alpha_21*omega_y^2+k_1)*Y1(x1)+I*k_1*alpha_21*Psi)*(diff(A1(T[2]), T[2]))-(1/2)*(-omega_y^2*alpha_11*alpha_21+k_1*(alpha_21+alpha_11))*omega_y*Phi[1, 1](x1, T[2])))/(-alpha_21*omega_y^2+k_1)

 

Download example_ac.mw

I do not see the behavior that you describe, in Maple 2018.2, either in a Worksheet or a Document. In that version I see the plots rendered prior to final conclusion, separated in time by the Sleep() specification.

But I do see the behavior that you describe if I execute your code in a Document in Maple 18.02.

So I'll ask whether perhaps you have given this Question an incorrect Product label, and whether you might actually have an older version such as Maple 18 (released, 2014).

If you are in fact using Maple 18 then you can try your computation in a Worksheet, rather than a Document. See the main menubar's File->New->Worksheet to open a fresh Worksheet instead of a Document. In that environment I do indeed see the plots rendered prior to final conclusion, staggered in time by the Sleep() specification.

If you really want the staggered display within a Document in version Maple 18 or older then you could insert a Plot Component and push the plots into that instead or printing. That too would stagger the rendering with the loop iteration, but each of the plots would in turn overwrite the same location. Here is an example. I inserted the Plot Component using the Components palette.  Download loop_plot_EC.mw

By the way, if you ever use a version later than Maple 18 then you could get a similar (in-place) overwriting, staggered effect by using DocumentTools:-Tabluate([plot(...)]) instead of print(plot(...)) . Here is an example done in Maple 2015 .  loop_tab_2015.mw

Yes, there are several ways. You could try solve (possibly after evalf). You could try the addon DirectSearch package's SolveEquations command. You could try Optimization:-Minimize and use the equations for constraints. You might even be able to leverage fsolve (it depends).

Why not attach a worksheet and show us the system?

You didn't explain how you wanted to utilize "&", eg. with "tabular", "array", "align", etc. Note that Maple's latex command already emits "array" for a Matrix.

For "tabular", I found this in the vault, which could likely be adjusted as needed.

restart;

 

Lat:=proc(M::Matrix,
          {output::{NoUserValue,identical(string)}:=':-NoUserValue'})
  local m,n,S;
  (m,n):=op(1,M);
  S:=cat(" \\begin{tabular}",
         "{|",seq("c|",i=1..op([1,2],M)),"} ",
         "\\hline ",
         seq([seq(sprintf("$%s$ & ",latex(M[i,j],':-output'=string)),j=1..n-1),
         sprintf("$%s$ \\\\ \\hline ",latex(M[i,n],':-output'=string))][],i=1..m),
         "\\end{tabular} ");
  if output=':-string' then
    return S;
  else
    printf("%s",S);
    return NULL;
  end if;
end proc:

 

Lat( < < x^2+1 | x^3 > > );

 \begin{tabular}{|c|c|} \hline ${x}^{2}+1$ & ${x}^{3}$ \\ \hline \end{tabular}

 

S := Lat( < < x^2+1 | x^3 > > , output=string):
S;

" \begin{tabular}{|c|c|} \hline ${x}^{2}+1$ & ${x}^{3}$ \\ \hline \end{tabular} "

 

Lat( Matrix(3,3,(i,j)->randpoly(x,coeffs=rand(0..2),degree=3)) );

 \begin{tabular}{|c|c|c|} \hline $2\,{x}^{2}+2\,x+1$ & ${x}^{2}+x+2$ & ${x}^{3}+2\,x$ \\ \hline ${x}^{2}+2\,x+1$ & ${x}^{3}+2\,{x}^{2}+2\,x$ & ${x}^{3}+1$ \\ \hline ${x}^{3}+2\,{x}^{2}+2\,x+1$ & ${x}^{3}+2$ & ${x}^{2}+1$ \\ \hline \end{tabular}

 

The last example produces this, for me, when processed using LaTeX.

Download latextabular.mw

This is a known issue with licensing.

You could try to install the last point-release update to Maple 2019.2.1 . That could help your case, to overcome a rare issue with licensing misidentification.

Otherwise you should contact Maplesoft Technical Support ( ie. send email to support@maplesoft.com )

If I add the compile=true option to the dsolve call then it takes about 6 seconds on my machine.

You supply the range option to dsolve; the first two odeplot calls over the same range are fast.

I suppress output of the eval calls to pick off the solution procedures.

I removed adaptive=8 in the final two plot calls, since it doesn't make sense to me to try adaptive plotting over such high oscillation (which would not be clearly seen at this resolution, I doubt). Instead I supply adaptive=false and force a high numpoints.

I used Maple 2019.2, as you had.

dsolve1_1r_ac0.mw

Do you want arrows? There are several available commands for that.

Plot_eigenvectors_in_3d_scatterplot_ac.mw

(I also changed the symbol to solidcircle. I gave Cov the symmetric shape.)

Using odeplot and a single dsolve (numeric) call -- with parameters -- this can be done somewhat efficiently.

(I compute it also with Carl's Answer's phaseportrait code, to illustrate that odeplot is reasonably quick. There's about a 10-fold timing speedup on my Maple 2020 on Linux, for this number of different Initial Conditions. The performance speedup increases with the number of ICs.)

 

First, using plots:-odeplot and a dsolve solution with parameters.

 

restart;

str:=time[real]():
dsol:=dsolve({diff(r(t),t)=r(t)^2*(r(t)+sin(theta(t))),
              diff(theta(t),t)=r(t)^3*(r(t)+theta(t)+cos(theta(t))),
              theta(0)=partheta, r(0)=parr}, numeric,
              parameters=[partheta, parr]):

odeplotpar:=proc(thetapar,rpar,i)
  dsol(parameters=[thetapar,rpar]);
  plots:-odeplot(dsol, [:-theta(t),:-r(t)], t=0..0.5,
                 numpoints=ceil(0.5/0.0005),
                 color=COLOR(HSV,0.85*i/16,0.85,0.7));
end proc:

P:=plottools:-transform((t,r)->[r*cos(t),r*sin(t)])(
 plots:-display(
   plots:-fieldplot([r^3*(r+theta+cos(theta)),r^2*(r+sin(theta))],
                    theta=0..2*Pi, r=0.7..3, fieldstrength=fixed(0.3),
                    color=COLOR(HSV,0,0,0.85)),
   seq(odeplotpar(i*Pi/8,0.75,i), i=0..15),
   axiscoordinates=polar, size=[600,600],
   axis[2]=[tickmarks=[subticks=0]],
   axis[1]=[gridlines=false, tickmarks=[[seq(0..3,0.5)]]])):
time[real]()-str;

.200

P;

 

For a timing comparison, a similar plot done with DEtools:-phaseportrait.
(One can also compare with DEplot, etc).

 

restart;

str:=time[real]():
P:=plots:-display( #needed to get polar axes
    plottools:-transform((t,r)-> r*~[cos,sin](t))( #transform to polar
        DEtools:-phaseportrait(
            [
                diff(r(t),t) = r(t)^2*(r(t)+sin(theta(t))),
                diff(theta(t),t) = r(t)^3*(r(t)+theta(t)+cos(theta(t)))
            ],
            [theta,r](t),
            t= 0..0.5, #independent variable range for all trajectories
            (i0:= map2(`~`[`=`], [theta,r](0), `[]`~(Pi/8*~[$0..15], .75))), #inits
            linecolor= [seq(COLOR(HSV, .85*i/ni, .85, .7), i= 0..(ni:= nops(i0)-1))],
            thickness= 1, #trajectory thickness (min. is 0, not 1)
            method= rkf45, stepsize= 0.0005,
            color= COLOR(HSV, 0, 0, .85), #light-grey arrows
            arrowsize= .3
        )
    ),
    axiscoordinates= polar, size= [600$2],
    axis[2]= [tickmarks= [subticks= 0]], axis[1]= [gridlines= false]
 ):
time[real]()-str;

1.949

#P;

 

Download polar_odeplot.mw

Here are two possible avenues ideas: 1) percent as a Unit, and 2) percent as an evalf'able constant. (I'll leave out the potential rabbit hole of some kind of object.)

2D Input mode seems to be a problem. And if that's the principle goal then this won't be worth much.

Note that in the Maple 2020 GUI the relevant output below renders OK for me, with an actual percent symbol even for the alternate. The Mapleprimes inline display doesn't seem to handle it, so a blank box appears below.

I could also have used the entity `&#37;` for the Units variant. I used the so-called "Arabic Percent Symbol" only because it looked a little different. Both seem to be limited, and not work as 2D Input.

restart;

 

Entering % in 2D Input mode is problematic. If I use `&#37;` or another

encoding of the usual % symbol then as 2D Input it gets parsed as the

so-called ditto (last result).

 

It's difficult even if I use an encoding for Arabic Percent Sign. (There are

other alternates, but my Maple 2020.0 on Linux doesn't render them

in output. (It shows only an empty box for the symbol.) In decimal

that can be referred to as the entity `&#1642;` and in hex `&#x066A;`.

This too does not serve for 2D Input because the Punctuation palette

has only the problematic regular %. And cut&paste of this alternative

turns into the problematic usual % symbol upon parsing.

 

So, I don't know how to use a pretty-printed % for 2D Input. If that is

solved then one of these two mechanisms might be improved.

 

Units:-AddUnit('percent', 'symbol' = '`&#1642;`',
               'prefix' = 'SI', 'conversion' = 1/100);

P := 45*Unit(percent);

45*Units:-Unit(Ùª)

convert( P * 123/7, units, 1 );

1107/140

convert( P * 123.0/7, units, 1 );

7.907142856

 

with(Units:-Simple):

simplify( P * 123/7, units );

1107/140

simplify( P * 123.0/7, units );

7.907142857

123/7*Unit(meter) * 45*Unit(percent);

evalf(%);

(1107/140)*Units:-Unit(m)

7.907142857*Units:-Unit(m)

restart;

`evalf/constant/&#37;` := proc(x) 0.01; end proc:

`evalf/constant/percent` := proc(x) 0.01; end proc:

 

P := 45 * `&#37;`;

45*%

evalf( P );

.45

evalf( P * 123/7 );

7.907142857

Q := 45 * percent;

45*percent

evalf( Q );

.45

evalf( Q * 123/7 );

7.907142857

 

Download percent.mw

[edited] As far as I know, Units and evalf-extensions either do some inner manipulations with locals or rely upon global names. So I don't see offhand and attractive way to make either of these two mechanisms work with a top-level local % declaration.

For example, the following allows for easy 2D Input, but in order to get the final float value it also needs the convert to global (which makes it awkward to use).

restart;

local %:

`evalf/constant/%` := proc(x) 0.01; end proc:

 

 

P := 45*%

45*%

evalf( convert(P,`global`) * 123/7 );

7.907142857

 

Download percent_local_evalf.mw

The awkwardness might all be hidden behind an object, so that entry could be something easy like, say %() as an empty function call. And then the prettyprint could be made nice and clean, and a static evalf export could do the conversion via global, and regular prettyprint output could hide the function call brackets. Oof.

I notice that you cut down your y-range to 0.0..0.7 in your original 3D plot. If you had used the range y=0..1 then in your Maple 2018 there would be a ragged edge along one side of the surface.

For y>1/sqrt(2)=0.707... you can still get a decent rendering of the surface or the contours.  See below, for the higher y-contour values. (Some of this is automatically better in Maple 2020, btw.)

You can also get a little tighter near to x=1, where you had used 0.99 for the upper edge. (This aspect is not fully better, automatically, in Maple 2020.0.)

The effect of those changes can also bring down the surface edge towards z=0 along boundaries, ie. a more faithful representation IMO.

For the 2D curves it's a little trickier to get tight up to the lower x-value (within x=0..1) for y-values less than 1/sqrt(2). One can fiddle with the lower plot range (eg. a conditional and a formula), but roundoff error makes even that tricky. Easier is to allow adaptive 2D plotting and higher numpoints handle it.

Also, you can raise the 2D curves up to their contour values, to include in a 3D plot, if you'd like.

You can also get a variant of that using the contourplot3d command (with axis relabelling). Note that with the parametric calling sequence you can rearrange which formulas get used for each coordinate, and that can be matched by corresponding axis relabelling and reorientation.

restart

kernelopts(version)

`Maple 2018.2, X86 64 LINUX, Nov 16 2018, Build ID 1362973`

with(plots)

z := proc (x, y) options operator, arrow; (x^2+x*y+y^2)*sqrt((1-y^2)^2/(x+y)^2-(x-y)^2) end proc

S := [solve({((-y^2+1)/(x+y))^2-(x-y)^2 = 0}, {y})]; S1 := eval(y, S[1])

eps := 0.1e-8; A := plot3d([x, y, z(x, y)], x = 0 .. 1-eps, y = 0 .. S1-eps, style = surface)

Colors := [yellow, orange, red, green, blue, khaki, violet, cyan, pink, magenta]; P3d := plots:-display(seq((plottools:-transform(proc (a, b) options operator, arrow; [a, y, b] end proc))(plot([x, z(x, y), x = 0 .. 1-eps], color = Colors[1+trunc(y/(.1))], thickness = 3, numpoints = 1000)), y = 0 .. .9, .1))

plots:-display(A, P3d, labels = [x, y, z])

plot([seq([x, z(x, y), x = 0 .. 1-eps], y = 0 .. .9, .1)], color = Colors, thickness = 2, numpoints = 1000, legend = [seq(y = C, C = 0 .. .9, .1)], labels = [x, z])

display(plot3d([x, z(x, y), y], x = 0 .. 1-eps, y = 0 .. S1-eps, style = surface), contourplot3d([x, z(x, y), y], x = 0 .. 1-eps, y = 0 .. S1-eps, contours = [seq(C, C = 0 .. .9, .1)], grid = [151, 151], thickness = 3), orientation = [-100, -15, 35], labels = [x, z, y])

 

Download Contour_Plot_MaplePrimes_ac.mw

Try passing the option  style=surface  to the plot3d call in question.

(Or, if your Maple version is truly ancient,  style=patchnogrid ).

The visual effect that you are calling "grid" is sometimes referred to as a wireframe. Its resolution details (when present in the rendering) are affected by the choice of the grid option, yes. But whether it appears at all -- or not -- is controlled by the style option.

See the Help page with Topic  plot3d,options  for more detail on the possible values that can be used for the style option.

If you search this site then you can find previous questions with the same topic.

For example, here.

I found that recent item by looking at the questions with the phaseportrait tag. It was right at the top.

There are other ways to search the site. Entering the terms in this sites Search bar produces a collection.

You can use multiple initial-conditions with the DEplot command. There are examples on its Help page.

You could also use the odeplot command.

I'm sure that someone will be quite willing to do all your problems in full (even coursework questions). But perhaps you could also show how far you've gotten so far.

Is this something like the look you're going for? (You can adjust the style, transparency, etc). Q1_ac.mw

If you don't need the solid boundary of the leading side (that moves) then it's a great deal simpler to do. I just prefer this look. I find that too much transparency makes these kinds of rotations overly difficult to visualize (and poorly so).

restart;
Lift3D:=plottools[transform]((x,y,z)->[x,z+sqrt(6-(sqrt(x^2+y^2))),y]):
F:=plottools[transform]((x,y)->[x,y+sqrt(6-x),0])(plot(sqrt(4-r)-sqrt(6-r),r=0..4,
                                                   filled,transparency=0.0)):
P := A -> plots:-display(orientation=[-90,15,-160],
            Lift3D(plot3d([[r,theta,sqrt(4-r)-sqrt(6-r)]],
                   r=0..4, theta=0..A, coords=cylindrical, filled,
                   orientation=[-90,15,-160], lightmodel=light1,
                   grid=[40,max(2,ceil(evalf(49*A/(2*Pi))))],
                   scaling=constrained, axes=normal, style=patch)),
            `if`(A<6.28,[F,plottools[rotate](F,-A,[[0,0,0],[0,1,0]])][],NULL),
            labels=[x,y,z]):
plots[animate](P, [A], A=0..2*Pi, frames=17, paraminfo=false);

This may be similarly resource intensive as an animated use of 3D plots:-shadebetween (for a similar number of frames). I could probably improve it by ditching the filled option in the plot3d call (inside P), and using a grid=[...,2] cylinder instead. That's done pretty well before -- the cylinder shape can have varying height, to joint the two surfaces where they don't intersect within the desired domain. Let me know if memory/GUI performance is a huge issue.

Here is a revision, which works.

I put a few comments into the Action Code, to explain how the substitution (for n) in the formula can be done.

I did not otherwise change the algorithm. It could be done more efficiently. I left it in the spirit of your prior work.

Iterative_components_ac.mw

[Edit] This is better than my original example (which passed n=3.0 and while relevant was not the most precise as explanation). I re-instated this Answer as it was accidentally deleted by someone else.

restart;
Digits := 20:
eval( ((n+1.)/n)^(n+1.), n=3 );

         3.1604938271604938268

restart;
Digits := 20:
evalf( eval( ((n+1)/n)^(n+1), n=3 ) );

         3.1604938271604938272

The difference between seq and $ is one of evaluation. (See also `||` versus cat.)

By the way, in the construction of your a list there is a single call to procedure u, into the result of which are placed the ten different integer arguments. In the construction of your b list there are ten calls to procedure u (each of which applies evalf).

First 8 9 10 11 12 13 14 Last Page 10 of 218