Int is the inert form of int. Your initial code was getting stuck trying to do the exact, symbolic int calculations. It would take a long time and a lot of memory for each call, and it would make separate attempt for each distinct x and y.

The inert form Int doesn't do anything at all. It just sits there. It gets typeset nicely with a pretty integral symbol. That is all very deliberate and very useful.

The plot routine will call evalf on the expression. But Maple knows something special about calls that look like evalf(Int(...)). It knows to treat those as numerical integration (quadrature), instead of as exact symbolic integration computations. Maple can do the numerical integrals easily, in your example.

So, the suggestion allowed Maple to completely avoid even attempting the doomed symbolic integration computations, and to wait until the evalf call from plot made it do numeric integration.

acer

Int is the inert form of int. Your initial code was getting stuck trying to do the exact, symbolic int calculations. It would take a long time and a lot of memory for each call, and it would make separate attempt for each distinct x and y.

The inert form Int doesn't do anything at all. It just sits there. It gets typeset nicely with a pretty integral symbol. That is all very deliberate and very useful.

The plot routine will call evalf on the expression. But Maple knows something special about calls that look like evalf(Int(...)). It knows to treat those as numerical integration (quadrature), instead of as exact symbolic integration computations. Maple can do the numerical integrals easily, in your example.

So, the suggestion allowed Maple to completely avoid even attempting the doomed symbolic integration computations, and to wait until the evalf call from plot made it do numeric integration.

acer

Sure, the prepost item on the Layour palette is a little weird. But at least its tooltip doesn't give the entirely wrong impression (unlike the new `A[n]`; tooltip for subliterals).

The prepost is like presubsup[d]^e. It doesn't look quite a odd as your post indicates, with defaults fonts and styles. There is no entirely atomic equivalent available on the palette, and no mixed version available via context-menu conversion. The plain prepost object is this,

`#mscripts(mi("A"),none(),none(),none(),none(),mi("b"),mi("c"))`[d]^e

but there is no wholly atomic palette item that gives this,

`#mscripts(mi("X"),mi("d"),mi("e"),nome(),none(),mi("b"),mi("c"))`

It should not be surprising that not all variations are present separately on the palette, however. There are six places for these decorations around the base symbol. Four of those could be present or not. The other two could be absent, present in an atomic identifier way, or present as power or table-reference. Who would want to have to sift a palette with 2^4*3^2 = 144 layout choices.

Consider the general beast,

`#mscripts(mi("X"),mi("f"),mi("e"),mi("d"),mi("c"),mi("b"),mi("a"))`

Perhaps there could be a better mechanism for entering such objects on the palette, without requiring a separate entry for each combination. A more flexible and complete mechanism might allow one to independently toggle the right-super and right-lower decorations as atomic versus power (`^`) and table reference (`[]`).

Perhaps the 1D/2D Math conversion in the context-menu could also allow both or either to be toggled.

acer

> E := t* (1-exp(-(1-t)^2/(2*o^2))):
> g := oo -> rhs(op(Optimization:-Maximize(eval(E,o=oo),t=0..1)[2])):

> eval(E,o=1/2);
                                                2
                           t (1 - exp(-2 (1 - t) ))
 
> Optimization:-Maximize(%,t=0..1);
              [0.205693857126463153, [t = 0.417189146242829434]]
 
> g(1/2);
                             0.417189146242829434

> plot(g,0..1,view=[0..1,0..1]);

acer

> E := t* (1-exp(-(1-t)^2/(2*o^2))):
> g := oo -> rhs(op(Optimization:-Maximize(eval(E,o=oo),t=0..1)[2])):

> eval(E,o=1/2);
                                                2
                           t (1 - exp(-2 (1 - t) ))
 
> Optimization:-Maximize(%,t=0..1);
              [0.205693857126463153, [t = 0.417189146242829434]]
 
> g(1/2);
                             0.417189146242829434

> plot(g,0..1,view=[0..1,0..1]);

acer

This is just the sort of thing that the 2-argument form of the eval command is for.

sol := NLPSolve(...);

Then use eval(model,sol[2]) instead of model.

acer

This is just the sort of thing that the 2-argument form of the eval command is for.

sol := NLPSolve(...);

Then use eval(model,sol[2]) instead of model.

acer

You might start with the manuals, as they are immediately available and range from beginner to advanced.

They can be downloaded as PDFs here, or read as online documents here.

acer

You might start with the manuals, as they are immediately available and range from beginner to advanced.

They can be downloaded as PDFs here, or read as online documents here.

acer

I should note that the use...end use becomes irrelevant, in this approach, and those two examples work with it removed. What I showed is merely a hackish alternative, given your special situation with mixed strings. Also, you may wish to sometimes use subs instead of eval.

acer

I should note that the use...end use becomes irrelevant, in this approach, and those two examples work with it removed. What I showed is merely a hackish alternative, given your special situation with mixed strings. Also, you may wish to sometimes use subs instead of eval.

acer

I forget whether everything you wanted equal turned out to be equal. (I hazily recall seeing some result that didn't seem to match your expectation, but I could be mistaken.)

The best course of action would be to upgrade from 12.00 to 12.02, and run it yourself.

Seeing `ee` means nothing, in itself. It's a bug in 12.00. If Maple 12 returns `ee` for simplify(A-B) then no, it isn't safe to conclude that A-B is zero (or the zero Matrix).

acer

I forget whether everything you wanted equal turned out to be equal. (I hazily recall seeing some result that didn't seem to match your expectation, but I could be mistaken.)

The best course of action would be to upgrade from 12.00 to 12.02, and run it yourself.

Seeing `ee` means nothing, in itself. It's a bug in 12.00. If Maple 12 returns `ee` for simplify(A-B) then no, it isn't safe to conclude that A-B is zero (or the zero Matrix).

acer

You are making use of PDEtools notational shortcuts for derivatives, via that package loading.

The result from VectorCalculus:-Jacobian contains derivatives which merely display like f[x,x], etc. But the underlying object contains derivatives and not indexed name f[x,x]. So attempting to subs for the indexed name f[x,x] accomplishes nothing.

For example,

> restart:
> with(PDEtools): declare(prime):
         The prime differentiation variable has not been declared yet
 
> Q := diff(diff(f(x),x),x);
                                 Q := f[x, x]
 
> subs(f[x,x]=17,Q);
                                    f[x, x]
 
> subs(f[x,x]=17,f[x,x]);
                                      17
 
> lprint(Q);
diff(diff(f(x),x),x)

> subs(diff(diff(f(x),x),x)=17,Q);
                                      17

By the way, VectorCalculus produces Matrices, not matrices. Matrices do not have last_name_eval and do not require eval() or evalm() as matrices do.

acer

You are making use of PDEtools notational shortcuts for derivatives, via that package loading.

The result from VectorCalculus:-Jacobian contains derivatives which merely display like f[x,x], etc. But the underlying object contains derivatives and not indexed name f[x,x]. So attempting to subs for the indexed name f[x,x] accomplishes nothing.

For example,

> restart:
> with(PDEtools): declare(prime):
         The prime differentiation variable has not been declared yet
 
> Q := diff(diff(f(x),x),x);
                                 Q := f[x, x]
 
> subs(f[x,x]=17,Q);
                                    f[x, x]
 
> subs(f[x,x]=17,f[x,x]);
                                      17
 
> lprint(Q);
diff(diff(f(x),x),x)

> subs(diff(diff(f(x),x),x)=17,Q);
                                      17

By the way, VectorCalculus produces Matrices, not matrices. Matrices do not have last_name_eval and do not require eval() or evalm() as matrices do.

acer