## 13613 Reputation

19 years, 252 days

## One coordinate system for all frames...

Same thing happens with plot3d.

Maybe animate is finding a coordinate system in which all frames can be displayed?

It would be quite annoying if the following animation changed the view between frames.

animate(plot,[sin(x),x=-a..a],a=1..10);

which it doesn't.

## Integers versus reals...

In range = a..b the length of the real interval [a, b] is b-a. The code could be written from that point of view (not unreasonable).

In your example the matrix has integral values (1,2,3,4), so b-a would result in 3.

## Integers versus reals...

In range = a..b the length of the real interval [a, b] is b-a. The code could be written from that point of view (not unreasonable).

In your example the matrix has integral values (1,2,3,4), so b-a would result in 3.

## Residues are equal, but so what?...

Yes, the two sides have simple poles at 2 with the same residues. But so what?

series(lhs(eq),x=2);
1        (-1)   1
- (x - 2)     + -
2               2
series(rhs(eq),x=2,2);
1        (-1)   3   1           /       2\
- (x - 2)     + - + -- x - 2 + O\(x - 2) /
2               8   32

## Residues are equal, but so what?...

Yes, the two sides have simple poles at 2 with the same residues. But so what?

series(lhs(eq),x=2);
1        (-1)   1
- (x - 2)     + -
2               2
series(rhs(eq),x=2,2);
1        (-1)   3   1           /       2\
- (x - 2)     + - + -- x - 2 + O\(x - 2) /
2               8   32

## Plot in the complex plane...

A plot in the complex plane (R^2) could then be done by

plots[odeplot](Sol, [x(t),y(t)],t=0..4);

## Plot in the complex plane...

A plot in the complex plane (R^2) could then be done by

plots[odeplot](Sol, [x(t),y(t)],t=0..4);

## Delay in posting?...

Please take a look at my last suggestion. It is identical to the one you are proposing.

## Delay in posting?...

Please take a look at my last suggestion. It is identical to the one you are proposing.

## Declarations?...

Do the declarations

global ICs;
local cx, cy;

have any effect? They don't appear to me to have any effect.

However, if your code is wrapped inside a procedure, it seems to work fine.

proc()
global ICs;
local cx, cy;
use DocumentTools in
Do(cx = %Plot1(clickx));
Do(cy = %Plot1(clicky));
ICs := ICs, y(cx)=cy;
Do(%Plot1 = DEtools[DEplot](de, y(x), x = -3 .. 3, y = -3 .. 3, [ICs], linecolour=blue))
end use;
end proc();

## Declarations?...

Do the declarations

global ICs;
local cx, cy;

have any effect? They don't appear to me to have any effect.

However, if your code is wrapped inside a procedure, it seems to work fine.

proc()
global ICs;
local cx, cy;
use DocumentTools in
Do(cx = %Plot1(clickx));
Do(cy = %Plot1(clicky));
ICs := ICs, y(cx)=cy;
Do(%Plot1 = DEtools[DEplot](de, y(x), x = -3 .. 3, y = -3 .. 3, [ICs], linecolour=blue))
end use;
end proc();

## Attempt at an explanation...

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
#convert~(dlist,rational) gives
#[0, (1/6)*Pi, (1/3)*Pi, (1/2)*Pi, (2/3)*Pi, (5/6)*Pi, Pi, (7/6)*Pi, (4/3)*Pi, (3/2)*Pi, (5/3)*Pi, (11/6)*Pi, 2*Pi]

#The following doesn't take much time:

S:=[seq(limit(csc(6*x),x=dlist[k]),k=1..nops(dlist))];
# There are 3 kinds of results, which are shown below.
Sn:=ListTools:-Enumerate(S):
#For these values of k the results are as they ought to be. Not surprising, since they
#correspond to integral multiples of Pi/2, so that no roundoff error is possible:
op~(1,select(has,Sn,Float(undefined)));
[1, 4, 7, 10, 13]
#For these values of k the limits are unevaluated:
op~(1,select(has,Sn,limit));
[2, 3, 5, 6, 11, 12]
#For the remaining two values of k the limits are evaluated to large absolute values:
op~(1,remove(has,Sn,{Float(undefined),limit}));
[8, 9]

#Now with these results in mind the following results are not surprising
seq(time(evalf(S[k])),k=1..nops(dlist));
0.015, 17.472, 17.550, 0., 17.674, 17.518, 0.015, 0., 0., 0., 17.768, 17.737, 0.

The unevaluated limits take about the same amount of time.

So what remains to explain is, why does limit succeed on its own for k = 8 and k = 9, i.e. corresponding to dlist-values 1.166666667*Pi and 1.333333333*Pi?

In Maple 13 the first results of limit (S above) are the same as in Maple 14. But using evalf on S doesn't change S at all, i.e. evalf/limit gives up and does it quickly.

In Maple 14 seq(evalf(S[k]),k=1..nops(dlist)); actually evaluates the previously unevaluated limits and that takes up the time. Maybe it ought to have given up.

## Attempt at an explanation...

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
#convert~(dlist,rational) gives
#[0, (1/6)*Pi, (1/3)*Pi, (1/2)*Pi, (2/3)*Pi, (5/6)*Pi, Pi, (7/6)*Pi, (4/3)*Pi, (3/2)*Pi, (5/3)*Pi, (11/6)*Pi, 2*Pi]

#The following doesn't take much time:

S:=[seq(limit(csc(6*x),x=dlist[k]),k=1..nops(dlist))];
# There are 3 kinds of results, which are shown below.
Sn:=ListTools:-Enumerate(S):
#For these values of k the results are as they ought to be. Not surprising, since they
#correspond to integral multiples of Pi/2, so that no roundoff error is possible:
op~(1,select(has,Sn,Float(undefined)));
[1, 4, 7, 10, 13]
#For these values of k the limits are unevaluated:
op~(1,select(has,Sn,limit));
[2, 3, 5, 6, 11, 12]
#For the remaining two values of k the limits are evaluated to large absolute values:
op~(1,remove(has,Sn,{Float(undefined),limit}));
[8, 9]

#Now with these results in mind the following results are not surprising
seq(time(evalf(S[k])),k=1..nops(dlist));
0.015, 17.472, 17.550, 0., 17.674, 17.518, 0.015, 0., 0., 0., 17.768, 17.737, 0.

The unevaluated limits take about the same amount of time.

So what remains to explain is, why does limit succeed on its own for k = 8 and k = 9, i.e. corresponding to dlist-values 1.166666667*Pi and 1.333333333*Pi?

In Maple 13 the first results of limit (S above) are the same as in Maple 14. But using evalf on S doesn't change S at all, i.e. evalf/limit gives up and does it quickly.

In Maple 14 seq(evalf(S[k]),k=1..nops(dlist)); actually evaluates the previously unevaluated limits and that takes up the time. Maybe it ought to have given up.

## evalf(limit) takes up the time...

Digging into where the procedure discont seems to take up the time, it appears that

`plot/discontplot`:-ModuleApply

calls the procedure discontlist local to `plot/discontplot`

which in turn calls another procedure alldisconts local to `plot/discontplot`.

Now `plot/discontplot`::alldisconts contains a procedure g which is mapped onto a list of problematic points called dlist.

So what seems to be happening is this:

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
g:=proc(z) local t,s;
try
t:=limit(csc(6*x),x=z);
if type(evalf(t),'numeric') then
try
s:=eval(csc(6*x),x=z);
if s=t then return NULL end if
catch:
end try;
return [z,t] else
return NULL
end if
catch:
return NULL
end try
end proc:
time(map(g,dlist));
105.222

#It really is evalf on the unevaluted limits that takes up the time:

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
time(evalf(seq(limit(csc(6*x),x=dlist[k]),k=1..nops(dlist))));
105.285

In Maple 13:

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
time(evalf(seq(limit(csc(6*x),x=dlist[k]),k=1..nops(dlist))));
0.748

## evalf(limit) takes up the time...

Digging into where the procedure discont seems to take up the time, it appears that

`plot/discontplot`:-ModuleApply

calls the procedure discontlist local to `plot/discontplot`

which in turn calls another procedure alldisconts local to `plot/discontplot`.

Now `plot/discontplot`::alldisconts contains a procedure g which is mapped onto a list of problematic points called dlist.

So what seems to be happening is this:

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
g:=proc(z) local t,s;
try
t:=limit(csc(6*x),x=z);
if type(evalf(t),'numeric') then
try
s:=eval(csc(6*x),x=z);
if s=t then return NULL end if
catch:
end try;
return [z,t] else
return NULL
end if
catch:
return NULL
end try
end proc:
time(map(g,dlist));
105.222

#It really is evalf on the unevaluted limits that takes up the time:

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
time(evalf(seq(limit(csc(6*x),x=dlist[k]),k=1..nops(dlist))));
105.285

In Maple 13:

restart;
dlist := [0., .1666666667*Pi, .3333333333*Pi, .5000000000*Pi, .6666666667*Pi, .8333333333*Pi, 1.000000000*Pi, 1.166666667*Pi, 1.333333333*Pi, 1.500000000*Pi, 1.666666667*Pi, 1.833333333*Pi, 2.000000000*Pi]:
time(evalf(seq(limit(csc(6*x),x=dlist[k]),k=1..nops(dlist))));
0.748

 First 219 220 221 222 223 224 225 Last Page 221 of 229
﻿