Robert Israel

6577 Reputation

21 Badges

18 years, 217 days
University of British Columbia
Associate Professor Emeritus
North York, Ontario, Canada

MaplePrimes Activity


These are replies submitted by Robert Israel

For a numerical approximation, use dsolve(..., numeric).  For example:

> S:= dsolve({1/sin(t)*diff(v(t),t)+v(t)=sin(t), v(0)=0}, 
              v(t), numeric);
   plots[odeplot](S, t=0..30, numpoints=300);

Maple can't find a closed form expression for an antiderivative, probably because there isn't one.  But it can evaluate integrals numerically even if they don't have closed form expressions.  Therefore it can plot them.  For example:

> plot(Int(cos((1+sin(t))^(1/2)), t=0..x), x=0 .. 2*Pi);

 

Maple can't find a closed form expression for an antiderivative, probably because there isn't one.  But it can evaluate integrals numerically even if they don't have closed form expressions.  Therefore it can plot them.  For example:

> plot(Int(cos((1+sin(t))^(1/2)), t=0..x), x=0 .. 2*Pi);

 

Of course there's no guarantee that the first solution Maple finds is the one you want.

Of course there's no guarantee that the first solution Maple finds is the one you want.

Your transform is not quite right: you want the first r value to be 1 and the 41st to be 3, so that would mean 1 + 2*(r-1)/40; you want the first theta value to be 45 degrees  = Pi/4 and the 91st to be -Pi/4, so that would mean (46-th)* Pi/180.  Thus

f:= transform(proc (r, th) options operator, arrow;
[(1.0+2.0*(r-1)/40.0).cos((46-th)*Pi/180.0),
(1.0+2.0*(r-1)/40.0).sin((46-th).Pi/180.0)] 
end proc):

And then if you want a view option, it's:

display(f(pc), view = [1/sqrt(2) .. 3, -3/sqrt(2) .. 3/sqrt(2)]);

But I also made a mistake: the orientation of my 3d plot was wrong.  It should have been orientation=[-90, 0].

Your transform is not quite right: you want the first r value to be 1 and the 41st to be 3, so that would mean 1 + 2*(r-1)/40; you want the first theta value to be 45 degrees  = Pi/4 and the 91st to be -Pi/4, so that would mean (46-th)* Pi/180.  Thus

f:= transform(proc (r, th) options operator, arrow;
[(1.0+2.0*(r-1)/40.0).cos((46-th)*Pi/180.0),
(1.0+2.0*(r-1)/40.0).sin((46-th).Pi/180.0)] 
end proc):

And then if you want a view option, it's:

display(f(pc), view = [1/sqrt(2) .. 3, -3/sqrt(2) .. 3/sqrt(2)]);

But I also made a mistake: the orientation of my 3d plot was wrong.  It should have been orientation=[-90, 0].

It works for me in both Classic and Standard interfaces.  Here's what it looks like for me, using Classic 11.02.

Download 4541_surfdata_plotting_problem.mws
View file details

It works for me in both Classic and Standard interfaces.  Here's what it looks like for me, using Classic 11.02.

Download 4541_surfdata_plotting_problem.mws
View file details

I don't know how I omitted it from my previous posting, but, as the error message states, when multiplying by Pi/180 you have to convert the result to a floating point type.
So the line

Data[i,j,2]:= Data[i,j,2]*Pi/180

could be replaced by

Data[i,j,2]:= evalhf(Data[i,j,2]*Pi/180)

and then it ought to work.  You may also want to add the option

scaling = constrained

in the surfdata command.

I don't know how I omitted it from my previous posting, but, as the error message states, when multiplying by Pi/180 you have to convert the result to a floating point type.
So the line

Data[i,j,2]:= Data[i,j,2]*Pi/180

could be replaced by

Data[i,j,2]:= evalhf(Data[i,j,2]*Pi/180)

and then it ought to work.  You may also want to add the option

scaling = constrained

in the surfdata command.

Since the differential equation doesn't have series solutions with polynomial coefficients, 'coeffs'='polynomial' doesn't work.  'coeffs'='mhypergeom' does work,
with a similar result as using Slode[mhypergeom_formal_sol] (not surprising, since this is what dsolve calls to do the work).

Since the differential equation doesn't have series solutions with polynomial coefficients, 'coeffs'='polynomial' doesn't work.  'coeffs'='mhypergeom' does work,
with a similar result as using Slode[mhypergeom_formal_sol] (not surprising, since this is what dsolve calls to do the work).

It looks like this bug was fixed in Maple 10.

It looks like this bug was fixed in Maple 10.

First 135 136 137 138 139 140 141 Last Page 137 of 187