Asymptotes are not always vertical.

expr:=(x^2-4*x+5)/(x-2);
asy:=Student:-Calculus1:-Asymptotes(expr);
P1:=plot(expr,view=[-10..10,-10..10],discont=false):
P2:=plots:-implicitplot(asy,x=-10..10,y=-10..10,color=[blue,green]):
plots:-display(P1,P2);

Asymptotes are not always vertical.

expr:=(x^2-4*x+5)/(x-2);
asy:=Student:-Calculus1:-Asymptotes(expr);
P1:=plot(expr,view=[-10..10,-10..10],discont=false):
P2:=plots:-implicitplot(asy,x=-10..10,y=-10..10,color=[blue,green]):
plots:-display(P1,P2);

The entries of an Array (or Matrix or Vector) are restricted to 8 byte floats only if the Array has the 'float[8]' datatype. If it has datatype=anything then other types may be assigned to the entries.

The entries of an Array (or Matrix or Vector) are restricted to 8 byte floats only if the Array has the 'float[8]' datatype. If it has datatype=anything then other types may be assigned to the entries.

The op command returns the operands of an expression. In this case expr is a product, so the operands are its multiplicands.

You'll have noticed that the commands I issued were based on a distinction amongst the operands that were noticable "by eye". You want something more automatic, so you can easily apply similar simplifications to other expressions.

It might help if you can post one or two more typical expressions in your class.

The op command returns the operands of an expression. In this case expr is a product, so the operands are its multiplicands.

You'll have noticed that the commands I issued were based on a distinction amongst the operands that were noticable "by eye". You want something more automatic, so you can easily apply similar simplifications to other expressions.

It might help if you can post one or two more typical expressions in your class.

Maybe the system is having a problem with some characters in the filename, such as the é. Perhaps you could try renaming it.

Maybe the system is having a problem with some characters in the filename, such as the é. Perhaps you could try renaming it.

Linear programming (LP) problems with linear constraints don't need a global solver, a local optimum is a global optimum.

The simplex algorithm is merely one way to solve LP problems. The Optimization package's LPSolve routine solves them using an "active set" method. The Minimize routine in Optimization will detect that the inputs specify an LP problem and dispatch to LPSolve automatically.

The is an older simplex package. It is implemented as a set of Maple Library routines and so should be proportionately much slower than the compiled Optimization package's routines for non-small problems. The simplex package handles rationals as is, while Optimization converts everything to floating-point.

Linear programming (LP) problems with linear constraints don't need a global solver, a local optimum is a global optimum.

The simplex algorithm is merely one way to solve LP problems. The Optimization package's LPSolve routine solves them using an "active set" method. The Minimize routine in Optimization will detect that the inputs specify an LP problem and dispatch to LPSolve automatically.

The is an older simplex package. It is implemented as a set of Maple Library routines and so should be proportionately much slower than the compiled Optimization package's routines for non-small problems. The simplex package handles rationals as is, while Optimization converts everything to floating-point.

It's easy enough to compare them for some simple finite tasks.

> restart:
> st:=time(): evalf(Sum(i,i=1..10^6)); time()-st;
                                              12
                               0.5000005000 10

                                     3.052

> restart:
> st:=time(): add(evalf(i),i=1..10^6); time()-st;
                                              12
                               0.5000005000 10

                                     0.640

> restart:
> st:=time(): for k to 10^4 do evalf(Sum(i,i=k+1..k+98)); od:
> time()-st;
                                     2.440

> restart:
> st:=time(): for k to 10^4 do add(evalf(i),i=k+1..k+98); od:
> time()-st;
                                     0.580

It's not just assigned values to k that can cause a problem. The various k's from different levels can collide and interact if they are not distinct locals.

In your code, the n-k passed as the 3rd argument to the next call gets used as the value of parameter n in that next recursion. So constructions such as n-k-k and k=0..n-k start to occur. It makes a difference if the k's in 4-k-k cancel (same global k) or not (distinct local k's).

At one point, you wrote originally that "two executions are equivalent". Yet in one of them 4-u a symbolic value is passed as the 3rd argument while in the other a numeric value is passed. The routine `evalf/Sum`, and routines called underneath it, could use different internal methods to handle such cases.

What you are missing is that evalf/Sum does not have special evaluation rules. ( See ?spec_eval_rules ) As a consequence, it evaluates its arguments up front. And so, when used inside a proc, its index of summation must not evaluate to something (including under scoping). The best way to ensure that is to declare the index name as local to the proc in which its called.

What Maple is missing is clear explanation of this on the ?sum and ?evalf/Sum help pages.

Below, you can see that it matters that seq and add have special evaluation rules for their arguments,

> k:=3:

> seq(k,k=1..4);
                                  1, 2, 3, 4
 
> add(k,k=1..4);
                                      10
 
> sum(k,k=1..4);
Error, (in sum) summation variable previously assigned,
second argument evaluates to 3 = 1 .. 4

> sum('k','k'=1..4);
                                      10

> evalf(Sum(k,k=1..4));
                                      4
                                    -----
                                     \
                                      )   3
                                     /
                                    -----
                                    3 = 1

> evalf(Sum('k','k'=1..4));
                                      10.

It's a simple consequence of the `imaginary` property (real part is zero) as described on  the?property page and the given assumption (real and strictly positive). The inability to ascertain the `false` result is a bug.

It's a simple consequence of the `imaginary` property (real part is zero) as described on  the?property page and the given assumption (real and strictly positive). The inability to ascertain the `false` result is a bug.