@janhardo You could also attempt numerical validation.

You could do that for a specific pair of values for b and z.

Or you could plot it, testing many values of b and z.

The following computes for many (here, purely real) values of both b and z. It has some numeric roundoff error but the difference is clearly very nearly zero. That means that there's no sign difference (which concerned you). Of course the value b=0 is problematic, but we already knew that.

plot3d([Re,Im](arctan(z/b)/b-ans),b=-4..4,z=-4..4,
       color=[red,blue],grid=[100,100],view=-1e-14..1e-14);

@Carl Love A starting point...

@Ronan We saw that you might now be using that as a Start Page.

I suppose that you could also (right-click) toggle off that Table's borders, just prior to exporting.

@janhardo Your call diff(%) is invalid syntax, and makes no sense. You've forgotten to tell Maple the name with which to differentiate.

Perhaps you meant to differentiate with respect to x.

simplify(exp(x*alpha)*cos(x*beta)*alpha/(alpha^2 + beta^2)
         + exp(x*alpha)*sin(x*beta)*beta/(alpha^2 + beta^2));

diff(%, x);

simplify(%);

@Christopher2222 Yes, there have been several postings over the years in which it's been shown that `simplify` does not try all (speculative) flavours of calls to `collect` and so can miss the most compact forms.

That is now quite well "known".

There is a balance between power and time, in simplification. Of course it's easy to say that some trivial example (like this one) ought to be handled. But one of the problems is in drawing a line in the sand, because some examples get slowed down tremendously while others are easy. Where a line is drawn will always be unsatisfactory to some people.

The subtleties here are more than most people realize. To make effective progress requires a huge collection of examples, to guard against severe behavioral regression.

However, `collect` is tangential here since it's already been mentioned that internally `simplify` actually produces the desired, partially factored forms under discussion. The central issue seems to be why its not always returned.

@mmcdara We're discussing how it decides which to accept. In both cases the partially factored result is generated and -- somehow -- analyzed.

That fully factored form doesn't get generated by the code we're discussing, so doesn't enter into the specifics of the computation path under discussion. The fact that simplify doesn't always call factor is also interesting, but tangential here. (It also doesn't always call collect.These are not a obscure facts, but are tangential in this quite specific context.)

@Carl Love I'd agree that sieving out nonreal results is a good last step.

But I'm not sure that option `real` to `solve` is best here. It can even interfere in some nonpolynomial cases.

The Jave GUI's 3D plot driver can finicky, especially w.r.t. operating sysyem graphic drivers.

Precisely which version of ubuntu are you using? Is it in the list of 64bit Linux versions officially supported by Maple 2019?

What's the video card and what (if any 3rd party) graphics driver might you have installed for it?

@vv You're now refering to a different procedure than you mentioned before, `simplify\size\size\object`.

But that's beside my main point. The original Question asked why t^2*x^2+t^2*y^2 partially factored while t^2*x^2-t^2*y^2 did not. Your answer of why the former happens does not explain why the latter does not.

Both of those respectively have a smaller measure for the corresponding partially factored form, according to `simplify\size\size`. or even `simplify/size/size/object` for that matter. Your Answer omits this additional information for the other expression,

`simplify/size/size`~([ t^2*x^2+t^2*y^2, t^2*(x^2+y^2) ]);

                [56, 38]

`simplify/size/size`~([ t^2*x^2-t^2*y^2, t^2*(x^2-y^2) ]);

                [59, 46]

Or,

`simplify/size/size/object`~([ t^2*x^2+t^2*y^2, t^2*(x^2+y^2) ]);

                [16, 12]

`simplify/size/size/object`~([ t^2*x^2-t^2*y^2, t^2*(x^2-y^2) ]);

                [17, 13]

So those measures' pairwise straight comparisons do not explain why one of them does get partially factored and one of them does not.

There must be some other key difference (be it structural, or that the measure comparison is graded, etc.)

@vv I don't see how `simplify/size/size` relates to whether t^2*x^2+t^2*y^2
 gets factored, or why t^2*x^2-t^2*y^2 does not get partially factored. I'll explain what I mean:

As far as I can see, a measure by `simplify/size/size` is not compared against another when dealing with t^2*x^2+t^2*y^2, since `simplify/size/size` gets called only once. So that part of the explanation -- that results from that procedure are compared -- seems inaccurate.

More importantly, it doesn't address the important aspect of the actual Question, which is the key point that t^2*x^2-t^2*y^2 does not get factored wrt t even though a similar measurement -- were it even made twice -- would provide the same kind of straight relative comparison.

I don't understand all the up-votes, as this doesn't seem to be a correct explanation. It doesn't rely on the measurement of t^2*(x^2-y^2).

@Carl Love There is no guard against nonreal results comming out of the CritPts procedure, and in such a case ViewRange throws an error.

Eg,
   PlotAndTable((x,y)-> x^4 - 3*x^2 - 2*y^3 + 3*y + 4*x*y);

@nm Your latest logic does not apply in the case of my (already provided) example,

    (x^2*y+x*y+x/y)/(y+p)

The factoring of the numerator to x*(x*y+y+1/y) would bring the very same kind of benefit, to be able to "easily say" x=0 or (x*y+y+1/y)=0, except for the singular situation where y=p. Is this all about not getting hung up on that? If so then consider another (already provided) example,

     (x^2*y+x*y+x/y)*(y+p)

In this case the factorization brings the very same kind of benefit you mentioned. 'The fact that the original expression is of type `*` does not affect that benefit or the possibility of that beneficial conclusion.

@nm Why do you not understand that you have not provided a precise description of the class of input that you want altered (factored, say), and in what way you want it altered?

The act of (only) providing a collection of examples is not a precise description of the class of input or the goal, if you have additional, unprovided, different examples against which you will run the code.

And when you provided further examples you change the criteria. An edit of the text of the Question to provide additional examples is an edit that changes the requirements.

@nm I did not claim that you're check was faulty. I said that I was not convinced it matched the earlier description. You have mischaracterized my comments. And indeed the code's check does not match the earlier description. Nowhere in the earlier discussion was it mentioned that the input must not satisfy denom(result)<>1 . Nowhere in the earlier discussion was it mentioned that the input expression might not have some denominator<>1.

The fact that one faulty result just happened to have denom(result)<>1 does not logically imply that all correct results must not have that quality.

In addition to all that, the criteria are unclear. What's the important distinction between these?
    x^2 + x + x^3*w
    (x^2 + x + x^3*w) * (y+1)
    (x^2 + x + x^3*w) * (y+1)^(-1)
    (x^2 + x + x^3*w) / (y+1)
Why wouldn't you want to pull out the common factor of x from all of those? Just "as we do it by hand."

@nm Your latest revised criteria is certainly not implied by what you've written (so far) in your Question's text.

And your latest claim makes the criteria somewhat murkier. Pulling out a factor of x out from,
   (x^2*y+x*y+x/y)/(y+p)
seems quite reasonable in the context so far.

And why not be able to pull it out of,
   x^3+(x^2*y+x*y+x/y)*(y+p)
as well?

Anyway, if you don't want that then you might try my second code (as I see you've looked at).

If the criteria are unclear then it's less productive. Please provide a precise description of the task.