I should note that the use...end use becomes irrelevant, in this approach, and those two examples work with it removed. What I showed is merely a hackish alternative, given your special situation with mixed strings. Also, you may wish to sometimes use subs instead of eval.

acer

I forget whether everything you wanted equal turned out to be equal. (I hazily recall seeing some result that didn't seem to match your expectation, but I could be mistaken.)

The best course of action would be to upgrade from 12.00 to 12.02, and run it yourself.

Seeing `ee` means nothing, in itself. It's a bug in 12.00. If Maple 12 returns `ee` for simplify(A-B) then no, it isn't safe to conclude that A-B is zero (or the zero Matrix).

acer

I forget whether everything you wanted equal turned out to be equal. (I hazily recall seeing some result that didn't seem to match your expectation, but I could be mistaken.)

The best course of action would be to upgrade from 12.00 to 12.02, and run it yourself.

Seeing `ee` means nothing, in itself. It's a bug in 12.00. If Maple 12 returns `ee` for simplify(A-B) then no, it isn't safe to conclude that A-B is zero (or the zero Matrix).

acer

You are making use of PDEtools notational shortcuts for derivatives, via that package loading.

The result from VectorCalculus:-Jacobian contains derivatives which merely display like f[x,x], etc. But the underlying object contains derivatives and not indexed name f[x,x]. So attempting to subs for the indexed name f[x,x] accomplishes nothing.

For example,

> restart:
> with(PDEtools): declare(prime):
         The prime differentiation variable has not been declared yet
 
> Q := diff(diff(f(x),x),x);
                                 Q := f[x, x]
 
> subs(f[x,x]=17,Q);
                                    f[x, x]
 
> subs(f[x,x]=17,f[x,x]);
                                      17
 
> lprint(Q);
diff(diff(f(x),x),x)

> subs(diff(diff(f(x),x),x)=17,Q);
                                      17

By the way, VectorCalculus produces Matrices, not matrices. Matrices do not have last_name_eval and do not require eval() or evalm() as matrices do.

acer

You are making use of PDEtools notational shortcuts for derivatives, via that package loading.

The result from VectorCalculus:-Jacobian contains derivatives which merely display like f[x,x], etc. But the underlying object contains derivatives and not indexed name f[x,x]. So attempting to subs for the indexed name f[x,x] accomplishes nothing.

For example,

> restart:
> with(PDEtools): declare(prime):
         The prime differentiation variable has not been declared yet
 
> Q := diff(diff(f(x),x),x);
                                 Q := f[x, x]
 
> subs(f[x,x]=17,Q);
                                    f[x, x]
 
> subs(f[x,x]=17,f[x,x]);
                                      17
 
> lprint(Q);
diff(diff(f(x),x),x)

> subs(diff(diff(f(x),x),x)=17,Q);
                                      17

By the way, VectorCalculus produces Matrices, not matrices. Matrices do not have last_name_eval and do not require eval() or evalm() as matrices do.

acer

> d := a*b+5/(3*h);
                                            5
                                d := a b + ---
                                           3 h
                                                                                
> a,b,h := 1,1,1;
                              a, b, h := 1, 1, 1
                                                                                
> d;
                                      8/3
                                                                                
> eval(d,1);
                                          5
                                   a b + ---
                                         3 h

> restart:

> d := a*b+5/(3*h);
                                            5
                                d := a b + ---
                                           3 h
 
> eval(d,[a=1,b=1,h=1]);
                                      8/3
 
> d;
                                          5
                                   a b + ---
                                         3 h

acer

> d := a*b+5/(3*h);
                                            5
                                d := a b + ---
                                           3 h
                                                                                
> a,b,h := 1,1,1;
                              a, b, h := 1, 1, 1
                                                                                
> d;
                                      8/3
                                                                                
> eval(d,1);
                                          5
                                   a b + ---
                                         3 h

> restart:

> d := a*b+5/(3*h);
                                            5
                                d := a b + ---
                                           3 h
 
> eval(d,[a=1,b=1,h=1]);
                                      8/3
 
> d;
                                          5
                                   a b + ---
                                         3 h

acer

For both this followup and the original post I see lowercase pi instead of Pi in the Properties metadata. Maple knows about Pi, but pi is just another (valueless) name.

What you do plan on doing, eventually, with the symbolic result of integration? Further algebraic manipulation, or numerical evaluation at delta&mu, or plotting, or..?

acer

For both this followup and the original post I see lowercase pi instead of Pi in the Properties metadata. Maple knows about Pi, but pi is just another (valueless) name.

What you do plan on doing, eventually, with the symbolic result of integration? Further algebraic manipulation, or numerical evaluation at delta&mu, or plotting, or..?

acer

cf. is an abbreviation for the Latin word confer, meaning compare.

You may already have figured out that you can accomplish the assignments using seq and assign. The result (NULL) gets ignored, as the assignments get done as side-effects. It's slick, but not especially good.

> x[1], x[2], x[3] := 1, 2, 3:

> seq( assign(a[i],x[i]), i=1..3 );

> a[1], a[2], a[3];
                                    1, 2, 3

acer

cf. is an abbreviation for the Latin word confer, meaning compare.

You may already have figured out that you can accomplish the assignments using seq and assign. The result (NULL) gets ignored, as the assignments get done as side-effects. It's slick, but not especially good.

> x[1], x[2], x[3] := 1, 2, 3:

> seq( assign(a[i],x[i]), i=1..3 );

> a[1], a[2], a[3];
                                    1, 2, 3

acer

I believe that the posted example actually did multiple sequential (rather than simultaneous) substitution.

This is simultaneous substitution,

> subs( {a=b, b=c}, [a,b] );
                                    [b, c]

And this is sequential substitution,

> subs( a=b, b=c, [a,b] );
                                    [c, c]

In your particular example, it might not have mattered. But the distinction can be useful.

acer

I believe that the posted example actually did multiple sequential (rather than simultaneous) substitution.

This is simultaneous substitution,

> subs( {a=b, b=c}, [a,b] );
                                    [b, c]

And this is sequential substitution,

> subs( a=b, b=c, [a,b] );
                                    [c, c]

In your particular example, it might not have mattered. But the distinction can be useful.

acer

The solve routine does not generally handle assumptions, in the sense that int does. It does however quite often call is internally, and so solve+assumptions sometimes has partial (and sometimes weird) effects.

What is more likely "supposed" to work is augmenting the assumptions as extra conditions. For example,

> solve({...., a>0}, ...);

Of course, it is still possible that it does not work, due to bugs/incompleteness/etc. The inequality solving capabilities seem to have been improving a little in recent releses, but are still not strong.

acer

The solve routine does not generally handle assumptions, in the sense that int does. It does however quite often call is internally, and so solve+assumptions sometimes has partial (and sometimes weird) effects.

What is more likely "supposed" to work is augmenting the assumptions as extra conditions. For example,

> solve({...., a>0}, ...);

Of course, it is still possible that it does not work, due to bugs/incompleteness/etc. The inequality solving capabilities seem to have been improving a little in recent releses, but are still not strong.

acer