Sorry, I think that the refresh option of SetProperty is new to Maple 13. I'm not sure that it can be done in Maple 12, to update components like that. By default, the Math container doesn't get updated until the Button returns control.

If I come up with a kludge to do it with components then I'll post it.

You should be able to get such progressive updating with Maplets instead of GUI Components in Maple 12, I believe.

acer

Given a math component MathContainer3, it works for me with the following Button code ("Action When Clicked" in the Button's Component Properties).

  to 4 do
    r:=evalf(Statistics:-Sample(
               Statistics:-RandomVariable(
                 Normal(0,1)),1)[1],1);
    if not assigned(LL) then
      LL:=[r];
    else
      LL:=[op(LL),r];
    end if;
    DocumentTools:-SetProperty( MathContainer3, 'value', r,
                                'refresh'=true );
    st:=time[real]();
    while time[real]()-st < 2 do end do;
  end do:

ps. I'll leave aside any efficiency issues in that use of Statistics:-Sample. Hope that's ok.

acer

Given a math component MathContainer3, it works for me with the following Button code ("Action When Clicked" in the Button's Component Properties).

  to 4 do
    r:=evalf(Statistics:-Sample(
               Statistics:-RandomVariable(
                 Normal(0,1)),1)[1],1);
    if not assigned(LL) then
      LL:=[r];
    else
      LL:=[op(LL),r];
    end if;
    DocumentTools:-SetProperty( MathContainer3, 'value', r,
                                'refresh'=true );
    st:=time[real]();
    while time[real]()-st < 2 do end do;
  end do:

ps. I'll leave aside any efficiency issues in that use of Statistics:-Sample. Hope that's ok.

acer

Actually, I believe that you should already have what you're looking for in the earlier response. Perhaps a minor change to the name of procedure FF would help make it more understandable for you.

It's not entirely clear what you mean by a "stored" function y(x). I gave two solutions. The first involved a procedure, as a function of x, which returned the pair x, y(x) such that f(x,y(x))=0.

> f := (x,y) -> cos(x+y): # or more complicated
> y := x->(x,fsolve(f(x,Y),Y=0..3)): # returns x,Y pair
> g := (a,b)->a^2+b:
> y(0.17);
                               0.17, 1.400796327
 
> f(y(0.17)); # essentially zero
                                              -9
                              -0.2051033808 10

> g(y(0.17));
                                  1.429696327
 
> plot( 'g@y'(x), x=0..0.5 );

The second sort of solution consisted of a precomputed array of pairs x,y(x) such that f(x,y(x))=0. The pairs are all "stored" in the plot structure assigned to P1. Then, a transformation of that stored data was made, so as to apply g to x,y(x).

> P1:=plots:-implicitplot(f,0..1/2,1.1..1.6):
> k:=plottools:-transform((a,b)->[a,g(a,b)]):
> plots:-display(k(P1));

The two plots generated by these two different approaches look the same, naturally.

ps. In your followup you mentioned g[x, f(x)], but that seems a typo. Your orginal post had f as taking two arguments, and mentioned g[x,y(x)].

acer

Actually, I believe that you should already have what you're looking for in the earlier response. Perhaps a minor change to the name of procedure FF would help make it more understandable for you.

It's not entirely clear what you mean by a "stored" function y(x). I gave two solutions. The first involved a procedure, as a function of x, which returned the pair x, y(x) such that f(x,y(x))=0.

> f := (x,y) -> cos(x+y): # or more complicated
> y := x->(x,fsolve(f(x,Y),Y=0..3)): # returns x,Y pair
> g := (a,b)->a^2+b:
> y(0.17);
                               0.17, 1.400796327
 
> f(y(0.17)); # essentially zero
                                              -9
                              -0.2051033808 10

> g(y(0.17));
                                  1.429696327
 
> plot( 'g@y'(x), x=0..0.5 );

The second sort of solution consisted of a precomputed array of pairs x,y(x) such that f(x,y(x))=0. The pairs are all "stored" in the plot structure assigned to P1. Then, a transformation of that stored data was made, so as to apply g to x,y(x).

> P1:=plots:-implicitplot(f,0..1/2,1.1..1.6):
> k:=plottools:-transform((a,b)->[a,g(a,b)]):
> plots:-display(k(P1));

The two plots generated by these two different approaches look the same, naturally.

ps. In your followup you mentioned g[x, f(x)], but that seems a typo. Your orginal post had f as taking two arguments, and mentioned g[x,y(x)].

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

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