I want to include the result of an evaluation in a document block that is included in a workbook. It is easy to write sin(Pi) and obtatin sin(Pi)=0 in your document block. Howwever in the case below I want to preserve only y=x/3  removing the isolate(...) expression. Does anyone know if this can be done and if so how to do it?
 

Thanks for any help.

Download maple_query_document_blocks.mw

Hello,

I want to adjust values in a matrix. In the example matrix you will find some measurement errors (values around -4000 or 1). But these are definitely measurement errors. Is there any possibility to adjust these values to the surrounding values (~1500)...like in an interpolation. Can someone help me how I can do this with maple?

Ps.: the matrix is exported from maple into .xls

Matrix:
O233.xlsx

Thank you very much!

Why is assume(...) do_something();  gives an error when I run the code one more time, but do_something() assuming ...; do not give an error when everything else is the same?

Is there semantic difference between the two forms? I thought they should work the same way. Here is an example

#in separate cell
restart;

#in separate cell
interface(showassumed=0):
pde := diff(u(x, t), t)=k*diff(u(x, t), x$2):
ic:=u(x,0)=0: bc:=u(0,t)=t:
assume(x>0);assume(t>0);assume(k>0):
sol:= pdsolve({pde,ic,bc},u(x,t)):

#in separate cell. Now this gives error
interface(showassumed=0):
pde := diff(u(x, t), t)=k*diff(u(x, t), x$2):
ic:=u(x,0)=0: bc:=u(0,t)=t:
assume(x>0);assume(t>0);assume(k>0):
sol:= pdsolve({pde,ic,bc},u(x,t)):
#error message now

Here is screen shot

Now will do the same, but use assuming. Now there is no error

#in one cell
restart;

#in one cell
interface(showassumed=0):
pde := diff(u(x, t), t)=k*diff(u(x, t), x$2):
ic:=u(x,0)=0: bc:=u(0,t)=t:
sol:= pdsolve({pde,ic,bc},u(x,t)) assuming x>0,t>0,k>0:

#in one cell, no error
interface(showassumed=0):
pde := diff(u(x, t), t)=k*diff(u(x, t), x$2):
ic:=u(x,0)=0: bc:=u(0,t)=t:
sol:= pdsolve({pde,ic,bc},u(x,t)) assuming x>0,t>0,k>0:

Here is screen shot

Why does one give an error, but the second one does not?

I thought they work the same way. Which method is recommended to use?

assume(...); do_something(); 

or 

do_something() assuming ...;

Maple 2018 on windows.

Is it possible to get the following integral involving vectors done in Maple 2018, but handle the singularity when p1=p3?

Note that the output of p3 and p1 are slightly different, probably because the earlier version of the worksheet was in Maple 2017? 

(Note: Earlier version - was due to help received from Dr. Edgardo Cheb-Terrab, using Maple 2017). 

with(Physics[Vectors]);
r_ := _i*x+_j*y+_k*z;
                    r_ := _i x + _j y + _k z
p__1_ := _i*`p__1x `+_j*`p__1y `+_k*`p__1z `;
           p__1_ := _i p__1x  + _j p__1y  + _k p__1z 
p__3_ := _i*`p__3x `+_j*`p__3y `+_k*`p__3z `;
           p__3_ := _i p__3x  + _j p__3y  + _k p__3z 
Expression to integrate wrt p3
'exp(i*(p__1_ . r_))/((p__3_ - p__1_)^2)'
             exp(I Physics:-Vectors:-.(p__1_, r_))
             -------------------------------------
                                                2 
              Physics:-Vectors:-+(p__3_, -p__1_)  
Delaying the evaluation above, if evaluation is allowed, the integrand is
exp(I*(p__1_ . r_))/(p__3_-p__1_)^2;
(exp(I (p__1x  x + p__1y  y + p__1z  z)))/((_i (-p__1x  + p__3x )

   + _j (-p__1y  + p__3y ) + _k (-p__1z  + p__3z ))^2)
T i is the imaginary unit
interface(imaginaryunit = I);
                               I
Because (4), has the value of i before being the imaginary unit, input the integrand again
'exp(i*(p__1_ . r_))/((p__3_ - p__1_)^2)'
             exp(I Physics:-Vectors:-.(p__1_, r_))
             -------------------------------------
                                                2 
              Physics:-Vectors:-+(p__3_, -p__1_)  


Now on the integration
Int(exp(I*(p__1_ . r_))/(p__3_-p__1_)^2, [`p__3x ` = -infinity .. infinity, `p__3y ` = -infinity .. infinity, `p__3y ` = -infinity .. infinity]);
  /infinity   /infinity   /infinity                            
 |           |           |                                     
 |           |           |          (exp(I (p__1x  x + p__1y  y
 |           |           |                                     
/-infinity  /-infinity  / -infinity                            

   + p__1z  z)))/((_i (-p__1x  + p__3x ) + _j (-p__1y  + p__3y )

   + _k (-p__1z  + p__3z ))^2) dp__3x  dp__3y  dp__3y 
value(Int(exp(I*(`p__1x `*x+`p__1y `*y+`p__1z `*z))/(_i*(-`p__1x `+`p__3x `)+_j*(-`p__1y `+`p__3y `)+_k*(-`p__1z `+`p__3z `))^2, [`p__3x ` = -infinity .. infinity, `p__3y ` = -infinity .. infinity, `p__3y ` = -infinity .. infinity]));
                                         /         /[          
 exp(I (p__1x  x + p__1y  y + p__1z  z)) |PIECEWISE|[infinity, 
                                         \         \[          

   Im(_i p__1x  + _j p__1y  + _k p__1z  - _k p__3z )    ]  
   ------------------------------------------------- = 0], 
                          _i                            ]  

                 \\         
   [0, otherwise]|| infinity
                 //         
In the above, there is the product of three Dirac delta functions, that can be represented as a single 3D Dirac delta
combine(exp(I*(`p__1x `*x+`p__1y `*y+`p__1z `*z))*piecewise(Im(_i*`p__1x `+_j*`p__1y `+_k*`p__1z `-_k*`p__3z `)/_i = 0, infinity, 0)*infinity);
                                         /         /[          
 exp(I (p__1x  x + p__1y  y + p__1z  z)) |PIECEWISE|[infinity, 
                                         \         \[          

   Im(_i p__1x  + _j p__1y  + _k p__1z  - _k p__3z )    ]  
   ------------------------------------------------- = 0], 
                          _i                            ]  

                 \\         
   [0, otherwise]|| infinity
                 //         

Hello,

I wonder why trigonometric functions in the Trig Identities context menu in this new release are now suddenly printed italic like cos(x). It's not only inconsistent with the display of functions everywhere else within Maple, also every LaTeX user with very little knowledge of mathematical typesetting rules will frown at the sight of this.

I know it's not a big thing but Maple always stresses to produce pretty-print textbook style output. Powers of trigonometric functions like tan(theta)^2 as shown in the attached screenshot would however be printed like tan^2(theta) in textbooks just as when written by hand.

There are quite some examples where Maple uses significantly strange typesetting like total derivatives dx dy dz in the Physics package that are typeset as partial derivatives. I wonder why Maple introduced a partial-d but not also a total-d operator - doesn't that kind of hurt the eye even if the functionality is beyond critique? That's actually the only case that comes to my mind right now where even Mathematica's typesetting resembles mathematics in textbooks more closely and displays mathematical content more pleasantly than Maple does.

Could some Maple expert help me understand why pdsolve gives me this error message from trying to solve this Schrödinger pde and if there is a work around?

restart;
pde:=I*diff(f(x,t),t)=-diff(f(x,t),x$2)+2*x^2*f(x,t);
bc:=f(-infinity,t)=0,f(infinity,t)=0;
sol:=pdsolve([pde,bc],f(x,t));

I must be doing something wrong, but do not see it.

Mathematica solves the above as follows

pde=I D[f[x,t],t]==-D[f[x,t],{x,2}] + 2 x^2 f[x,t];
bc={f[-Infinity,t]==0,f[Infinity,t]==0};
sol=DSolve[{pde,bc},f[x,t],{x,t}]

thank you

I just installed Maple 2018.   There are long delays when typing imput into a worksheet.  Never had this problem with Maple 2017. I assume that there is some new debugging going on during my input.  But, whatever it is, is there a way to turn it off?

Does any one know of a trick to make Maple solve this PDE using pdsolve?

restart;
pde:=diff(u(x,t),t)+diff(u(x,t),x)=0;
bc:=u(0,t)=0;
ic:=u(x,0)=x;
sol:=pdsolve({pde,ic,bc},u(x,t));

I have tried all HINTS and assumptions and Maple just returns () as solution.

Mathematica solve this as follows

ClearAll[u,x,t];
pde=D[u[x,t],t]+D[u[x,t],x]==0;
bc=u[0,t]==0;
ic=u[x,0]==x;
sol=DSolve[{pde,ic,bc},u[x,t],{x,t}]

Heavidside theta is basically a unit step function.

Maple 2018.

I am surprised Maple pdsolve can't solve this basic heat PDE. it is heat PDE on bar, with left end boundary condition being time dependent is only difference from basic heat PDE's on a bar.

May be a Maple expert can find a work around? I tried all the HINTS I know about.

restart;
#infolevel[pdsolve] := 3:
pde:=diff(u(x,t),t)=diff(u(x,t),x$2);
bc:=u(0,t)=t,u(Pi,t)=0:
ic:=u(x,0)=0:
sol:=pdsolve([pde,bc,ic],u(x,t)) assuming t>0 and x>0;

I also hope this question of mine do not get deleted as well, like the question I posted last night asking why pdsolve ignores assumptions that showed number of examples, was deleted few hrs after I posted it. 

If this question gets deleted, I will get the message that posts showing any problem in Maple software are not welcome here by Maplesoft and I will stop coming here.

This is using Maple 2018.

I noticed when solving Laplace PDE on disk, that no condition is needed to tell Maple if one is asking for solution inside the disk or outside. So how does Maple know which one it is?

It turned out Maple gives the same solution for the PDE outside as inside, which is wrong.

The solution to Laplace PDE inside a disk of radius 1 is

Which Maple gives correctly. But it also give the same above solution for outside the disk. The solution outside the disk should have r^(-n) and not r(n).  Like this

Basically Maple ignores assumption on `r`. This is what I tried

restart;
pde := (diff(r*(diff(u(r, theta), r)), r))/r+(diff(u(r, theta), theta, theta))/r^2 = 0:
bc := u(1, theta) = f(theta), u(r, -Pi) = u(r, Pi), (D[2](u))(r, -Pi) = (D[2](u))(r, Pi):
sol_inside:=pdsolve([pde, bc], u(r, theta), HINT = boundedseries) assuming r<1;

restart;
pde := (diff(r*(diff(u(r, theta), r)), r))/r+(diff(u(r, theta), theta, theta))/r^2 = 0:
bc := u(1, theta) = f(theta), u(r, -Pi) = u(r, Pi), (D[2](u))(r, -Pi) = (D[2](u))(r, Pi):
sol_outside:=pdsolve([pde, bc], u(r, theta)) assuming r>1;

Both the above gives the same answer.

How then does one solve the Laplace PDE outside the disk using Maple? And why is assumptions on "r" seems to be ignored in the above?

(ps. there is no Maple 2018 product to select, so I selected Maple 2017 from the menu).

The new UNTIL keyword added to Maple 2018 seems to me to be confusing and a useless addition to the Maple language.

First of all, using it in a DO loop, one does not use an closing END DO as normal. This makes it harder to use, since one is used to seeing an END DO to close each DO. They align physically better, which makes the code easier to read.

In addition, I can't think of anything that can't be done using current language constructs that needs this new keyword. Can someone? 

Adding a whole new keyword to make one type maybe few less characters seems like  a bad language design. A language constructs should be orthogonal to each others for the language to remain simple and clean. Adding more keywords for the fun of it should be avoided if something can be written using exisiting language constructs.

n := 37:
do
  n := n + 1
until isprime(n);
n;

very confusing to read. It has no end do. At first, I did not see where the loop ends. And the above can be done in many other ways allready, one direct way could be

n := 37:
do
  n := n + 1;
  if isprime(n) then
     break;
  fi;
od;
n;

And it is more clear as well since the DO is aligned with the END DO and I find the logic clearer with no new keyword added. Another way could be

n:= 37:
found_prime := false:
while not found_prime do
   n:= n + 1;
   found_prime := isprime(n);
od:
n;

I am sure there are other ways to do this.

Could someone please show an example where UNTIL is really needed and will make the code much more clear that justifies adding it to the language?

Stupid question maybe, but when will the newest version be released or what will the newest version be label wise? When are the newest versions generally released???