> ArrayTools:-RandomArray(1,2);
                [0.959492426392902997    0.792207329559554418]
 
> rtable(1..2,random(1..50));
                                    [9, 47]
 
> S := Statistics:-RandomVariable(DiscreteUniform(1, 50)):
> Statistics:-Sample(S,2);
                                   [2., 43.]
 
> LinearAlgebra:-RandomMatrix(1,2,generator=1..50);
                                  [37    48]
 
> Array(1..2,RandomTools:-Generate(list(integer(range=1..50),2)));
                                    [28, 7]
 
> Array(1..2,RandomTools:-Generate(integer(range=1..50),makeproc=true));
                                    [3, 14]

acer

It seems that the Online Help is somewhat broken with respect to searches for topics containing an underscore.

For example, searching failed to find the page on special evaluation rules, even when either the partial "spec" or the full help-topic "spec_eval_rules" were tried. (One strange aspect here was that the unrelated last_name_eval did come up in the results, and that even has underscores in it.)

Another example was for convert/unit_free. Searching for "unit_free", or "convert/unit_free", or "convert,unit_free" all failed. (There appears to be a link to convert/unit_free at the bottom of the convert/units page. But it is broken, pointing at the invalid Convert/unit_free.)

acer

The difference is that add has special evaluation rules while sum does not.

One can fake it, with sum, by judicious use of uneval quotes (right-single-quotes).

> test2 := j->seq(x[j-i mod 24], i = 0 .. 8):
> test2(3);
           x[3], x[2], x[1], x[0], x[23], x[22], x[21], x[20], x[19]
 
> test := j->sum(x['j-i mod 24'], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]
 
> test := j->sum(x['`mod`'(j-i,24)], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]

When you used sum, it evaluated the arguments up front and worked with this,

> x[j-i mod 24];
                                  x[j + 23 i]
 
> seq(%, i = 0 .. 8);
x[j], x[j + 23], x[j + 46], x[j + 69], x[j + 92], x[j + 115], x[j + 138],
 
    x[j + 161], x[j + 184]

Since add has special evaluation rules, it can delay the application of mod until j and i have values.

acer

The difference is that add has special evaluation rules while sum does not.

One can fake it, with sum, by judicious use of uneval quotes (right-single-quotes).

> test2 := j->seq(x[j-i mod 24], i = 0 .. 8):
> test2(3);
           x[3], x[2], x[1], x[0], x[23], x[22], x[21], x[20], x[19]
 
> test := j->sum(x['j-i mod 24'], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]
 
> test := j->sum(x['`mod`'(j-i,24)], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]

When you used sum, it evaluated the arguments up front and worked with this,

> x[j-i mod 24];
                                  x[j + 23 i]
 
> seq(%, i = 0 .. 8);
x[j], x[j + 23], x[j + 46], x[j + 69], x[j + 92], x[j + 115], x[j + 138],
 
    x[j + 161], x[j + 184]

Since add has special evaluation rules, it can delay the application of mod until j and i have values.

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

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