acer

32373 Reputation

29 Badges

19 years, 334 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

In 2D math input mode, type \ (ie. the backslash key) before typing _ (ie. underscore, usually Shift-minus keystrokes) in order to have the underscore symbols be displayed literally.

That should work before and after Maple 17. In Maple 16 and earlier typing a single underscore would lower the prompt to the subscript position. In Maple 17 and later that happens when two underscores are typed in succession.

You can often use the resulting name as intended, even when it's inadvertantly displayed as a subscript in the input. But it looks weird afterwards, and may be confusing if you come back to the Document at a later date. Using the backslash helps it look as intended, with underscores displayed literally.

See the help topic tasks/building/annotate/mathModeShortcut , or the table entry on escaping characters in the help topic worksheet/documenting/2DMathShortcutKeys .

acer

The `int` command provides an option `AllSolutions` which allows it to attempt and return a piecewise solution with conditions on parameters in the range of integration.

For this example this produces results equivalent to what one gets under assumptions. The result for the case x<0 is the same as what I get under assumptions if I also call `simplify`(...under the same assumption on x).

If you set up the call to `int` or `Int` yourself then this can be done by adding the option `AllSolutions`. The alternate spelling as `allsolutions` is also ok.

restart:

ee := Int((x-tau)^(0.5-1)*(tau^2+(tau^(1.5))*(8/(3))-tau-(2)*tau^0.5),
                         tau=0..x, allsolutions):

value(ee);

value( convert(ee,rational) );

If the integral call was produced by some other command then you can also enable this behavior with an environment variable (so that you don't have to mess with `op` in order to shoehorn that option into the `int` or `Int` call).

restart:

ee := Int((x-tau)^(0.5-1)*(tau^2+(tau^(1.5))*(8/(3))-tau-(2)*tau^0.5),
                         tau=0..x):

_EnvAllSolutions:=true:

value(ee);

value( convert(ee,rational) );

That all works in my Maple 18.01.

The result in the piecewise solution for condition x<=0 evaluates to zero for x=0 (the empty integration range). When I tried this example using assumptions on x instead of the `AllSolutions` option I could get a direct result for the assumption x<0 but not for x≤0.

acer

In a Document, apply a context-menu operation to either 2D Math input of output. This produces a black right-arrow and a result.

Now select the right-arrow and the output beside it with the mouse cursor. Then from the GUI's main menu select View , and Expand Execution Group

The hidden command that was applied, as the context-menu action, should be revealed.

On my Linux, those main menu choice are available as the keyboard acceleration, Alt-v then x

acer

Welcome to the site. Welcome to Maple! It's not as hard to use as it might seem at first.

There were several errors in your code, as you guessed.

There were mismatched start- and endbraces in both lambda1 and lambda2.

The assignments to R[0] and R[1] were just equations with `=`, not actual assignments with `:=`.

You were assigning to `R` after assigning to R[0] and R[1]. Assigning to `R` will wipe out those assignments to R[0] and R[1].

You were mixing up expressions and operators. You had `R` defined as an operator, but then were using it with `subs` as if it were an expression.

Here is a way, with RR as an expression.

restart:
f := .25; g := 1; R[0] := 5; R[1] := 4.8; nDays := 30;
lambda1 := (1 - f + sqrt((1 - f) + 4*g*f))*1/2;
lambda2 := (1 - f - sqrt((1 - f) + 4*g*f))*1/2;
k1 := (-lambda2*R[0] + R[1] )/(lambda1 - lambda2);
k2 := ( lambda2*R[0] - R[1])/(lambda1 - lambda2);
RR := k1*lambda1^N + k2*lambda2^N;
for n from 2 to nDays do
  evalf(subs(N=n,RR));
end do;

Here is a way, with RR as an operator.

restart:
f := .25; g := 1; R[0] := 5; R[1] := 4.8; nDays := 30;
lambda1 := (1 - f + sqrt((1 - f) + 4*g*f))*1/2;
lambda2 := (1 - f - sqrt((1 - f) + 4*g*f))*1/2;
k1 := (-lambda2*R[0] + R[1] )/(lambda1 - lambda2);
k2 := ( lambda2*R[0] - R[1])/(lambda1 - lambda2);
RR := N -> k1*lambda1^N + k2*lambda2^N;
for n from 2 to nDays do
  evalf(RR(n));
end do;

I suggest you study Robert Israel's great post of Top Ten Maple Errors.

acer

If you are in an Execution Group then the command from a right-click context-menu action is inserted as 1D Maple Notation, and then that gets executed. This happens whether you right-click on 2D Math input or 2D Math output.

If you are in a paragraph in a Presentation/Document Block then the command used by a right-click context-menu action is not visible as an explicit command. In later versions of Maple (including Maple 15) the inserted right-arrow may also be annoted, as a GUI preference. But that's not the same as giving you the actual command executed.

It's possible to insert an Execution Group (red cursor prompt, red input by default) in a Document, but it is awkward.

So if you like the context-menus and want to see commands used by them, explicitly, then you might find it much easier to use Worksheets rather than Documents.

acer

You can either enter the command yourself, or you can use the right-click context-menu which has an entry for taking limits.

Here is how it can look, by entering the commands yourself,

ee := ((2 + x)^3 +8)/x;

                                          3    
                                   (2 + x)  + 8
                             ee := ------------
                                        x      

limit(ee, x=0);

                                  undefined

limit(ee, x=0, right);

                                  infinity

limit(ee, x=0, left);

                                  -infinity

You can also use the Limit Tutor. From the main menubar select Tools -> Tutors -> Calculus - Single Variable, -> Limit Methods.

acer

expr := x + y + z;
                               expr := x + y + z

convert(expr,`*`);
                                     x y z

convert(expr,list);
                                   [x, y, z]

`*`( op(expr) ); 
                                     x y z

[ op(expr) ];    
                                   [x, y, z]

It wasn't clear whether you want to transform expr into both, or run through them as follows.

x + y + z;
                                   x + y + z

convert(%,`*`); 
                                     x y z

convert(%,list);
                                   [x, y, z]

x + y + z;
                                   x + y + z

`*`(op(%));
                                     x y z

[op(%)];   
                                   [x, y, z]

All you need to know here is that `op` returns the operands of a sum or product of terms. (I use the terms sum and product in the mathematical sense rather than in the sense of commands `sum` and `product`.) So `op` produces the expression sequence x,y,z when applied to either the sum or the product.

acer

You haven't told us your purpoise, so we have to guess.

restart:

tneighbors := proc(G::Graph)
  uses GraphTheory;
  local i, V;
  V := Vertices(G);
  {seq(`if`(nops(Neighbors(G,V[i]))=2, i, NULL), i=1..nops(V))};
end proc:

with(GraphTheory):

G1 := Graph( Trail(1,2,3,4,5,6,7,8,9,10,1), Trail(11,12,6,11,1,12) ):
#DrawPlanar(G1);

tneighbors( G1 );

                   {2, 3, 4, 5, 7, 8, 9, 10}

select(v->nops(Neighbors(G1,v))=2, {op(Vertices(G1))});

                   {2, 3, 4, 5, 7, 8, 9, 10}

# This kind of thing is generally suboptimal, as the quadratic memory
# cost of augmenting a set is unnecessary.
tneighbors2 := proc(G::Graph)
  uses GraphTheory;
  local i, S, V;
  V := Vertices(G);
  S := {}:
  for i from 1 to nops(V) do
    if nops(Neighbors(G,V[i]))=2 then
      S := S union {i};
    end if;
  end do;
  return S;
end proc:

tneighbors2( G1 );

                   {2, 3, 4, 5, 7, 8, 9, 10}

tneighbors3 := proc(G::Graph)
  uses GraphTheory;
  local i, T, V;
  V := Vertices(G);
  for i from 1 to nops(V) do
    if nops(Neighbors(G,V[i]))=2 then
      T[i] := i;
    end if;
  end do;
  return {indices(T,nolist)};
end proc:

tneighbors3( G1 );

                   {2, 3, 4, 5, 7, 8, 9, 10}

acer

The NAG quadrature solvers such as _d01amc have hard-coded weights that are only suitable for handling a double-precision approximation of each evaluation of the integrand. That's why evalf/Int won't let one use those methods with Digits greater than evalhf(Digits), or with the option `digits=d` and `d` that high.

And on the surface it may seem like this always means an insurmountable wall for integrands with subexpressions which may evaluate to outside the double-precision range, or for integrands which suffer from great roundoff error.

Also, when these methods were first introduced the evaluations of the integrand (a callback from NAG to Maple) were only allowed in `evalhf` mode.

But it is possible (since I forget when... Maple 9?, 10?) to use a non-evalhf'able procedure as the integrand with the three NAG univariate quadrature methods. Such a procedure is free to manage Digits internal to itself.

So two things could then happen, for such a procedure. Roundoff error in the individual integrand approximations might be reigned in. And values outside the usual 1e-308 to 1e308 range might be handled.

Having said that, it's often a good idea to keep the working precision of the rest of the solver as high as it can go (option digits=15) while allowing the tolerance (epsilon) to be relaxed optionally.

This seems enough to be able to get quick results for the various parameter pair values given. It's not going to solve all other numerically hard problems, but it seems to be adequate here.

The following results appear to match what others found (even with alternate, slow methods). But they compute quickly.

restart:

expr := exp(-x)^j*(1-exp(-x))^(4-j)*beta^alpha
        /GAMMA(alpha)*x^(alpha-1)*exp(-beta*x):

G:=proc(A, B, J, ee, {eps::float:=1e-14})
  local f;
  f:=subs(__DUMMY=eval(ee,[alpha=A,beta=B,j=J]),
          proc(x) Digits=50; []; __DUMMY;
          end proc);
  forget(evalf); forget(`evalf/int`);
  evalf(Int(f, 0..infinity, ':-digits'=15, ':-epsilon'=eps,
            ':-method'=':-_d01amc'));
end proc:

CodeTools:-Usage(
   seq( 'G'( 900, 50, j, expr ), j=0..4 )
                );

memory used=1.97KiB, alloc change=0 bytes, cpu time=0ns, real time=1000.00us, gc time=0ns

                                          -8                     -21  
    0.999999927237869, 1.81905311687842 10  , 4.25712142901189 10   , 

                         -27                     -33
      2.19976264687971 10   , 1.13667316831278 10   

CodeTools:-Usage(
   seq( 'G'( 45.2895968537810, 6.34934081467530, j, expr ), j=0..4 )
                );

memory used=2.22KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns, gc time=0ns

    0.994712351662338, 0.00131579418350684, 0.00000406276781217926, 

                         -8                     -10
      2.42436962707272 10  , 2.45623513060466 10   

CodeTools:-Usage(
   seq( 'G'( 0.1, 50, j, expr, eps=1e-9 ), j=0..4 )
                );

memory used=2.29KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns, gc time=0ns

                       -8                          
    9.76825547933535 10  , 0.00000158951838518320, 

      0.0000389398475682795, 0.00185661752266041, 0.992333435120739

## This will force 100 calls to G, taking 11.75 sec total on my i7
#CodeTools:-Usage(
#   plot( 'G'( a, 50, 2, expr ), a=0.1..100, adaptive=false, numpoints=100 )
#                );
## ## This will force 100 calls to G, taking 9.27 sec total on my i7
#CodeTools:-Usage(
#   plot( 'G'( a, 6.35, 2, expr ), a=40..50, adaptive=false, numpoints=100 )
#                );

The only fly in the ointment I saw was the case of high j=4 in the original example or alpha=0.1, beta=50. I found that case could be handled quickly, even at epsilon=1e-10, by a change of variables turning the range into t=0..1.

Lastly, I hard-coded Digits=50 into that procedure `G`. But it could alternatively be made an option of `G`, if it needed increasing.

 

acer

I don't think that it's easier to write a procedure for what is essentially a single command.

eq := f(z) = g(z):

map(Int, eq*K, z=1..L);       

                           L                L
                          /                /
                         |                |
                         |   K f(z) dz =  |   K g(z) dz
                         |                |
                        /                /
                          1                1

Replace `Int` with `int` if you want it active.

A procedure might make it easier if you didn't know yet what the name of the variable (of integration) was in the expressions on both sides of the equation. But if you already know the name of the variable of integration, the multiplicand K, the equation, and the range of integration then it's as simple to execute the command above as it is to call a procedure, no?

acer

Plotting can be done with two basic approaches: expressions, or procedures.

Here is an example of plotting an expression `f`. Notice that for this way of calling the `plot` command the second argument (which gives the range) has the name of the indeterminate variable on the left hand side of an equation. Note that expression `f` will evaluate differently if you happen to also assign to the name `x`.

f := x^2 - x;

eval( f, x=1.1 );  # evaluation at a single point

plot( f, x=-3..3 );

Here is an example of plotting with a procedure (an `arrow` operator is just a convenient way to define a simple procedure). Notice that the `x` in the definition of procedure `g` is just a dummy name. That dummy name `x` used in the definition of `g` has nothing to do with the global variable `x`, which you can still assign to without affecting how procedure `g` works.

g := x -> x^2 - x;

g( 1.1 );  # evaluation at a single point

plot( g, -3..3);

Read the manuals. I suggest you start with commands (here) rather than Clickable Math (here or here). Look for a copy of Andre Heck's book. Have a read through Robert Israel's list of Top Ten Errors (and, in this case, pay close attention to his item 1 of the 10).

If you have a problem with understanding an error message from Maple in future, and ask here for advice, then please provide detail about the error message. It's not reasonable to expect accurate help if you provide no detail. Good Luck.

I believe that an example such as,

f := x -> x^2 - x;
plot( f(x), x=-3..3 );

may confuse some new users, and is not so useful. I believe that it unnecessarily conflates the concepts of expression and procedure/operator. It is fundamental that new users get that distinction crystal clear. Slightly better is,

f := x -> x^2 - x;
plot( f(t), t=-3..3 );

but it's still not great form (IMO) to introduce an operator simply to make an expression from a function call to it. I see new users who create operators only to use them just once, to form an expression. This often devolves to something like,

f := unapply( x^2 - x, x );
plot( f(x), x=-3..3 );

where `f` is only used for that single plot. It works, but so often the new user who codes this way has little or no idea just why it works or what might break it.

acer

restart:

f:=evalf[10](Pi);
                          3.141592654

convert(f, rational);

                             104348
                             ------
                             33215 

evalf[20](%);

                     3.1415926539214210447

convert(f, rational, exact);

                           1570796327
                           ----------
                           500000000 

evalf[20](%);

                     3.1415926540000000000

acer

I see the same results in 64bit Maple 18.01, as well as 32bit/64bit Maple 16.02 and Maple 11.02, all for Windows.

I suppose that you may have already figured out that for a univariate polynomial p with real coefficients fsolve(p,x) will invoke RootFinding:-Isolate (with the method being RS by default).

If you execute fsolve(p,x,complex) then at default working precision this gets done successfully by the modified Laguerre method via the NAG c02agc function. And the root near 1.018 is in the returned sequence of roots. It doesn't resort to `fsolve/polyill`.

Offhand I don't know why Isolate's RS method goes wrong on your particular example.

I wonder whether fsolve should try both of Isolate's methods in such a case. (Well, it should certainly try something else, for an odd degree univariate polynomial with real coefficients if Isolate's method=RS returns null, since there must be one real root, as you say!).

For what it may be worth, you can reduce the typing a little, as I believe that the behaviour is the same for

-65658-18554*x-186255*x^2-97616*x^3-238885*x^4+582426*x^5

acer

Here is an attempt. This is an interesting topic, and a generalized methodology (that accomodates the limitations of how ISOSURFACE 3D plot structures work) would be useful.

(Sorry that this site renders the inlined plots poorly. They look a bit better in the GUI, and manually rotating them reveals more detail.)

 

restart:

opts := x=-5..5,y=-5..5,z=-5..5, grid=[20,20,20]:

lts:=[x^2+x*(y+2*z)-1, y^2+y*(x+2*z)-3];
eqs:=y*z*(x+y+2*z)^3-8;

[x^2+x*(y+2*z)-1, y^2+y*(x+2*z)-3]

y*z*(x+y+2*z)^3-8

cover:=plots:-implicitplot3d(max(lts[]), opts,
                             style=surface, transparency=0.7, color=blue):

# The purpose of `coverB` is that when displayed alongside `cover` they
# indicate which is the inner, feasible region of space with boundary `cover`.

coverB:=plots:-implicitplot3d(max(lts[])+2,opts,
                              style=patch, transparency=0.5, color=green):
# The following illustrates that the region between (inside) the blue
# surfaces is the feasible region defined by the constraints.
#
# The same could be done for each of the inequalities, separately, for
# further illustration.

plots:-display(cover, coverB, lightmodel=none);

targ:=plots:-implicitplot3d(eqs, opts,
                            style=patch, transparency=0.0, color=gold):

# The answer should be the portion of the gold surface which lies in
# the feasible region between the two blue surfaces.

plots:-display(cover, targ, lightmodel=none);

# I suspect that this technique is related to how 3D implicit plots are
# rendered by the GUI. The ISOSURFACE plot structure does not explicitly
# contain a set of points at which the implicit function's evaluations
# are zero (the surface), or even close to zero. Rather, the ISOSURFACE
# is a full 3D grid of x,y,z points and function values, and the interface
# itself interpolates and renders.
# This is likely related to why it handles cusp discontinuously smooth
# surfaces badly (producing no surface), because it is looking for zero-
# crossings.
# On account of these posited behaviors, it seems to work best to produce
# implicit functions which cross zero carefully, and which also behave
# well near only the constraints.
#
# If Maple's 3D implicit plotting were adaptive and capable of handling
# jump dicontinuity, etc, then we could approach such problems by simply
# constructing a procedure which returned some arbitrarily chosen
# positive constant value whenever the input point was not feasible. But
# with the current mechanism that does not work in general, and often
# produces either a surface warped away from the correct surface, or spurious
# (infeasible) surface portions, or an empty result.
#
# The following seems to work, producing the red surface for y*z*(x+y+2*z)^3-8
# inside the feasible region defined by x^2+x*(y+2*z)-1<0 and y^2+y*(x+2*z)-3<0.
 
hola:=plots:-implicitplot3d(min(eqs,-max(lts)),opts, grid=[40,40,40],
                            style=patch, color=red):

plots:-display(cover, hola, lightmodel=none);

 


Download ineq3dz.mw

acer

Why do you have to compute all the permutations before you classify them?

Why do you keep spamming this site with duplicates of the same question?

acer

First 236 237 238 239 240 241 242 Last Page 238 of 336