That solution may behave differently than you expect, since you have used a set (about which Maple has its own notion of element ordering).

A more reliable solution would be,

> coefficients:={j = -139.55659155625, k = -3.8511665004543}:
> eval(j,coefficients);
                               -139.55659155625

Consider, in Maple 11 where ordering of set elements was by memory address.

> restart:
> coefficients:={j = -139.55659155625, k = -3.8511665004543};
         coefficients := {j = -139.55659155625, k = -3.8511665004543}

> rhs(coefficients[1]);
                               -139.55659155625

> restart:
> coefficients:={j = -139.55659155625, k = -3.8511665004543};
         coefficients := {k = -3.8511665004543, j = -139.55659155625}

> rhs(coefficients[1]);
                               -3.8511665004543

> eval(j,coefficients);
                               -139.55659155625

Also, in Maple 13, the ordering of set elements is not according to the order in which they appear in the input.

> coefficients:={k = -3.8511665004543, j = -139.55659155625}:
> rhs(coefficients[2]);
                               -3.8511665004543

> eval(j,coefficients);
                               -139.55659155625

That solution may behave differently than you expect, since you have used a set (about which Maple has its own notion of element ordering).

A more reliable solution would be,

> coefficients:={j = -139.55659155625, k = -3.8511665004543}:
> eval(j,coefficients);
                               -139.55659155625

Consider, in Maple 11 where ordering of set elements was by memory address.

> restart:
> coefficients:={j = -139.55659155625, k = -3.8511665004543};
         coefficients := {j = -139.55659155625, k = -3.8511665004543}

> rhs(coefficients[1]);
                               -139.55659155625

> restart:
> coefficients:={j = -139.55659155625, k = -3.8511665004543};
         coefficients := {k = -3.8511665004543, j = -139.55659155625}

> rhs(coefficients[1]);
                               -3.8511665004543

> eval(j,coefficients);
                               -139.55659155625

Also, in Maple 13, the ordering of set elements is not according to the order in which they appear in the input.

> coefficients:={k = -3.8511665004543, j = -139.55659155625}:
> rhs(coefficients[2]);
                               -3.8511665004543

> eval(j,coefficients);
                               -139.55659155625

I think that it is a bug in the 2D Math presentation. That same formula displays with (-1)^n in the commandline and Classic GUI interfaces' help.

Uneval quotes can be used here.

 res1 := 0;
 id1:= Create(bar(param1), 'res1');

Uneval quotes can be used here.

 res1 := 0;
 id1:= Create(bar(param1), 'res1');

The usual drawbacks to RootFinding:-Analytic are that it is slower and that the complex values get in the way if only purely real roots are wanted.

On the one hand, the "complex box" that Analytic computes over should not be taken very "thin" (very narrow imaginary range) as that can produce numerical difficulties in calculating the contour integrals (residues). On the other hand, making the complex box wide enough to compute safely (and then easily using select and fnormal to sieve out the nonreal results) can make it slow.

The usual drawbacks to RootFinding:-Analytic are that it is slower and that the complex values get in the way if only purely real roots are wanted.

On the one hand, the "complex box" that Analytic computes over should not be taken very "thin" (very narrow imaginary range) as that can produce numerical difficulties in calculating the contour integrals (residues). On the other hand, making the complex box wide enough to compute safely (and then easily using select and fnormal to sieve out the nonreal results) can make it slow.

Yes, and it's possible to view the source code and see that Student:-Calculus1:-Roots is itself calling fsolve with its avoid option.

I might have expected RootFinding:-NextZero to also get the next real root for this example.

Yes, and it's possible to view the source code and see that Student:-Calculus1:-Roots is itself calling fsolve with its avoid option.

I might have expected RootFinding:-NextZero to also get the next real root for this example.

If your Linux truly is an x86-64 distribution then you should be able to install and run the X86_64_LINUX version of Maple, regardless of whether your chip is AMD or Intel.

The x86-64 platform is supported by the Intel Core2 Duo (for example, or the P4EE, etc) just as it is supported by the AMD Athlon (etc).

Basically, any issues or problems would more likely be between the Linux OS and the Maple Installer or binaries, rather than with your (presumably modern) x86-64 capable hardware.

collect(M1,x);

collect(M1,x);

So your problematic Case 2 corresponds to my guess and suggested workaround, no?

plot(unapply(g2, t), 0..200*Unit(s));

plot(unapply(g2, t), 0..200*Unit(s), useunits=[Unit(s),Unit(m/s)]);

So your problematic Case 2 corresponds to my guess and suggested workaround, no?

plot(unapply(g2, t), 0..200*Unit(s));

plot(unapply(g2, t), 0..200*Unit(s), useunits=[Unit(s),Unit(m/s)]);

> restart:
> P:=15000:
> E:=proc(x) option remember;
>   -E(x-1)*(-11*P+10*E(x-1))/P;
> end proc:
> E(1):=1:
> kernelopts(printbytes=false):
> st:=time(): length(E(20)); time()-st;
                                    3348149

                                    92.177

> restart:
> P:=15000:
> E:=proc(x) option remember;
>   evalf( -E(x-1)*(-11*P+10*E(x-1))/P );
> end proc:
> E(1):=1:
> st:=time(): E(20); time()-st;
                                             17778
                             -0.5132751215 10

                                      0.