@ecterrab 

Thanks for the quick fix. I confirm it is fixed in Latest Physics update. It it great job you are doing by giving fixes so quickly in these updates instead of one having to wait a year or so for a new version of Maple to get the fix.

I have found few more problems  elsewhere in Maple 2021.1 in the last 2-3 months, but I send these to technical support in emails already so I did not post them here.

The only main problem that remains for me with using Maple, is that timeout does not always timeout anywhere near the timeout value given all the time. I still see cases where it hangs or takes much much longer than the timeout value.

But I talked about this many times before so will not bring up anymore. I have many examples showing this. I'll wait for Maple 2022 to see if this problem is hopefully finally resolved.

Thanks again for your support.

@Preben Alsholm 

I think you did not get the errors when you simplified the integrand, is because of the call to simplify() being made before int(). This causes something to be loaded and changes memory layout?

To show this, I used the simplified version of the integrand (copied from different worksheet so I do not have to call simplify()) and repeated things, and now it fails.

Now repeated the same thing, but used simplify()  like you did, and the error went away.

This tells me that it has nothing to do with the simpler version of the integrand. It is due to the call to simplify() before which caused something to be loaded which had the side effect of removing the error.

To proof this more. I kept the original integrand, but loaded something else. Calendar package. And now i am not able to reproduce the error no matter how many times I tried.

Removing the call to Calender. Closing Maple. Starting again, and now tried it, and got the error back: of course Calender package has nothing to do with int() command. but this shows that it seems to be a memory layout or something related as loading something before, even if not related causes different behavior. These were all done after starting Maple again each time with nothing else running in Maple.

issue_int_nov_11_2021_simplified_version.mw

Download issue_int_nov_11_2021_simplified_version_2.mw

issue_int_nov_11_2021_with_calender.mw

issue_int_nov_11_2021_no_calender.mw

@itsme 

I do not have any custom stuff in my ~maple folder. Never used it actually. I am on windows.  I do not have anything special installed for Maple. I use the original Maple installation but do install the Physics package as extra using the command Physics:-Version(latest).  I have updated Physics just 2 days ago also. I do not think this is related to Physics as I have not even used it or loaded it in this example.  This is single user PC sitting on my kitchen table. Nothing fancy going on here. No network installation, etc.. 

It just seems it depends on how memory is allocated in Maple at the time, and it seems random.   

@itsme 

"But I completely disagree with you that an option to do this should not be available"

I did not agree with the design that Maple latex generator should try to do automatic line wrapping to help the end user. I think it is the wrong place to do so. But I never said it should not be available. I said at the end this 

"May be a new setting called     donotaddlinebreak which will override linebreak and linelength settings?"

So users can have a choice. That is all. For those who want automatic newlines added, they can choose so. But for those who do not, can choose so.

Playing with values for linelength setting is not the correct way to do this, even though setting linelength to 10^6 would prevent automatic linewrapping in most practical cases.

The issue of long math display in Latex have been around for decades and there are many solutions for this in Latex itself using packages and other math environments. If you look at tex site at stackexchange for example you will see many examples and solutions.  

@ecterrab 

For me, the latex generator software should just generate correct Latex and not try to guess things related to what the final paper width could be and add line breaks to "help" the user. I do not think that is the right place to do this. 

It should leave the Latex as is, no matter how long it is, and let the the actual Latex compilation phase worry about these issues. Trying to guess what the page width will be and trying to help by adding lines breaks in the middle can make things worst and might not be what the end user wanted.

There are many ways to handle these in the Latex compiling stage that the user can choose to do. Such as using breqn package, or  the user might be using landscape mode, or by using the geometry package, or by using the gather environment which shrinks math to page width, and so on.

My point is, the Latex generator should not try to anticipate what the physical paper width is and try to help the user by doing automatic line breaks. In the example I showed, it lead to an output which does not look good and not what is expected and is different from what shows on the screen. I remember you once said that the Latex generated sould match what shows on the screen (worksheet Maple output). In this case, it does not.

but for now, I set linelength=100000 in the settings. I did try breaklines=false which the help shows as possible option, but I got an error saying

Error, (in latex:-Settings) wrong left-hand-side in breaklines = false

Even though help says the default is false. I wanted to be sure.

May be I am doing something wrong. If one can turn off this breaking lines feature, regardless of the linelength setting, then that will be even better, so that the user could have a choice to use it or not. and not worry about the linelengtn setting.

May be a new setting called     donotaddlinebreak which will override linebreak and linelength settings?

But for now linelength=100000 seems to have done the trick. Hopefull, I will not have a latex expression generated longer than this.

regards

@ecterrab 

I found a case where PDEtools:-Solve can't solve for the unknowns in the equation. May be I am not understanding  some of the functionality. It works on some equations but not on others, when I was testing it. Here is an example where it can not solve it

restart;
eq:=-4*c1*sin(2*x)+4*c2*cos(2*x)+2*c3*cos(2*x)-8*c3*x*sin(2*x)+2*c4*sin(2*x)+8*c4*x*cos(2*x) = 3*x*cos(2*x);
the_constants:={c1, c2, c3, c4};
PDEtools:-Solve(eq,the_constants,independentof = x);

Here it seems to hang. Waited for more than one hr. While

restart;
eq:=-4*c1*sin(2*x)+4*c2*cos(2*x)+2*c3*cos(2*x)-8*c3*x*sin(2*x)+2*c4*sin(2*x)+8*c4*x*cos(2*x) = 3*x*cos(2*x);
sol := solve(identity(eq,x),{c1,c2,c3,c4});

Gives the answer immeadiatly

Also Solving this by "hand", by comparing terms gives

restart;
eq1:=-4*c1+2*c4=0;
eq2:=4*c2+2*c3=0;
eq3:=-8*c3=0;
eq4:=8*c4=3;
the_constants:={c1, c2, c3, c4};
PDEtools:-Solve([eq1,eq2,eq3,eq4],the_constants);

Here is an example where it works:

restart;
eq:=-3*c1*exp(-x)+cos(x)*(-3*c2-c3)+sin(x)*(-3*c3+c2)=exp(-x)+2*cos(x);
PDEtools:-Solve(eq,{c1,c2,c3},independentof=x)

Which agrees with the "manual" solution

restart;
eq1:=-3*c1=1;
eq2:=-3*c2-c3=2;
eq3:=-3*c3+c2=0;
PDEtools:-Solve([eq1,eq2,eq3],{c1, c2, c3});

Why did the first example above not solve it?

@Preben Alsholm 

        "This works:"

I am afraid it does not work.

expr:=x^2*A[2]+A[1];
select(type,expr,identical(x^2) &* anything);

gives 0

Maple 2021.1

@Joe Riel 

             "Try changing anything to indexed"

this does not really help. First, it has to work for any expression. I do not know what is being multiplied by x^2. This was just an example.

restart;
expr:=3*x+sin(x);
select(type,expr,'`*`'({anything, identical(x^2)}));

gives 3*x also. I needed something similar to pattern matching

patmatch(3*x^2,a::anything*x^2,'la');la

works

 but

patmatch(3*x,a::anything*x^2,'la');la

does not as expected.     But need to do it using structured types, just to learn it better as it is "supposed" to be the better way to do this, but I find it much confusing than using simple patterns.

@Rouben Rostamian  

You don't want u(0,theta)=0.  You want u(0,theta) to be finite. 

Yes, I knew that, but I did not know how to tell Maple that u(0,theta) is "finite". So I used zero to see what solution it gives.

When solving by hand, we can do that, but I do not think it is possible to tell the computer this. At least  I do not know how to.

@dharr 

Yes.

And if I tell it u=0 at r=0, then one of the BC is not satisfied

restart;
interface(version);
the_rhs := r^2*cos(theta)*sin(theta):
pde := VectorCalculus:-Laplacian(u(r,theta),'polar'[r,theta])=the_rhs:
bc := u(1, theta) = cos(theta)*sin(theta),u(0,theta)=0;
sol:=pdsolve([pde, bc], u(r, theta),HINT=f(r)*sin(2*theta));

pdetest(sol,[pde,bc])

As the solution blows at r=0

@dharr 

I tried your other hint, and it gives this solution

restart;
interface(version);
the_rhs := r^2*cos(theta)*sin(theta):
pde := VectorCalculus:-Laplacian(u(r,theta),'polar'[r,theta])=the_rhs:
bc := u(1, theta) = cos(theta)*sin(theta):
sol:=pdsolve([pde, bc], u(r, theta), HINT=f(r)*sin(2*theta));

In plain text

sol := u(r, theta) = ((r^6 + 24*_C2*r^4 - 24*_C2 + 11)*sin(2*theta))/(24*r^2)

which seems closer to the correct one, but not exactly the same. Notice it has also one unknown _C2

and using 

sol:=pdsolve([pde, bc], u(r, theta), HINT=f(r)*g(theta));

gives

sol := u(r, theta) = sin(2*theta)*(-576*_C2*_C3^4*r^4 + 24*_C3^3*r^6 + 264*_C3^3*r^4 + _C3*r^6 + 576*_C2*_C3^4 + _C2*r^4 - _C2 + 11*_C3)/(576*_C3^3*r^2 + 24*_C3*r^2)

@dharr 

thanks., but in Maple 2021 HINT=`*` returns the same solution as without this hint.

restart;
interface(version);
the_rhs := r^2*cos(theta)*sin(theta):
pde := VectorCalculus:-Laplacian(u(r,theta),'polar'[r,theta])=the_rhs:
bc := u(1, theta) = cos(theta)*sin(theta):
sol:=pdsolve([pde, bc], u(r, theta), HINT=`*`);

@Rouben Rostamian  

Thanks. Yes, this can be solved by hand analytically (I did not do that), but got the solution from Mathematica, which is the same as the one you showed. That is why I was surprised that Maple gives, what looks like wrong solution here.

ClearAll[x,y,u,r,theta]
rhs=r^2 Cos[theta]*Sin[theta];
pde=Laplacian[u[r,theta],{r,theta},"Polar"]==rhs;
bc=u[1,theta]==Cos[theta]*Sin[theta];
soldsolve=u[r,theta]/. First@DSolve[{pde,bc},u[r,theta],{r,theta}]
Simplify[soldsolve]

Here is a plot of the solution

It is possible Maple can solve it analytically and give the correct solution using some Hints or other options I do not know about.,

@acer 

I was testing the last one, but it does not work?

restart;
expr:=exp(sin(x));
thaw(expand(subsindets(expr,specfunc({sin,cos,exp}),freeze)))

it gives

But the method with try/catch worked.

@acer 

Yes, this helped reduce verbosity in this example, but still due to not able to use "zero or more" method in general with structured type, I find I still need to duplicate things.

Let me give a much simpler example than the above. 

Suppose we want to match  anything*sin(anything)  by making a structured type for this expression.

Since I can't use zero or more, I find I have to duplicate the type using Or or {}.

One time for anything*sin(anything) when anything is not 1, and one for sin(anything) for the case when factor is default 1. Here is an example

TypeTools:-AddType('my_type', {  '`*`'({rational,specfunc(sin)}),   specfunc(sin)   } );
type(2*sin(x),my_type);
type(sin(x),my_type);

The above structured type now matches both cases. Because the first part looks for `*` type and the second one looks for sin(x) on its own. So I had to make separate type for when the leading factor is default 1. Same thing for powers if present like in the example I posted in original post.

I know ofcourse that 2*sin(x) has type `*`  and sin(x) is not type `*` that is why it does not work. Which is completely understandble from point of view of a strong type system. But for finding subexpressions, it means one have to make many types to capture each possible case, while with pattern matching (which does not use structured types), one can, using only one pattern, match a much larger class of subexpressions.

In Mathematica, using the zero or more method for pattern:

type = n_.*Sin[_];
MatchQ[Sin[x], type]
MatchQ[2*Sin[x], type]

And both above gives True match since first one, n_. says zero or more. No need to duplicate things.

I can do the same thing above using Maple's patmatch easily as follows

my_pattern:='n::anything*sin(b::anything)';
patmatch(2*sin(x),my_pattern,'la'); la;
patmatch(sin(x),my_pattern,'la'); la;

But I can't do similar thing with structured type. That is why I think patterns are more flexible for finding subexpressions and for expressions transformation, but everyone here says to avoid patmatch in Maple and use structured types.