Preben Alsholm

MaplePrimes Activity


These are replies submitted by Preben Alsholm

@baustamm1 Yes I meant building blocks in that sense.

Whar are the intial and boundary conditions here in this case?

@Carl Love Your original version works in Maple 2015.1 with 1-D math input.

@baustamm1

The output from pdsolve on your system sys1 is not to be considered the general solution, but rather as building blocks for any solution as when using separation of variables.

You could try doing
infolevel[pdsolve]:=3;
before executing the pdsolve command.

@Axel Vogt No I don't think so.
Try setting
infolevel[dsolve]:=3:
Then when executing the dsolve statement you will see the procedure for evaluating YP[1] is
proc (N, X, Y, YP) option `[Y[1] = f(x)]`; YP[1] := ff(X); 0 end proc;
Thus ff(X) remains unevaluated. Thus no problem.
The problem appear right away when defining the ode if you didn't have the return unevaluated part, as in
ff1:= x -> evalf(Int(exp(t), t= 0 .. x, method = _d01ajc));
ode1:=D(f)(x)=ff1(x);
You will notice the disappearance of option and evalf before we even get to the task of solving.



@Mac Dude You should be able to use Physics:-Assume without loading the package. Just use the long name Physics:-Assume.
Example:
restart;
Physics:-Assume(a>0);
sqrt(a^2);
about(a);
Physics:-Assume(a=a);
about(a);


@Kitonum If the order is important then notice that your solution doesn't preserve the order, even in the example given.
Here is another example:

restart;
u:=[x,z,y]; v:=[b,a,x];
[op({op(u), op(v)})];
ListTools[MakeUnique]([u[],v[]]);

OK, you say that if you want the result sorted then etc., but sorted according to which criterion? In recent versions we get lexicograhic ordering when using sets, thus 'a' preceeds 'b' etc.

@acer I just submitted an SCR with title "Bug in indets".

Maybe superfluous to mention, but you have to remember to set Typesetting to Extended in the options menu.

The problem is the same for int and Int. The remedy by acer still works.

restart;
w:=[int(f(x),x),Int(f(x),x)];
indets(w,specfunc(int));
indets(w,specfunc(Int));
convert(w,Int);
convert(w,int);
value(w);
indets(w,specfunc(int) &under (convert,int)); #Empty
indets(w,specfunc(int) &under value);#Empty
indets(w,specfunc(Int) &under (convert,Int));#Empty
## acer's remedy of converting global as the last action:
indets(w,specfunc(int) &under (convert,compose,int,`global`));
indets(w,specfunc(int) &under (rcurry(convert,`global`)@value));
indets(w,specfunc(Int) &under (convert,compose,Int,`global`));
## The converting global is essential:
indets(w,specfunc(XX) &under (curry(subs,int=XX)@value));
indets(w,specfunc(XX) &under (rcurry(convert,`global`)@curry(subs,int=XX)@value));
###########################################################
The problem is indeed rather confusing. Yet another example, this time with f and %f (and in parallel f(x) and %f(x)):
restart;
w:=[f,%f];
w(x);
value(%f);
indets(w,identical(f));
indets(w,identical(%f));
value(w);
indets(w,identical(f) &under value);#Empty
indets(w(x),specfunc(f) &under value);#Empty
indets(w,identical(%f) &under curry(subs,f=%f)); #OK
indets(w(x),specfunc(%f) &under curry(subs,f=%f)); #OK
indets(w,identical(f) &under (rcurry(convert,`global`)@value)); #Surprise!
indets(w(x),specfunc(f) &under (rcurry(convert,`global`)@value)); #OK!
indets(w,identical(%f) &under (rcurry(convert,`global`)@curry(subs,f=%f))); #Surprise!
indets(w(x),specfunc(%f) &under (rcurry(convert,`global`)@curry(subs,f=%f))); #OK!





I think this example is simpler and seems to get rather unexpected results from indets: The ones labelled 'Surprise'.
My understanding is that in those 'Surprise' cases indets ought to return {diff(u(x),x),D(u)(x),Diff(u(x),x)}, i.e. all three types of derivatives. But it doesn't.

restart;
expr:=diff(u(x),x)+D(u)(x)+Diff(u(x),x);
convert(expr,diff); #OK
convert(expr,D); #OK
convert(expr,Diff); #OK
indets(expr,specfunc(D(u))); #OK
indets(expr,specfunc(diff)); #OK
indets(expr,specfunc(Diff)); #OK
indets(expr, specfunc(D(u)) &under (convert, D)); # Surprise
indets(expr, specfunc(diff) &under (convert, diff)); # Surprise
indets(expr, specfunc(Diff) &under (convert, Diff)); #Surprise
type(diff(u(x),x),specfunc(D(u)) &under (convert,D)); #OK
hastype(expr,specfunc(diff) &under (convert,D)); #OK
#######acer's remedy given in his answer below works fine:
indets(expr, specfunc(D(u)) &under (convert, compose, D, `global`)); #OK
indets(expr, specfunc(diff) &under (convert, compose, diff, `global`)); # OK
indets(expr, specfunc(Diff) &under (convert, compose, Diff, `global`)); # OK
############
The example I first looked at may still be interesting:

expr2:=diff(u(x),x)+D(u)(x);
indets(expr2, specfunc(D(u)) &under (convert, D)); # Surprise: The empty set
indets(expr2, specfunc(diff) &under (convert, diff)); # Surprise
indets(expr2, specfunc(Diff) &under (convert, Diff)); #OK




Isn't the problem that when temporarily converting diff(u(x,t),x,t) to D (the &under-part) the expression becomes convert(expr), thus the two versions of the mixed second derivative of u are treated as the same and represented as 2*D[1, 2](u)(x, t).
If that is actually the case then the retreat from the temporary conversion is impossible, it would result in just one of the versions, in this case the diff-version.

Since the fact that the same unexpected results come up in my examples below if the expressions expr and expr2 are changed to lists as in
expr:=[diff(u(x),x),D(u)(x),Diff(u(x),x)];
my explanation above doesn't tell the whole story.

@Al86 My first version of "Another approach" was flawed: Using U:= x->1+add(c[i]*x^i,i=1..n) means that U(0) = 1. However, x = 0 corresponds to t = infinity.
I have replaced the flawed version with another. The new one doesn't make any change of variable.
I have tried yet another appoach using y(t) = 1+h*y1(t)+h^2*y2(t)+...
Inserting this into the integral equation and equating powers of h gives y1(t), y2(t), etc.
Using just y(t)=1+h*y1(t) gives results that are quite similar to the collocation approach above.
That is encouraging.

It may be worth pointing out that now (at least from Maple 18 and on) dsolve can solve systems given on matrix form.
Simple examples.
restart;
M:=Matrix([[1,1,0],[0,1,3],[0,0,2]]);
b:=<7,9,13>;
X:=<seq(x[i](t),i=1..3)>;
sys:=diff~(X,t)=M.X+b;
dsolve(sys); #General solution
dsolve({sys,x[1](0)=0,x[2](0)=3,x[3](0)=0}); #Initial values given
dsolve({sys,eval(X,t=0)=<0,3,0>}); #An alternative formulation of the ivp
##### B a matrix:
B:=<b|<1,2,3>|<-1,8,-9>>;
X:=Matrix(3,(i,j)->x[i,j](t));
sys:=diff~(X,t)=M.X+B;
dsolve(sys);
dsolve({sys,eval(X,t=0)=<<0,3,0>|<4,-5,7>|<0,0,0>>});
## A final note: You can get the output on vector or matrix form in all the cases above by doing the following right after the dsolve command:
X=subs(%,X);

@Axel Vogt Why is the given integral equation not
y(t) = 1-h*Int(JacobiTheta3(0,exp(-Pi^2*s))*y(t-s)^4,s = 0 .. t) ?
That seems to me to be implied by his recursion.
The discussion in the previous question posed by Al86 left me somewhat confused, so maybe I'm missing something.


@tomleslie I apologize for editing my comment many times within about one hour yesterday.
If you read the comment as it ended up yesterday after my last edit, I think the reason for the weird behavior is the following:
When using U(x):=uuu; #Where uuu is some expression, e.g. x/(1+s^2).
the entry U(x)=uuu is written in the memory table of U.
When using
inttrans:-invlaplace(U(x),s,t) assuming x>0;
the first that happens (before evaluation of U(x)) is that x is replaced by another (local) name (think of it as x~).
After that evaluation of U(x~) takes place. First the memory table is searched, the index x~ is not found. Thus since no (general) definition of U has been done, U(x~) is just itself, i.e. evaluates to U(x~).
After that invlaplace gets to work resulting in U(x~)*Dirac(t).
Just before exiting `assuming` the local name x~ is replaced by the global x resulting in the output U(x)*Dirac(t).
Notice that if you evaluate that by doing just
%;
you get uuu*Diract(t).
###
So is this a bug? In my view it is not. It is due to the deliberate design of `assuming`.
As I also pointed out (and you mention) the mess could easily have been avoided by using U or Ux (or whatever name) instead of U(x).

First 111 112 113 114 115 116 117 Last Page 113 of 231