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.)

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

Yes, it is possible.

acer

Issue the command time[real]() at the start, and assign the result to a name. Then issue it again when the student clicks, and subtract.

acer

solve does not like solve for unevaluated function calls such as your n(SPF) and n(SPH).

So change those to just name like say nSPF and nSPH (or n*SPF and n*SPH if that's what you intended). Both succeed for me in M18.01.

For example,

ineq:=-s*(-n(SPF)*tau+n(SPH))/(tau-1) <= n(SPH):
soln := solve(subs([n(SPF)=nSPF,n(SPH)=nSPH],ineq),nSPH) assuming (tau<1,s>0,s<1,tau>0):
subs([nSPF=n(SPF),nSPH=n(SPH)],soln);

acer

Do not introduce `k` and `x` with floats. Use exact quantities instead. That should get around the discrepancy in Maple 9.5.

restart;
k:=99/100:
m:=1:
x:=(Pi*csc(Pi*(k-m)))/(693/1000*GAMMA(k)*GAMMA(m)):
m1:=MeijerG([[-m],[1-m]],[[0,-m,-m],[k-m]],(-m*k)/snr):
m2:=MeijerG([[-k],[1-k]],[[0,-k,-k],[m-k]],(-m*k)/snr):
c:=x*((((m*k)/snr)^m)*m1-(((m*k)/snr)^k)*m2):
plot([Re(c),Im(c)], snr=-5..10, color=[red,blue]);

In particular, when using those floats in the definitions of `k` and `x` as you had it originally, Maple 9.5 will produce this,

restart;
k:=.99:
m:=1:
x:=(Pi*csc(Pi*(k-m)))/(.693*GAMMA(k)*GAMMA(m)):
m2:=MeijerG([[-k],[1-k]],[[0,-k,-k],[m-k]],(-m*k)/snr):

evalf(eval(m2,snr=5));

                  259.8556695 + 5.313756679 I

exactm2:=convert(m2,rational,exact):
evalf(eval(exactm2,snr=5));

                  6.225950422 - 2.656878345 I

The above may not just be a roundoff issue -- ie. increasing precision might not fix it. You might have to use exact rationals in the arguments to MeijerG.

An alternative workaround for Maple 9.5 could be to convert your `c` (or perhaps just `m2`) expression to exact rational prior to plotting, manipulating expression `c`, or querying `c` at float values of `snr`.

acer

You can do this by first creating a PlotComponent (say, with identity/name of "Plot0") and then pushing a revised plot to it with each new value computed.

In ths attached example I include a `Sleep` call merely to mimic a computation that takes some time.

ticker.mw

acer