@C_R 

Did you run the updated worksheet with 6 trials? DO you get similar timings on them or some are slow and some fast as I show?

Which version are you using? 

THe integral is not solvalble. int() returns right away as expected. This is just made up one for testing.

@C_R 

Oh, I see what you meant. Will this do what you want in this case?

((x->x)=combine[trig])(expr);

For the third line. What is it supposed to do?  Did you mean

map(x->x=combine[trig](x),[trig])

I do not understand what  your

(x->x=combine[trig])(expr);

is supposed to do actually.

@C_R 

Well, I thought you just wanted the fraction*ln changed. That was your example. 

For general cases, you could try this and see. 
 

Download make_nice.mw

@acer 

Thanks. I did not relaize it is same underlining issue. I ended up writing my own function to verify the IC only using limits and it is working so far where odetest fail such as this example.

I only now use odetest to verify the solution, but not the initial conditions due to this problem in odetest.

@Preben Alsholm 

Yes, this is what I mean,.

If you look at my solution for second example, when using "solve" it is the same as what "dsolve" gave. So internally "dsolve" must have used "solve" in this example. The solution verifies in this case.

But when using "Solve", and everything else is same, now odetest do not verify the solution any more. Due to how the RootOf comes out.

So yes, it is not always better to use "Solve". Sometimes "solve" is better and sometimes "Solve" is better. Better in the sense that solution that results can be validated by odetest. It all depends on how the RooOf is written as you can see.

Both solve and Solve solutions are correct. But sometimes one form is more friendly to odetest than the other.

@Preben Alsholm 

fyi, I added a counter example, where now using solve makes odetest verify the solution but using Solve does not.

@aroche 

Thanks for the quick fix. Verified OK in latest Physics.

@vv 

"With your statement,  (x + y(x))^7 * (1+diff(y(x),x)) = 0  has 8 solutions."

No. Only 2. Because  A^7=0 then that is the same as  A=0.

Maple agrees

dsolve( (x + y(x))^7 * (a+diff(y(x),x)) = 0)

@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.