Carl Love

Carl Love

28100 Reputation

25 Badges

13 years, 106 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@acer 

I was doing what you suggested as you were entering the above comment. See my comment above.

@ 

It's a great solution technique, but setting [A=0, B=0] really trivializes the problem. Here is a way to use other parameters and still have it be automatic.


restart:

ODE1:=A*u(t)^2+B*u(t)*(h(t)+C)+E*h(t)=F*cos(u(t));

A*u(t)^2+B*u(t)*(h(t)+C)+E*h(t) = F*cos(u(t))

(1)

eqic:=A*u1^2+B*u1*C=F*cos(u1);

A*u1^2+B*u1*C = F*cos(u1)

(2)

ODE2:=diff(h(t),t)=u(t):

#I added parameter G for u(0).

sol:=dsolve({ODE1,ODE2,h(0)=0,u(0)=G},type=numeric,parameters=[A,B,C,E,F,G],stiff=true,maxfun=0):

params:= [1,1,1,1,1]:

#Need to do an fsolve to get the value of u(0).

u0:= fsolve(eval(eqic, [A,B,C,D,F]=~ params), u1);

.5500093499

(3)

sol('parameters'= [params[], u0]):

with(plots):

odeplot(sol,[t,h(t)],0..3);

 

odeplot(sol,[t,u(t)],0..1);

 

 

 


Download ODEtoDAE_2.mw

@Dave L 

I heartily support user-supplied tolerances for fsolve, something akin to what is available for numerical integration. I've encountered many problems where the failure of fsolve to converge seems to be caused by the tolerance being too close to the working precision.

@Kitonum 

Okay, I see your point. I would rather that plot3d have an option to specify the handedness than needing to switch the order of the arguments, but it is the way that it is.

@Kitonum 

Yes, I was well aware that plot3d allows the abominable syntax x= 0..1, y= 0..x, but I'd prefer to forget it because that syntax encourages sloppy mathematical thinking.

I'll rephrase my advice:

I find it most useful to remember that one should set the ranges in plot3d to be exactly the same as the ranges that one would use for a double integral of the surface over the region in question.

I find it most useful to remember that the limit ranges for the variables in a plot3d are exactly the same as the limits you would use to set up a double integral of the surface over the region in question.

@nm 

Yeah, the hypergeometric answer is wrong and clearly cannot be evaluated for integer n. Sorry that I didn't check that before posting. I have no idea where this answer comes from.

@Mac Dude

 By "closing a paragraph," the OP means collapsing a section.

@nm 

So, the semantics of Pi and pi are identical in Maple and Mathematica. The only difference is how they are treated by the help system. I think that there needs to be a help page ?pi because using pi when one means Pi is one of the most common newbie errors. The same is probably true for Mathematica newbies.

@mobosmobos 

Please let me know how it goes.

@Carl Love 

I am surprised that the above Answer has not attracted more attention. This failure to follow the McCarthy rules is a serious and AFAIK undocumented problem. Even worse, I just discovered that (at least in Maple 16) when using 2D input infix logical operators are always translated to prefix form and thus the McCarthy rules cannot be used in 2D input! For the OP, that means that the code cannot be run in 2D input: You will need to switch to 1D input, which many of us on MaplePrimes would recommend anyway.

You can also get around this by recoding your logical expression to use the `if` operator, like this:

if ST:-IsPrefix(y, x) and
     `if`(assigned(P[x]), ST:-IsPrefix(P[x], y), true)
then
     P[x]:= y
end if

@tomleslie 

Why is the coefficient 20, not 10?

@Markiyan Hirnyk 

Thanks for spotting that. I corrected the Answer.

Your code runs in Maple 16 without error. I don't have access to Maple 18 right now to compare.

@DJJerome1976 

Simply using the assumption a+b=d+c is enough to make the eigenvalues c+d and a-c. The integer assumption is not necessary.

First 518 519 520 521 522 523 524 Last Page 520 of 709