How could one tell Maple to simplify  log(x)+log(y) to log(x*y)?

As Maple own apps says  https://www.maplesoft.com/support/help/maple/view.aspx?path=MathApps%2FProductRuleForLogarithms

And known identity  https://en.wikipedia.org/wiki/List_of_logarithmic_identities

This is what I tried

restart;
simplify( ln(x) + ln(y), symbolic);
simplify( ln(x) + ln(y), ln);
simplify( ln(x) + ln(y), size);

Maple knows this identity, becuase

simplify( ln(x*y)- (ln(x)+ln(y)) , symbolic)
       0

Note, this identity has no assumptions on it. It is defined as is.

Maple help page says

ln(x y) ==> ln(x) + ln(y) provided     0 < x  and   signum(y) is unknown

so, is Wikipedia and all the other references I saw wrong for not showing this assumption on x>0 whey they state the product rule for logs?

I want to go the other way

 ln(x) + ln(y) ==> ln(x y) 

So this releation should really be written as

ln(x) + ln(y) <==> ln(x y) 

is there a way to change the color of just the labels on the axis ticks only? 

I wanted to do this for DEplot, but I started with normal plot since it is easier. I could change the colors of the axis, but this changes not only the tick labels but the whole axis itself:

restart;
plot(sin(x),x=-Pi..Pi,axis=[tickmarks=[color=red]], color=blue);

So the axis itself changed color as well. It is OK for the ticks as well as the ticks labels (the numbers of the ticks). But prefer the axis itself not to be red.

Once there is a way to do the above, I wanted to apply to DEtools:-DEplot. Why? Becuase it is hard to read the Axis tick labels on DEplot. I thought that changing the color of the tick labels will it easy. But DEtools:-DEplot does not even accept axis command:

ode:= diff(y(x),x)=2*x:
DEtools:-DEplot(ode,y(x),x = -2 .. 2,y = -2 .. 2, [[0.1,0]],
               labels=["",""],
               linecolour = red,
               color = blue,
               'arrows' = 'medium',
               axesfont=['Times', 'bold', 12]
               );

You can see it is hard to read the axis tick labels above, as arrows go over some of them,. If I make them say RED, I think it will make it more clear.

Now when adding the axis options, it gives error

DEtools:-DEplot(ode,y(x),x = -2 .. 2,y = -2 .. 2, [[0.1,0]],
               linecolour = red,
               color = blue,
               arrows = MEDIUM,
               axesfont=['Times', 'bold', 10],
               axis=[tickmarks=[color=red]]
               );

Error is generated, axis is not supported command.

Any idea how to make tick labels red for DEtools:-DEplot? It will be OK if I can get both the axis and the ticks RED, at least it will be better than it is now.

One workaround way I currently use is this:

ode:= diff(y(x),x)=2*x:
p1:=DEtools:-DEplot(ode,y(x),x = -2 .. 2,y = -2 .. 2, [[0.1,0]],
               labels=["",""],
               linecolour = red,
               color = blue,
               'arrows' = 'medium'                    
               );
p2:=plot(0,x=-2..2,y=-2..2,axis=[tickmarks=[color=red]]);
plots:-display([p2,p1]);

But this seems like a hack to me. There should be a way to directly set tickmarks color in DEplot?

Is there a place to read about rules for naming constants of integrations for solution of ODE so that Maple odetest will not have problem verifying solution of an ODE?

It seems Maple does not like some constant names. If I use C or C1 or C[1] or A etc... odetest does not give back zero, even thought the solution is exactly the same as Maple's, except Maple uses _C1.

I read one is not supposed to use _ constants in own code, since these are reserved for Maple.

So what is one supposed to use? Here is an example

restart;
ode:=2*sqrt(x)*diff(y(x),x)=sqrt(1-y(x)^2):
my_sol:=y(x)=sin(sqrt(x)+(1/2)*C1);

Compare to Maple own solution

maple_sol:=dsolve(ode,y(x));

You can see, there is no difference, except the name of the constant.  Yet, Maple does not odetest my solution

odetest(my_sol,ode);

I tried naming my constant to C, C[1], A, Z, etc.. I got tired trying. Only when I use _C1 does Maple give zero for odetest.

What is so special about _C1?  And if one can't use _ symbols as Maple says, what is one to to do? 

Maple 2018.1, Physics version `2018, July 21, 4:16 hours, version in the MapleCloud: 78, version installed in this computer: 78`

From answer posted in https://www.mapleprimes.com/questions/225137-Internal-Symbol-Z1--Causes-Error-

I've learned to use

subsindets(expr, 'suffixed(_)', f->n);

To replace in a Maple generated solution which contains system suffix, such as _Z, _Z1, etc... returned by Solve and Maple calls, with a symbol that I find easier to read. The above works in some cases but not others. For example, it works on this result

restart;
expr:=signum(0, _Z, 1);
subsindets(expr, 'suffixed(_)', f->n);

                      signum(0, n, 1)

But not on this one

restart;
expr:=RootOf(signum(0, _Z, 1));
subsindets(expr, 'suffixed(_)', f->n);

             RootOf(signum(0, _Z, 1))

I do not want to use pattern matching, since the result is something I do not know what it will be. I just want to replace all those Maple symbols that start with _Z in the solution by another symbol. I can't use subs() either, since I do not know what the symbol will be.

What is the correct way to do this?

Should this generate an error?

restart;
r:=evalc(Im(1/ln(x)));
solve(r,{x});

This did not help. Same error as above.

restart;
r:=evalc(Im(1/ln(x))):
solve(r,{x}) assuming x::real;

This made Maple not give an error

restart;
r:=evalc(Im(1/ln(x))):
solve(r,{x}) assuming x::real, x>0;

       {x = x}

Also this worked, but NULL returned

restart;
r:=evalc(Im(1/ln(x))):
solve(r,{x}) assuming x::real, x<0;

Also this worked with NULL returned

restart;
r:=evalc(Im(1/ln(x))):
solve(r,{x}) assuming   x<0;

Is this how Maple generally works? i.e It generates an exception error when it is not able to solve something? Or does it normally echo back the input back if it can't solve something? Or at least return NULL if it can't solve it? I am havin hard time figuring which method to use to check if Maple is able to solve something or not, because each time it seems to do something different.

Should one then put a try/catch around each Maple call, and treat the try section as if Maple was not able to solve the equation whatever it was?