28721 Reputation

29 Badges

18 years, 1 days
Ontario, Canada

Social Networks and Content at

MaplePrimes Activity

These are answers submitted by acer

In your Question's text you stated that you want to change it, " replacing  vin/Iout with omega0*Lm". But then later you showed the attempt,

   eval(sol1, vin/Iout = omega*Lm)

which has omega rather than omega0. I'm going to proceed as if that attempt were a typo.

The algsubs command can perform that initial substitution.

sol1 := C*vout*vin/(Iout*L*k^2);


algsubs(vin/Iout = omega0*Lm, sol1);


eval(%, [Lm = k*L, C = 1/(omega0*L)]);



I suggest that you double-check all your formulas.

I fix that kind of error by using a full colon as statement terminator.

It's slightly difficult to see exactly what your after, since s does not appear in your expression assigned to V, and that expression also contains a term R1_R2. I'll proceed below as if those are mere typos.

Perhaps it is something like the following?

V := V1*R2/(C*R1*R2*s+R1+R2);


We are going to try to reformulate the expression assigned
to V, in the following form.

target := V1*R2/(R1+R2)/(C*R1*R2*s/(R1+R2)+1);


The OP has asked that we do that as, "divide numerator and
denominator by the s^0 coefficient." [presumably of the denominator]

The job is easily done, in only two steps.

The first step is to obtain the s^0 coefficient in the
denominator. We get it programmatically, not by eye.


F0 := coeff(denom(V),s,0);


numer(V)/F0  /  collect(denom(V)/F0,s);


We happen to get the desired ordering of terms
in the sums in the denominator (ie. the "1" on the right), forced
because I'd 
already input the target expression in the same session.

If I hadn't entered the target formula, we might also
need this sorting of terms in the sum, for prettiness.

#sort( %, order=plex(s) );


The andmap's purpose here is to bail (returning false) upon the first entry discovered as false. That's for efficiency.

But that could be done at both levels, here, ie. per equation as well as per soln value. In general that's even more efficient, as it would return the single false result as soon as any one instantiated equation were found to be false.



`Maple 2022.2, X86 64 LINUX, Oct 23 2022, Build ID 1657361`

eqs := [u     + v     + w     = 1,   u*x   + v*y   + w*z   = 1/2,
        u*x^2 + v*y^2 + w*z^2 = 1/3, u*x^3 + v*y^3 + w*z^3 = 1/4,
        u*x^4 + v*y^4 + w*z^4 = 1/5, u*x^5 + v*y^5 + w*z^5 = 1/6]:

soln := [solve(eqs, explicit)];

[{u = 4/9, v = 5/18, w = 5/18, x = 1/2, y = 1/2+(1/10)*15^(1/2), z = 1/2-(1/10)*15^(1/2)}, {u = 4/9, v = 5/18, w = 5/18, x = 1/2, y = 1/2-(1/10)*15^(1/2), z = 1/2+(1/10)*15^(1/2)}, {u = 5/18, v = 4/9, w = 5/18, x = 1/2+(1/10)*15^(1/2), y = 1/2, z = 1/2-(1/10)*15^(1/2)}, {u = 5/18, v = 4/9, w = 5/18, x = 1/2-(1/10)*15^(1/2), y = 1/2, z = 1/2+(1/10)*15^(1/2)}, {u = 5/18, v = 5/18, w = 4/9, x = 1/2+(1/10)*15^(1/2), y = 1/2-(1/10)*15^(1/2), z = 1/2}, {u = 5/18, v = 5/18, w = 4/9, x = 1/2-(1/10)*15^(1/2), y = 1/2+(1/10)*15^(1/2), z = 1/2}]



By putting all the instantiated equations into a single container
then a single call to andmap suffices.

For this particular problem that single container can be reduced
merely by making it a set (some instantiations are duplicates...).




As fun bonus, there happens to be no seq variable in play, to be declared local...


Lm := (simplify(k*sqrt(L*L)) assuming (0 < L));


L1 := (factor(L - Lm) assuming (0 < L and 0 < Lm and 0 <= k));





Note what happens without the sort (I have to do it in a fresh session, since the sorted result in the session above is subsequently obtainable without it...).


Lm := (simplify(k*sqrt(L*L)) assuming (0 < L)):

L1 := (factor(L - Lm) assuming (0 < L and 0 < Lm and 0 <= k)):






ps. If you have more involved examples then please show them up front in your Question.

If you merely use single right-tick uneval quotes (As Carl's suggested) then subsequent full evaluation of the resulting plot structure can lead to inadvertant and undesirable evaluation of assigned names in the textplots.

That can include the scenario where you pass the textplot(s) to plots:-display as a subsequent programmatic merging with plots computed only later.

That can make merely using uneval quotes a somewhat problematic approach. Too few layers of quoting and your code might accidentally evaluate the quoted expressions. Too many layers and some quotes can undesirably appear in the rendering. Too tricky, and fragile if mixed with later revisions to the overall code.

Passing the resulting assigned textplot structure around as eval(P,1) is possible, but that too can get complicated and onerous -- depending on later code changes.

Instead, your could use Typesetting:-Typeset to get the textplots, with much better resistence to such unwanted subsequent evaluation. Basically, it's just going to be more robustly useful in such a case that you don't want any part of the "text" to be subsequently, accidentally evaluated. You only have to focus on its construction, and not on how you use/pass it later.

In the examples below, the green text survives as intended, while the red text goes wrong due to inadvertant evaluation.


with(plots): setoptions(size=[500,300]);


p,c := -2,5;

-2, 5

P := display(
  textplot([1,3,Typesetting:-Typeset(p<c)], color="Green"),
  textplot([1,2,':-p'<':-c'], color="Red"),


display(P, plot((x-4)^2,x=0..8));


nb. If your expression is first assigned to some name, eg.  foo:=expression , then you might need either,
etc, since Typesetting:-Typeset has special evaluation rules (to prevent automatic evaluation) on its first parameter.

A call like,

   DocumentTools:-GetProperty("ComboBox0", value);

will return the currently selected item in the Combo Box embedded component with that ID.

The command parse would turn that string into the global instance of a name (if valid as such).

There are examples of this kind of use of GetProperty on this Help page. (That page was the very first hit, when I entered ComboBox in the Help Browser's search field.)

The parse command is not specific to embedded components. You could also be more verbose with, say, convert(str,name), btw.

An even more typical scenario for such use of parse is getting user-supplied numeric values from a TextBox embedded component. In that case, the Help page's main example actually uses parse, which is helpful. In the case of a ComboBox any programmatic contextual switching could be string-based as well/easily as name-based, by which I mean that parsing to a name isn't so inherently useful because the choices were already hard-coded and known the code author.

I was able to recover the following. Please check it over.

There might be an equation or Matrix input missing after the line containing, "Til at starte med bestemmer vi", and another after the line beginning, "Vi kan bestemme". And I'm not sure whether the very first opening Section should contain all other Sections (you might need to adjust).

This kind of curruption problem seems to be less frequent with Maple 2023. You might want to try that upgrade, if available to you.

In any event, I suggest that you try to make regular backups -- even if that means saving to separate files, manually.

The z that is the named parameter of your procedure,
    v := z -> functionList[1]
has nothing to do with the global name z that is in the expressions in the set. That's why your attempt does not succeed; invoking that procedure does not replace the z in the expression.

Here are two ways, the second a correction to your procedure-building approach, and the first a simpler approach using eval.


functionList := {2 + z, z^2 - 3*z, -z^3 + 4}:

Easier way, IMO.

plot3d(Im(eval(functionList[1],z=x + y*I)), x = -1 .. 1, y = -1 .. 1);

v := unapply(functionList[1],z):

plot3d(Im(v(x + y*I)), x = -1 .. 1, y = -1 .. 1);

Note that the following produce the same result as each other,
and are both what can get passed straight to plot3d as its
first argument (if you were to use the second element of your set).

The first method is considerably simpler. It is unnecessary
extra effort to construct a procedure/operator v
and then to only call it once (merely to construct the argument
passed to plot3d).

Im(eval(functionList[2],z=x + y*I))


v := unapply(functionList[2],z):
Im(v(x + y*I));



Is this one of the kinds of animation of the curves that you mean?

See attachment for animation of t vs x(t), t vs y(t), with all three playable together and axes aligned. Adjust as wanted.

There seem to be quite a few "corner cases", what with automatic-simplification, GUI rendering quirks, etc.

(I did this quickly, without cleaning it up. Check for mistakes...)


H := proc(ee) local res;
  res := subsindets(combine(simplify(ee)),`*`^fraction,
                    end proc)
         assuming positive;
  subsindets(res, {name,name^integer}^fraction,
             proc(u) local p,r,res; uses ID=InertForm:-Display;
               p := iquo(numer(op(2,u)),denom(op(2,u)),'r');
               if denom(op(2,u))=2 then
               end if;
             end proc);
end proc:








0, "%1 is not a command in the %2 package", _Hold, Typesetting


0, "%1 is not a command in the %2 package", _Hold, Typesetting


a*b^2*c*%surd(a*b, 3)


a*surd(a, 3)*b^2*c


a*b^2*surd(c^3, 4)


a^2*b^2*%surd(a*c^3, 4)


0, "%1 is not a command in the %2 package", _Hold, Typesetting


0, "%1 is not a command in the %2 package", _Hold, Typesetting


a^2*surd(a, 4)*(b*c)^(1/2)


Your attempt to get the overall vertical min&max with,

   plottools:-getdata(A)[3][.., 2]

is faulty because you have multiple curves structures in the plot.

But rather that fix that approach (ie. get the min&max for each and then compare/combine) you could use the rangesonly option of getdata which will figure out the overall min&max in both directions. Ie,

   ymin, ymax := op(plottools:-getdata(P, rangesonly)[2])

If I plot the surface at a higher grid resolution, in only a narrow strip close to x=-1 then it appears that the surface is discontinuous along x=-1, for y>1.5.

Using implicitplot instead of contourplot seems to provide a useful mechanism for getting the contours to agree with the surface in that region.

I'll leave it to you to figure out whether the apparent discontinuities are (perhaps?) due in part to numeric roundoff issues due to the complicated scaling of factors (ie. exp calls, and very large/small coefficients). I don't see offhand how symbolic manipulation of the expression (even with exact rationals) sheds light there.


You seem to have omitted to supply a value for y.

For example,

UnivariateBarGraph(beta, [seq(0..1, 0.2)],
                                   [Q = 1.3015, lambda = 0.9989, x = 0, Br = 1, y=1/10], "Chartreuse");

Is this the kind of plot you had in mind?

Naturally, you can apply additional options and adjust the axis labels, etc.

1 2 3 4 5 6 7 Last Page 1 of 298