8 years, 364 days

These are answers submitted by acer


Yesterday at 3:17 PM acer 10211
0 0

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


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:


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

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}


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.


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

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

   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   

   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   

   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

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




September 25 2014 acer 10211
2 1

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?


expressions and procedures

September 22 2014 acer 10211
1 1

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.



September 22 2014 acer 10211
0 0


convert(f, rational);




convert(f, rational, exact);






September 16 2014 acer 10211
1 2

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




September 16 2014 acer 10211
2 3

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



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];

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


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

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




why all at once?

September 16 2014 acer 10211
0 0

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?



September 12 2014 acer 10211
0 1

Yes, it is possible.



September 04 2014 acer 10211
0 0

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.



September 04 2014 acer 10211
3 1

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



September 02 2014 acer 10211
2 7

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

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,



                  259.8556695 + 5.313756679 I


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



September 02 2014 acer 10211
4 12

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.


multiplication intended?

September 01 2014 acer 10211
4 2

If you intend that expression as a multiplication (and not as a compound function application) then insert an explicit multiplication sign (ie. the * on you keyboard) between the two bracketed terms.


                            (x - 4) 


                          x(x - 4) - 4

Otherwise your input would can get parsed as the function application x(x-a) - a(x-a). That is, the compound operator (x-a) applied to the argument x-a.

Note that 4 applied to x-4 (or pretty much anything) produces a result of 4.

There are some situations, including your example, where an extra blank space between the two bracketed terms would also get interpreted implicitly as a multiplication, if you used 2D Math input mode. In 1D Notation that would produce a parsing error. It can get more confusing still. I suggest getting in the habit of always using an explicit multiplication symbol, to avoid ambiguous situations with implicit multiplication.



September 01 2014 acer 10211
2 2

One way is to make your absolutely qualified filenames be a concatenation of a base location and some relative paths.

# Uncomment the line you want, and comment out the line you don't want.
#base:="C:/officeplace/location 1/":
#base:="C:/homecomputer/location 2/":


readdata(..., datafileA, ...);
readdata(..., datafileB, ...);

Another way could be to use the currentdir command to set the current working directory.


1 2 3 4 5 6 7 Last Page 1 of 99