Just put any relevant bits inside a for...do loop, and inside the loop create a variety of plots and assign them to names P[i], say. Here's an example. (This particular trivial example below could be done more simply, but it might illustrate a methodology for you.)

> elist := [1,2,3]:
> for i from 1 to 3 do
>   g:=eval( sin(e*x), e=elist[i] );
>   P[i] := plot( g, x=-6..6 );
> end do:
> plots:-display( [seq(P[i],i=1..3)] );

acer

Just put any relevant bits inside a for...do loop, and inside the loop create a variety of plots and assign them to names P[i], say. Here's an example. (This particular trivial example below could be done more simply, but it might illustrate a methodology for you.)

> elist := [1,2,3]:
> for i from 1 to 3 do
>   g:=eval( sin(e*x), e=elist[i] );
>   P[i] := plot( g, x=-6..6 );
> end do:
> plots:-display( [seq(P[i],i=1..3)] );

acer

Different types of problem can merit different types of methodology.

My Maple gets a single solution point using Optimization:-Minimize in 0.005 sec (with 0.01sec to load Optimization's external libs on only the first attempt). That's 1000 times faster than using LinearMultivariateSystem in that way.

For embedding inside a program that needs to repeatedly get a single valid feasible point, the faster way may be much more desirable. If a more involved calculation had to solve one hundred distinct systems then the difference in contribution of 500sec versus 0.5sec should be obvious.

The OP may well have had in mind a characterization of all integer solutions, but didn't say so explicitly. It seems pretty reasonable to me: different approaches for quite different tasks.

acer

Different types of problem can merit different types of methodology.

My Maple gets a single solution point using Optimization:-Minimize in 0.005 sec (with 0.01sec to load Optimization's external libs on only the first attempt). That's 1000 times faster than using LinearMultivariateSystem in that way.

For embedding inside a program that needs to repeatedly get a single valid feasible point, the faster way may be much more desirable. If a more involved calculation had to solve one hundred distinct systems then the difference in contribution of 500sec versus 0.5sec should be obvious.

The OP may well have had in mind a characterization of all integer solutions, but didn't say so explicitly. It seems pretty reasonable to me: different approaches for quite different tasks.

acer

It's usually better to use add instead of sum for adding a finite number of terms.

I modified it slightly so that y(x) returns a scalar rather than the x,Y pair, as it may be more clear.

For fun, I made a general expression from f. And I created L with the given values of N, e, and d instantiated within it. I did not assign to N, e, or d at the top-level. (All that doesn't make much difference in this example, since f calls non-evalhf'able fsolve. But in another example, it might allow plot to use the fast evalhf interpreter because there'd be no lexical scoping.)

restart:

f:=(x,y)-> -N+add(1/(exp(e*((n-x)^2-y))-1),n=-50..50):
fexpr:=subs(N=10000,e=0.2,d=1/(e*N),f(x,Y)):
                                                                                
y:=unapply('fsolve'(fexpr,Y=0..x^2),x):
y(.4);
                                                                                
Lproto:=(a,b)-> -(1/N)*add((n-a)/(exp(e*((n-a)^2-b))-1),n=-50..50):
L:=subs(N=10000,e=0.2,d=1/(e*N),eval(Lproto)):
                                                                                
L(0.452,y(0.452));
                                                                                
plot(t->L(t,y(t)), 0.1..0.45); # 26sec, little memory

Note that the plot only starts at 0.1. It runs OK in Maple 12.01 or Maple 13. When starting from 0.01 that plot comsumes huge memory resources -- I'm not yet sure precisely why.

acer

It's usually better to use add instead of sum for adding a finite number of terms.

I modified it slightly so that y(x) returns a scalar rather than the x,Y pair, as it may be more clear.

For fun, I made a general expression from f. And I created L with the given values of N, e, and d instantiated within it. I did not assign to N, e, or d at the top-level. (All that doesn't make much difference in this example, since f calls non-evalhf'able fsolve. But in another example, it might allow plot to use the fast evalhf interpreter because there'd be no lexical scoping.)

restart:

f:=(x,y)-> -N+add(1/(exp(e*((n-x)^2-y))-1),n=-50..50):
fexpr:=subs(N=10000,e=0.2,d=1/(e*N),f(x,Y)):
                                                                                
y:=unapply('fsolve'(fexpr,Y=0..x^2),x):
y(.4);
                                                                                
Lproto:=(a,b)-> -(1/N)*add((n-a)/(exp(e*((n-a)^2-b))-1),n=-50..50):
L:=subs(N=10000,e=0.2,d=1/(e*N),eval(Lproto)):
                                                                                
L(0.452,y(0.452));
                                                                                
plot(t->L(t,y(t)), 0.1..0.45); # 26sec, little memory

Note that the plot only starts at 0.1. It runs OK in Maple 12.01 or Maple 13. When starting from 0.01 that plot comsumes huge memory resources -- I'm not yet sure precisely why.

acer

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

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