Smarter, you say? Then I hope the result of coulditbe(mU > 1-u) is false, not true... Actually, it is; but if you've already tried coulditbe(mU > 1-u) before setting _EnvTry to hard, you need

> forget(coulditbe);

otherwise it will just remember the FAIL value. BTW, _EnvTry is documented in the help page ?assume:

The environment variable _EnvTry can be used to specify the intensity of the testing by the is and coulditbe routines. Currently _EnvTry can be set to normal (the default) or hard. If _EnvTry is set to hard, is and coulditbe calls can take exponential time.

Following the hint given in the error message, I managed to make this work (after increasing maxmesh):

> sol := dsolve(rescale,[c(r),h(r),k(r)], 
    numeric, method=bvp[middefer], maxmesh=30000);

Following the hint given in the error message, I managed to make this work (after increasing maxmesh):

> sol := dsolve(rescale,[c(r),h(r),k(r)], 
    numeric, method=bvp[middefer], maxmesh=30000);

Actually it would work if you told Maple what was the variable, rather than having it guess:

> fsolve(Int(t, t = 0 .. x) = 1, x);

Actually it would work if you told Maple what was the variable, rather than having it guess:

> fsolve(Int(t, t = 0 .. x) = 1, x);

Hmm, it must be Maple 7 or before. Well then, the option is filename rather than output, and there's no provision for output to a string.

Hmm, it must be Maple 7 or before. Well then, the option is filename rather than output, and there's no provision for output to a string.

I suspect the bug occurs when "::odd" is being evaluated using evalhf (which plot uses to get the values to plot). Consider this:

>  for i from 1 to 10 do
   a := evalhf(piecewise(i::prime,0.0,1.0));
   if a = 0.0 then print(i,a) fi
 od:

1, 0. Does evalhf think that 1 is prime and 2, 3, 5, 7 are not? Actually I think what is happening is that evalhf just ignores the ::prime, so the first argument of the piecewise is evaluated as i. Now evalhf uses 1.0 and 0.0 to represent the boolean values true and false: it seems that anything except 1.0 is considered to be false. I would consider it to be a bug that evalhf ignores :: in this context. If it can't handle it correctly, it should result in an error (as type(i,prime) would).

I suspect the bug occurs when "::odd" is being evaluated using evalhf (which plot uses to get the values to plot). Consider this:

>  for i from 1 to 10 do
   a := evalhf(piecewise(i::prime,0.0,1.0));
   if a = 0.0 then print(i,a) fi
 od:

1, 0. Does evalhf think that 1 is prime and 2, 3, 5, 7 are not? Actually I think what is happening is that evalhf just ignores the ::prime, so the first argument of the piecewise is evaluated as i. Now evalhf uses 1.0 and 0.0 to represent the boolean values true and false: it seems that anything except 1.0 is considered to be false. I would consider it to be a bug that evalhf ignores :: in this context. If it can't handle it correctly, it should result in an error (as type(i,prime) would).

In this too-simple case, the exact solution is y(1)*`=`* tan(1 + arctan(w)) = (w+tan(1))/(1-w*tan(1)). So you're doing a Pade approximant of something that really should be a rational function with numerator and denominator of degree 1, and the coefficients of the higher terms are the result of numerical error. I'll see if I can put together a "collaborative book" contribution.

In this too-simple case, the exact solution is y(1)*`=`* tan(1 + arctan(w)) = (w+tan(1))/(1-w*tan(1)). So you're doing a Pade approximant of something that really should be a rational function with numerator and denominator of degree 1, and the coefficients of the higher terms are the result of numerical error. I'll see if I can put together a "collaborative book" contribution.

It's a curious bug. But in both Maple 10 and Maple 11 I get FAIL rather than true. So there's been some improvement...

It's a curious bug. But in both Maple 10 and Maple 11 I get FAIL rather than true. So there's been some improvement...

Besides removing the blank line which mariner mentioned, note that you're using t, not x, as the variable in eq. So this would work:

> yvals := map(s -> eval(eq,t=s), fs[1..50,1]);
  with(plots):
  xmin, xmax:= (min,max)(seq(fs[i,1],i=1..50));
  display([pointplot(fs), plot(eq,t=xmin..xmax)]);

Besides removing the blank line which mariner mentioned, note that you're using t, not x, as the variable in eq. So this would work:

> yvals := map(s -> eval(eq,t=s), fs[1..50,1]);
  with(plots):
  xmin, xmax:= (min,max)(seq(fs[i,1],i=1..50));
  display([pointplot(fs), plot(eq,t=xmin..xmax)]);