Student:-Calculus1:-Roots does in fact use fsolve with the avoid option. (But it uses it cleverly and repeatedly, until it ascertains that no more roots are in each generated subinterval.)

It's been for many years and Maple major releases that fsolve has, by default, returned only a single solution for the case of anything by a univariate polynomial. Changing that default would break a lot of users' code, so is a Bad Idea. Allowing it with some new syntax, such as fsolve(...,maxsols=all, <ranges>) might be ok.

Student:-Calculus1:-Roots is not bad, but one can write a 20 line procedure that is measurably faster, using RootFinding:-NextZero. You might also try the routine from Robert Israel's Maple Advisor Database which computes all real roots on a finite range.

acer

Student:-Calculus1:-Roots does in fact use fsolve with the avoid option. (But it uses it cleverly and repeatedly, until it ascertains that no more roots are in each generated subinterval.)

It's been for many years and Maple major releases that fsolve has, by default, returned only a single solution for the case of anything by a univariate polynomial. Changing that default would break a lot of users' code, so is a Bad Idea. Allowing it with some new syntax, such as fsolve(...,maxsols=all, <ranges>) might be ok.

Student:-Calculus1:-Roots is not bad, but one can write a 20 line procedure that is measurably faster, using RootFinding:-NextZero. You might also try the routine from Robert Israel's Maple Advisor Database which computes all real roots on a finite range.

acer

> 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

> 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