@Preben Alsholm 

I changed my code to avoid the change of variable in Int as I was doing it and the issue went away. I thougth using Inert int freezes the integral while I manipulate its content before changing it back to non Inert. 

But my main point, is, since content of Int is wrong, then why simplify(expr,size) do not give an error while simplify(expr) did?.

One would expect both to give an error in this case. 

@Carl Love 

I don't see any possibility of assume= anything being used as the 3rd argument.

Well, when it says

Is it too much of a jump to the assumption that last agument will be the third one in the case of  using size in simplify as in simplify(eq,size,assume=.....)   ? 

As for assume=positive  vs. assume=x::positive I had no idea this will make a difference. When I saw assume=positive, I assumed one can also write assume=x::positive. This is in case the expression has more than one symbol and want to tell it that only x is positive. 

If there is a subtle difference, may be help should be more clear on this and provide more examples for normal users.  

" even simplify(eq) returns an error"  

True. I just saw that. But then in this case, one would expect that  simplify(eq,size)  to also give an error, but it does not.

@Carl Love 

Yes ofcourse., I know it is timelimit(). I made typo. dsolve hangs without timelimit, so I wrote this quick test and made typo and wrote timeout instead of timelimit.

The main issue is that dsolve hangs. But I can work around it now, since I can add timelimit().

dsolve() typically returns implicit solution on its own when it can't solve for y(x) explicitly. May be it was trying to do this and that is why it hangs on this problem.

@tomleslie 

I know this transformation. This is Liouville Transformation on the dependent variable. I am looking for the transformation on the independent variable. From page 177, Theory of differential equations in engineering and mechanics / by K.T. Chau.

The above can be done by Maple

restart;
ode:= diff(w(z), z$2)+f(z)*diff(w(z),z)+g(z)*w(z)=0;
new_ode:=PDEtools:-dchange({w(z)=W(z)*exp(-1/2*int(f(z),z))},ode,{W}):
simplify(%)

Which gives the result in the book and what you show also (after canceling the exponential since not zero).

The transformation I am looking for is different. It is on the independent variable. Not the dependent variable.

@Carl Love 

Thanks Carl. Your method works well also. For checking for isobaric function case. (slight modification makes it also check for homogenous ode).

The bottom line is that the above is for checking if f(x,y) is isobaric. For an ode of the form y'=f(x,y), it is isobaric ode if there exist numerical solution p for f(x,y). 

Now your method and vv's give same result and both are correct results. I can now use both methods. If one fails for some reason, will try the second next. If both do not solve for numerical value of p, then most likely the ode is not isobaric.

restart:
f:= [
    (x,y)->-(y^2+2/x)/(2*y*x),
    (x,y)-> x*sqrt(x^4+4*y)-x^3,
    (x,y)-> (3*x+y^3)*y/(x*(x-y^3))
]:
map(f-> (solve(identity(f(a*x,a^p*y)=a^(p-1)*f(x,y), a), {p}) assuming a>0),f);

Q:=proc(F,x,y)   
    local eq,sol,t,p;
    eq:=eval(F,[x=t*x,y=t^p*y]) = t^(p-1)*F; 
    sol:=limit(diff(eq, t), t=1): 
    return simplify(solve(sol, p));     
end proc;
map(F->(Q(F(x,y),x,y)),f)

@vv 

I was working now on documenting my code and I just realized I do not know how to proof this result you show for this:

Could you please show how you obtained (2) or a reference to it? I do not see how (1) implies (2) even though it works when there exists such p.

@Joe Riel 

Yes, use Maple standard GUI, worksheet mode. It is very easy to reproduce as you can see above. Were you able to reproduce it on standard worksheet also?  

I ended up losing work on the worksheet, because even though I did SAVE FILE (while it was hanged), many times, and I thought it saved the worksheet, but when I had to terminate Maple and restarted, found that it did not actually save the worksheet as expected.

@Rouben Rostamian  

thanks. fixed it. I had 

pts:= map(X->eval({x,y},X),[cp]);

changed it to

pts:= map(X->eval([x,y],X),[cp]);

Because it was a set, maple changed the order on me in the middle without me noticing.

@acer 

I understand all of this. That an input of `*` could be expanded and they will become `+` and then factored, and the benifit will come from this. But I am not looking for such advanced things in my question due to where this function is used at this moment.

I simply want to pull a common factor term if possible from `+` expression. That is all. I added to my question that input will only need to be of type `+` to be more clear. 

@acer 

If there is something not clear in a question, people normally ask the poster to clarify things. There is not wrong about it. This happens all the time at stackexchange in comments below the question.

So if there was something not clear about the specification, you can simply ask for clarification before answering. 

I tried my best to explain the question, if there is still something not clear, I will try to make it more clear.

@acer 

I only need to find common factor when the input is of type `+`. If the input is already a product, i.e. type `*`, then I do not need to do anything with it.

The whole idea, is that if I have term such as x+x^2+y*x, I want to convert to product  x*(1+x+y) in order to process each operand one at a time, which will simply things. There are equations, So they have the form 

                     x+x^2+y*x=0

But when it is in the form

                    x*(1+x+y)=0

Then now the program can easily say x=0 or (1+x+y)=0.

If the input is already in the form `*` as in

              x^2*(x+x^3+x*y)=0

Then I do not need to find common factor. Since it is in product form already. All the examples I gave and all the initial description I showed, are of type `+` as you can see.

If you are saying I should have mentioned explicitly that input only needs to be `+` and nothing else, OK. I will add this now. But I thought this was clear, as common factor is done on type `+`. At least in traditional way one thinks about it.

@acer 

I am not convinced that your (current) code's accept/reject criteria match your prior descriptions.

why? I said first line the following

I am looking for a robust way to factor an expression (if applicable) to become    x^n*(rest)  as we do it by hand.

so the output of common_factor should be `*`, so I check if the result is `*` or not. Are you saying the check for denom(result)<>1 is not needed?  There was case where it did that, and I wanted to check for it:

expr:=diff(y(x),x)-(1+x^(1/2))/(1+y(x)^(1/2));
term:=y(x);
acer_V1_common_factor(term,expr);

But I see now your V2 fixed this;

expr:=diff(y(x),x)-(1+x^(1/2))/(1+y(x)^(1/2));
term:=y(x);
acer_V2_common_factor(term,expr);

But I thought to keep the check there as extra saftey. What is wrong with it?

I just saw this addition of your

Naturally that remark may not hold if you further edit it.

sorry, I have no idea what you are talking about here. I did not edit anything in the question. I simply cleaned up the testcases and put all tests into one function. If you can explain more what you mean that will help better understand what is the issue.

Can you explain why you added "incomplete question" tag to my question? What is incomplete about it?  Instead of doing all these things, why not explain to people simply what the issue you see in the question. If there something not clear, I can improve it. But adding side remarks like this and adding tag incomplete without any explaination is not helpful.

@acer 

But this case

 expr:=(x^2*y+x*y+x/y)/(y+p);

will not be even be used by common_factor. Becuase the program will only attempt to find a common_factor only on input which is not already of type `*`.

And the above is of type `*`. So I only need to worry about finding common factor on input which is not of type `*`. 

@J F Ogilvie 

Yes, you example gives Error, (in gcd/Freeze) arguments should be polynomials also. But actually for me, this is not a big deal, as I can simply trap this error and by pass it and just use the input in this case.

The main problem is when it changes the input to a much more complicated form, such as this

expr:=A-(1+x)/(1+y^(1/2));
term:=y;
common_factor(term,expr);

By hand, I would leave the expression as is as there is no common y(x) among the two terms.

It would be better if this would also throw the same error as the last one, becuase I would trap it and not use the result, but now the program does not now and it complicated the expression. 

I just thought of an idea! Simply add an extra check that the result is of type `*` but with denom=1 only. This will be able to detect such edge cases edges. If so, reject it and by pass. This with the trap should catch the two issues I see so far.

Will try it now on my main test program and see. Will take some hrs to finish. The test is running now...

@acer 

Unfortunately this did not work after testing it more. There are cases where it should have left the input as is, but it changed it to strange form for some reason which made the ode much more complicated that it was, and many other cases where it gives error that arguments should be polynomials.  I can handle the case when it throws a signal, as I can trap it and keep using the original input. But I can't handle the cases where the input becomes much more complicated like the first example below since the program does not know this happend.

When doing all these by hand, the result should be the input itself, as there is no common y(x) to pull out as can be seen.

As I mentioned in my question. The input can be any mathematical expression (actually they are all differential equations) but can be any valid differential equation, which can contain any mathematical functions and expressions.

restart;
common_factor := proc(x::algebraic, ee::algebraic)
  local p, d := gcd(ee, x^frontend(degree,[ee,x]),'p');
  d * p;
end proc:
print("*********************");
expr:=diff(y(x),x)-(1+x^(1/2))/(1+y(x)^(1/2));
term:=y(x);
common_factor(term,expr);
print("*********************");
expr:=diff(y(x),x) -(x-1)*y(x)^5/x^2/(-y(x)+2*y(x)^3);
term:=y(x);
common_factor(term,expr);
print("*********************");
expr:=3*y(x)+diff(y(x),x) - 2*x/exp(3*x);
term:=y(x);
common_factor(term,expr);

I'll try to implement a brute force parsing method for this by looking at each term and collect all terms one by one. and see if there is a common factor that way.