These  are good example(s)  why I think Maple's simplify needs to be improved. 

Example 1

Given an expression which is zero for nonnegative x, one would expect simplify to simplify it to zero when told that x is positive. 

But nothing I tried with simplify worked. combine  figured it out.

But why? Is this not the job of simplify? 

The expression is 

e:=x-1/4*(-2+2*(4*x^2+1)^(1/2))^(1/2)*(2+2*(4*x^2+1)^(1/2))^(1/2);

Here is worksheet

Compare some other software on this same problem

It should be as simple as the above in Maple.

A user should not have to try 100 different commands in Maple to find which works.

simplify should have done it in first place. What Am I overlooking here?

Maple 2024

Download why_simplify_do_not_work_example.mw

EXAMPLE 2

In this example the expression is zero for x<0. Here nothing worked for me. This is challenge for Maple experts here to find the command to simplify this to zero. 

I know it is zero for x<0.

e := -1/2*(-2*x*sqrt(4*x^2 + 1) + (16*x^3*sinh(3/2*arcsinh(2*x)) - 8*x^2*cosh(3/2*arcsinh(2*x))*sqrt(4*x^2 + 1) + 4*sinh(3/2*arcsinh(2*x))*x - cosh(3/2*arcsinh(2*x))*sqrt(4*x^2 + 1))*sqrt(-2 + 2*sqrt(4*x^2 + 1)))/sqrt(4*x^2 + 1)

Using some other software gives

I'd like to find command to do the same in Maple. i.e. simplify it to zero. What else to try?

Download why_simplify_do_not_work_example_2.mw

I think I found another problem with odetest.  When solution is implicit, it fails to verify the solution against the ode when adding the IC. (not everytime, but in some cases).

But it does verify the solution against the ode when IC is not given. I give 3 examples.  Also at bottom is worksheet of all of this.

Example 1

restart;

ode:=diff(y(x), x) = sin(y(x));
ic:=y(0)=Pi/2;
mysol:=ln(tan(y(x)/2))=x;

It says solution satisfies the ode itself OK

odetest(mysol,ode);

gives 0

But adding IC now gives

odetest(mysol,[ode,ic]);

Which I am having hard time reading. Is it now saying the solution does not satisfy the ode or the IC? Both are supposed to be zero.

Are these not supposed to be in same order given? so it looks like if we go left to right, it is saying the solution do not satisfy the ode now but it does satisfy the IC. Right?

But before it said the solution satisfies the ode.

Also, we can see the IC is satisfied. Let do it by hand

eval(mysol,[y(x)=Pi/2,x=0])

              0 = 0

So why does it say solution satisfies the ode first, then when adding the IC, now it changed its mind?

Also, solving for y(x) from the implicit solution, now it verifies it OK  with the IC also:

ode:=diff(y(x), x) = sin(y(x));
ic:=y(0)=Pi/2;
mysol:=ln(tan(y(x)/2))=x;
mysol_explicit:=solve(mysol,y(x));
odetest(y(x)=mysol_explicit,[ode,ic])

          [0, 0]

You see. Same solution. But different result from odetest depending if it is implicit or explicit.

Is this supposed to happen or is this a bug in odetest I should report? odetest is supposed to handle both explicit and implicit solutions. I know my solutions are correct. I just use odetest for verification. I also plotted my solution against maple's solutions and they are exact match. 

Example 2

ode:=diff(y(x),x)=1+y(x)^2;
mysol:=arctan(y(x))=x;
ic:=y(0)=0;
odetest(mysol,ode);
odetest(mysol,[ode,ic]);

Gives 0 for the first call to odetest but gives [diff(y(x), x) - 1 - y(x)^2, 0] for the second call.

Changing the solution to explicit. now it verifies it

mysol_explicit:=solve(mysol,y(x));
odetest(y(x)=mysol_explicit,[ode,ic]);

Now it gives [0,0]

Example 3

ode:=diff(y(x), x) - 2*y(x) = 2*sqrt(y(x));
ic:=y(0)=1;
mysol:=ln(sqrt(y(x))+1)=x+ln(2);
odetest(mysol,ode);
odetest(mysol,[ode,ic]) assuming positive;

Gives 0 for the first call but  [diff(y(x), x) - 2*y(x) - 2*sqrt(y(x)), 0] but when using explicit it now verifies OK

mysol_explicit:=solve(mysol,y(x));
odetest(y(x)=mysol_explicit,[ode,ic]) assuming positive;

           [0, 0]

Maple 2024 on windows 10

Download odetest_implicit_problem_june_2_2024.mw

Simple question. I hope it has simple answer. I have always thought that what int() returns should match exactly what "default" result shows when using int() with the option _RETURNVERBOSE 

I mean exact match. But this below shows that int() result underwent some simplification as it is not the same as default.

restart;

integrand:=sin(x)/(sin(x) + 1);
maple_result_1 :=int(integrand,x);
maple_result_2 := int(integrand,x,'method'=':-_RETURNVERBOSE')[1]

Ofcourse maple_result_2 can be made the same as maple_result_1

simplify(rhs(maple_result_2)) assuming 0<x and x<Pi;

But this is beside the point. Why is "default" is not excatly the same as int() result?  It seems that int() does something more after obtaining the :"default" result as shown.

Should default not match exactly result from int() ?

Maple 2024.

Maple int gives one result, called the "default" result unless one uses method=_RETURNVERBOSE to look for other results.

First, how does Maple decide what is "default" i.e. given all the methods listed, what method then used for "default".

Here is an example where default result makes it hard to solve for a differential equation. The integrand is 

1/(y+sqrt(y))

Maple int default gives anti as ln(y - 1) + 2*arctanh(sqrt(y))  which is complex valued for all y. The arctanh is only defined for argument between -1 and 1 also. Having sqrt there makes it now valid for 0 to 1. But ln(y-1) is negative in this region also. Hence complex. 

Using method=_RETURNVERBOSE we see much better anti derivatives hidding there and given by "derivativedivides" and "meijerg" as 2*ln(1 + sqrt(y)) which is complex valued only for negative y and real for all positive y. Same for "trager"  ln(2*sqrt(y) + 1 + y)

So it would have been much better if Maple picks the best anti-derivative automatically and use that for default instead and give this to the user.

Why is this important? Try to solve   the ode y'/(y+sqrt(y))=2 with IC y(0)=1 and you see we can't solve for the constant of integration using  ln(y - 1) + 2*arctanh(sqrt(y))=2x+c since at y=1 we get division by zero. If Maple had returned 2*ln(1 + sqrt(y)) instead then solving for constant of integration is trivial now since anti is real and defined at y=1

This is just one example of many.

My question is, How does Maple integrate decide what is "default" and why it does not try harder to pick better one (using number of known metrices for this sort of thing) from the other solvers it already has access to?  

What is the point of having all these other nice integrate methods, if the default used is not the "best" one?

Should user then always use method=_RETURNVERBOSE and then try to pick the "best" one themselves? This will be too much work for user to do.

I think Maple should do this automatically. Btw, I tried few other CAS integrators and the all give the better result given above by "meijerg" automatically.

Maple 2024

Update

Here is a quick function, called it smart_int() which returns the anti-derivative with the smallest leaf size from Maple.

Ofcourse smallest leaf size does not mean the anti-derivative is necessarily the "best" using other measures. But this function already allowed me to solve some ode's I could not solve before using Maple's defaullt int result because it made solving for constant of integration easier now.

Feel free to improve and change. If you find any bugs please let me know

The test here shows the result of smart_int compared to int on few integrals. You see on many of them smart_int gives smaller result. Additional criteria for selection can ofcourse be added and I will probably do that.

For example, do not pick ones with complex numbers if there is one without even though leaf size is smaller. This check has been added also.

Check the last integral in this test. The difference is so large. 

Download smart_int.mw

Any workaround or why ODESteps gives this internal Maple error?  Is this known limitation of ODESteps?

ps. reported also to Maplesoft just in case.

Download bug_in_odesteps_divide_by_zero_may_31_2024.mw