Thanks for pointing that out, Alejandro.

I didn't mention it because the objects produced by the operator that VectorCalculus:-D returns wil have an attached coordinate system. The Vector objects from VectorCalculus are not the same as usual Vector objects. They have a coordinate system as Maple attributes, and typeset differently.

> r:=t-><(x0*exp(-t/t0)*cos(t/t0),y0*exp(-t/t0)*sin(t/t0),z0*exp(-t/t0))>:

> dr:=VectorCalculus:-D(r):
> V1 := dr(u);
      /            u         u                u         u   \
      |  x0 exp(- ----) cos(----)   x0 exp(- ----) sin(----)|
      |            t0        t0               t0        t0  |
V1 := |- ------------------------ - ------------------------| e  +
      \             t0                         t0           /  x
 
    /            u         u                u         u   \
    |  y0 exp(- ----) sin(----)   y0 exp(- ----) cos(----)|
    |            t0        t0               t0        t0  |
    |- ------------------------ + ------------------------| e  -
    \             t0                         t0           /  y
 
              u
    z0 exp(- ----)
              t0
    -------------- e
          t0        z

That is not as good as simply this (and why can't D do it?),

> Dr:=unapply(map(diff,r(u),u),u):
> V2 := Dr(u);
               [            u         u                u         u   ]
               [  x0 exp(- ----) cos(----)   x0 exp(- ----) sin(----)]
               [            t0        t0               t0        t0  ]
               [- ------------------------ - ------------------------]
               [             t0                         t0           ]
               [                                                     ]
               [            u         u                u         u   ]
               [  y0 exp(- ----) sin(----)   y0 exp(- ----) cos(----)]
         V2 := [            t0        t0               t0        t0  ]
               [- ------------------------ + ------------------------]
               [             t0                         t0           ]
               [                                                     ]
               [                              u                      ]
               [                    z0 exp(- ----)                   ]
               [                              t0                     ]
               [                  - --------------                   ]
               [                          t0                         ]

And it's getting too complicated, for such a simple resquest, to do clear the attributes. (Why does VC have all sorts of commands for changing the Coordinates, but no obvious mention of how to remove them from one of its free Vectors?)

> rtable_options(V1,attributes=[]):
> V1;
            [            u         u                u         u   ]
            [  x0 exp(- ----) cos(----)   x0 exp(- ----) sin(----)]
            [            t0        t0               t0        t0  ]
            [- ------------------------ - ------------------------]
            [             t0                         t0           ]
            [                                                     ]
            [            u         u                u         u   ]
            [  y0 exp(- ----) sin(----)   y0 exp(- ----) cos(----)]
            [            t0        t0               t0        t0  ]
            [- ------------------------ + ------------------------]
            [             t0                         t0           ]
            [                                                     ]
            [                              u                      ]
            [                    z0 exp(- ----)                   ]
            [                              t0                     ]
            [                  - --------------                   ]
            [                          t0                         ]

acer

Thanks for pointing that out, Alejandro.

I didn't mention it because the objects produced by the operator that VectorCalculus:-D returns wil have an attached coordinate system. The Vector objects from VectorCalculus are not the same as usual Vector objects. They have a coordinate system as Maple attributes, and typeset differently.

> r:=t-><(x0*exp(-t/t0)*cos(t/t0),y0*exp(-t/t0)*sin(t/t0),z0*exp(-t/t0))>:

> dr:=VectorCalculus:-D(r):
> V1 := dr(u);
      /            u         u                u         u   \
      |  x0 exp(- ----) cos(----)   x0 exp(- ----) sin(----)|
      |            t0        t0               t0        t0  |
V1 := |- ------------------------ - ------------------------| e  +
      \             t0                         t0           /  x
 
    /            u         u                u         u   \
    |  y0 exp(- ----) sin(----)   y0 exp(- ----) cos(----)|
    |            t0        t0               t0        t0  |
    |- ------------------------ + ------------------------| e  -
    \             t0                         t0           /  y
 
              u
    z0 exp(- ----)
              t0
    -------------- e
          t0        z

That is not as good as simply this (and why can't D do it?),

> Dr:=unapply(map(diff,r(u),u),u):
> V2 := Dr(u);
               [            u         u                u         u   ]
               [  x0 exp(- ----) cos(----)   x0 exp(- ----) sin(----)]
               [            t0        t0               t0        t0  ]
               [- ------------------------ - ------------------------]
               [             t0                         t0           ]
               [                                                     ]
               [            u         u                u         u   ]
               [  y0 exp(- ----) sin(----)   y0 exp(- ----) cos(----)]
         V2 := [            t0        t0               t0        t0  ]
               [- ------------------------ + ------------------------]
               [             t0                         t0           ]
               [                                                     ]
               [                              u                      ]
               [                    z0 exp(- ----)                   ]
               [                              t0                     ]
               [                  - --------------                   ]
               [                          t0                         ]

And it's getting too complicated, for such a simple resquest, to do clear the attributes. (Why does VC have all sorts of commands for changing the Coordinates, but no obvious mention of how to remove them from one of its free Vectors?)

> rtable_options(V1,attributes=[]):
> V1;
            [            u         u                u         u   ]
            [  x0 exp(- ----) cos(----)   x0 exp(- ----) sin(----)]
            [            t0        t0               t0        t0  ]
            [- ------------------------ - ------------------------]
            [             t0                         t0           ]
            [                                                     ]
            [            u         u                u         u   ]
            [  y0 exp(- ----) sin(----)   y0 exp(- ----) cos(----)]
            [            t0        t0               t0        t0  ]
            [- ------------------------ + ------------------------]
            [             t0                         t0           ]
            [                                                     ]
            [                              u                      ]
            [                    z0 exp(- ----)                   ]
            [                              t0                     ]
            [                  - --------------                   ]
            [                          t0                         ]

acer

It can be demonstrated that some special mechanism is being used to get results to the canvas in Documents. But it is not the same as the usual print routine.

A simple demonstration of this fact can be done using a routine which has side-effects (ie. changes something globally whenever executed). Take the following as 2D Math input in a Document

restart;
f := proc() global x; x:=x+1; print("hi"); 17 end proc

x := 0

'f()'

x

When the above block is executed in the Document the value of x remains 0. If the View is changed to expand that whole document block (thus revealing those print calls) then, following manual execution of each line (including the print calls), the value of x gets changed to 1 and "hi" gets printed. The inference is that when the document block is collapsed and run it does not utilize the same kind of print call, since it does not evaluate its arguments and cause the side-effects.

In effect one cannot safely run run all the lines that appear when a document block is expanded. It would be better if those print calls were not shown in the expanded view, since they are demonstrably not equivalent to the actual mechanism used in the collapsed form. (It's just an anachronistic hold-over. If I recall, in some very early version of the Standard GUI, those really were actual print calls, and even running the collapsed view could bring about unintended side-effects.)

acer

It can be demonstrated that some special mechanism is being used to get results to the canvas in Documents. But it is not the same as the usual print routine.

A simple demonstration of this fact can be done using a routine which has side-effects (ie. changes something globally whenever executed). Take the following as 2D Math input in a Document

restart;
f := proc() global x; x:=x+1; print("hi"); 17 end proc

x := 0

'f()'

x

When the above block is executed in the Document the value of x remains 0. If the View is changed to expand that whole document block (thus revealing those print calls) then, following manual execution of each line (including the print calls), the value of x gets changed to 1 and "hi" gets printed. The inference is that when the document block is collapsed and run it does not utilize the same kind of print call, since it does not evaluate its arguments and cause the side-effects.

In effect one cannot safely run run all the lines that appear when a document block is expanded. It would be better if those print calls were not shown in the expanded view, since they are demonstrably not equivalent to the actual mechanism used in the collapsed form. (It's just an anachronistic hold-over. If I recall, in some very early version of the Standard GUI, those really were actual print calls, and even running the collapsed view could bring about unintended side-effects.)

acer

If you want to maximize the expression then instead of fiddling around manually with the partial derivatives you could try something like,

Optimization:-Maximize( ZV_or_what_have_you, assume=nonnegative);

acer

If you want to maximize the expression then instead of fiddling around manually with the partial derivatives you could try something like,

Optimization:-Maximize( ZV_or_what_have_you, assume=nonnegative);

acer

The most reliable way I have found to post to this forum is to use fixed-width (pre and /pre tags) for code. And it works best for me to edit it all entirely by hand in source mode. I hit the "Source" icon in the little iconbar above the editing box, to toggle between source and view modes. I insert all the <pre> and </pre> tags by hand.

I read your follow-up. I wasn't sure whether you still had any explicit questions.

Maybe I can say this: In Maple 13 and earlier, a unit is "attached" to an object by way of multiplication. (A lot of dimensional stuff just falls out nicely, in consequence of that, with units as multiplied qualities.) The Units:-Standard environment affects things that are entered at the "top-level", as direct commands. Loading that package rebinds the names such as  `+` and `*`, to provide units-aware versions of those operators. But the original global `+` and `*` are units-ignorant, which is why units don't simplify automatically in the arithmetic by default.

The `+` used in routines stored in the Maple Library is the global `+` (a.k.a. :-`+`), and similarly for multiplication, etc. Those global function name bindings are what get stored in Library routines and do not get affected even when Units:-Standard is loaded. Loading that package only affects the interactive top-level `+` that one types in. But it doesn't automatically render any of the Library routines as units-aware. Something to keep in mind.

acer

The most reliable way I have found to post to this forum is to use fixed-width (pre and /pre tags) for code. And it works best for me to edit it all entirely by hand in source mode. I hit the "Source" icon in the little iconbar above the editing box, to toggle between source and view modes. I insert all the <pre> and </pre> tags by hand.

I read your follow-up. I wasn't sure whether you still had any explicit questions.

Maybe I can say this: In Maple 13 and earlier, a unit is "attached" to an object by way of multiplication. (A lot of dimensional stuff just falls out nicely, in consequence of that, with units as multiplied qualities.) The Units:-Standard environment affects things that are entered at the "top-level", as direct commands. Loading that package rebinds the names such as  `+` and `*`, to provide units-aware versions of those operators. But the original global `+` and `*` are units-ignorant, which is why units don't simplify automatically in the arithmetic by default.

The `+` used in routines stored in the Maple Library is the global `+` (a.k.a. :-`+`), and similarly for multiplication, etc. Those global function name bindings are what get stored in Library routines and do not get affected even when Units:-Standard is loaded. Loading that package only affects the interactive top-level `+` that one types in. But it doesn't automatically render any of the Library routines as units-aware. Something to keep in mind.

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

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