@vv 

•  (x + y(x))*(1+diff(y(x),x)) = 0 has one solution: y(x) = -x + c.

I do not agree.

These are two separate solutions.

If we did have  one general solution and by giving some value to C we get another solution then what you said applies.

But this is not the case here.

The solution y=-x is not obtained from a "general solution". It just happened in this case to be one by setting c=0 in the other solution.

Mathematica also agrees.

We all learned from school that if we have A*B=0 then either A=0 or B=0. So there are two solutions.

@acer 

Thanks for the suggestions but I prefer to have an explicit

           X->operation on X

with map.

i.e. I like to have the argument be explicit. Because sometimes I need to do something on X and it is easier to have it be explicit there. I am just more used to this form. Even if I do not want to do anything with X, seeing it there is more clear to me.

I do not like implicit things. I like everything explicit even if the code is little longer. I had this illness for long time and can't get rid of it.

@C_R 

Thanks for spotting this. This was  a typo. I made last minute change. change var to x in the function but forget to change it everywhere. That is all.

Try the updated worksheet. It should all be "x" now.

Yes, the size change is amazing. I am changing all my code now to use smart_int() instead of int() and so far found very good results. Need to do much more testing.

@vv 

You are correct. But help does not say anything about this and that one needs to change the form when the solution is implicit. All what help says is that it supports both implicit and explcit solutions. That is all.

Also notice that it works without changing the form as long as the IC was not included. It is only when adding the IC the problem shows.

But I changed my code now to check for this and changed the solution to lhs(sol)-rhs(sol)=0 and now they all verify OK.  I think Maple should really not have such limitations in place. After all, it could have itself checked for this and internally made the form change if needed.

Thanks.

@Preben Alsholm 

Ok, this is good. So method=default it should be, Now it agress with what shows for "default" with _RETURNVERBOSE

So we have default and _DEFAULT. But _RETURNVERBOSE shows default and not _DEFAULT

So to really find what int() on its own gives (which is meant to be the default), we have to run the command again with no options to compare or use _DEFAULT option.

After all of this, I still do not know what "default" method is :)

Talk about confusing API.

@Preben Alsholm 

But this is my question. Using int(...,'method'=_DEFAULT) gives the same exact result as int(...) as expected. At least from the few I tried.

But when looking at output of int(i...,'method'=':-_RETURNVERBOSE') now the "default" is not the same as I showed.

Here

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

Why is "default"  result not the same as _DEFAULT?  

 It runs all of the integrators in sequence and returns the first answer found.

Ok. But this still does not explain why what is shown in "default" is not the same as int() on its own or using _DEFAULT method. This is my question. 

@Christian Wolinski 

It is better to have anti-derivative with no explicit complex number in it if the integrand is also free of complex numbers. Such anti-drivatives, even though it is correct is considered of lower quality.

@vv 

opps. I forgot I did.

too many ode's and lose track. 

Feel free to close this question then as duplicate.

@Preben Alsholm 

You are right. I was trying different solution where this assumption is needed and kept this assumption there. Forgot to check if it is still needed or not.

This makes it little more strange that Maple did not find this solution.

Here is the one which needs the assumption I was looking at first

ode:=diff(y(x), x) = sin(y(x)) + 1;
ic:=y(0)=Pi;
SOL:=y(x)=2*arccos(-(x/sqrt(4 + 4*x + 2*x^2)));
odetest(SOL,[ode,ic])  assuming x>-2; #assumption is needed

                 [0, 0]

@minhthien2016 

sorry, I do not understand what you are asking as follow up above. It is better to ask new question if this is not related but you need to add more details. Not clear what is the question here.

@vv 

I see ODESteps as designed for standard simple ODEs

But nothing could be simpler that this ode I gave it :)

@vv 

I see.

I always have Physics updates in the libname path. This is the default as far as I know.

Actually in Maple 2024 there is bug (regardless of syntax used to simplify)

Download eig_maple_2024.mw

Compare to Maple 2023

Download eig_maple_2023.mw

@acer 

Yes this is much simpler. For Pi/2<x and x<Pi only it differentiates back to 1/sqrt(sin(x))

anti:=-sqrt(2)*EllipticF(sqrt(2)*sqrt(sin(x)/(1 + sin(x))), sqrt(2)/2);
simplify(diff(anti,x)) assuming Pi/2<x and x<Pi

But Mathematica's anti seems to be valid for all x according to it:

@Carl Love 

yes, I thought it was strange that solve gives duplicate solutions also, that is why I put it in set. But I did not mention it, as I thought this could happen, even though I have not seen it before myself.

This came about when I was looking at integration of 1/sqrt(sin(x)) trying to see why can't get same solution as Mathematica's which is much simpler but I gave up

int(1/sqrt(sin(x)),x)

Integrate[1/Sqrt[Sin[x]], x]

Doing some checking, I do not think Mathematica's EllipticF and Maples' EllipticF are defined the same way. 

But at the end I  could not find a way to make Maple's solution as simple as Mathematica's.