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.

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

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

@nm Naturally, if you provide further examples then it may require further adjustment.

For example,

common_factor := proc(x, ee) local d, t;
  if ee::`+` then
    t := max(map(proc(u) local r:=frontend(degree,[u,x]);
                         `if`(r::numeric,r,0); end proc,[op(ee)]));
    d := gcd(numer(ee),x^t);
    d*map(u->u/d,ee);
  else ee; end if;
end proc:

smthng2.mw
I await further different kinds of examples.

ps. I don't think that trapping errors (and leaving such expressions as is) is a great idea. That could miss some examples that could actually be handled.

(I don't really want to freeze functions calls other than the `x` term and things of type {`+`,`*`,`^`} -- up front by hand, or via frontend `` before calling `gcd`, if I don't have to.)

[edit] Here are some alternatives. The commented lines allow yet additional alternatives.

common_factor := proc(x, ee) local d, t;
  if ee::`+` then
    t := max(map(proc(u) local r:=frontend(degree,[u,x]);
                         `if`(r::numeric,r,0); end proc,[op(ee)]));
    d := gcd(numer(ee),x^t);
    d*map(u->u/d,ee);
    #d*map(u->frontend(expand,[u/d]),ee);
  else
    t := frontend(degree,[ee,x]);
    d := gcd(numer(ee),x^t);
    d*frontend(expand,[ee/d]);
    #d*frontend(expand,[numer(ee)/d])/denom(ee);
  end if;
end proc:

And here is a harder example than you've provided so far. The goal might be to distribute the division by d over the numerator (a sum) without distributing the division by the denominator. A problem is that numer and denom may expand.

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

Two different (correct but unnecessarily altered) results arise from the above revision, depending on which alternative is used for the case that ee is not of type `+`.

A possibility for such a harder case (or, nesting of this difficulty, harder still) is a recursive approach maps over sums until no product has a sum as multiplicand.

@Carl Love Your second example is written as,

   Enumerate2:= (L::list, f)-> local p; [seq]([p, f(p)], p= L)):

which is a syntax error of an extra closing bracket. Presumably you intended,

   Enumerate2:= (L::list, f)-> local p; [seq]([p, f(p)], p= L):

@janhardo I'm sorry, but I don't understand your sentence.

You originally mentioned [p,f(p)] for every p in L, and you didn't specify what f should be. So I did what you asked.

And then afterwards in your followup comment you mentioned sin(x). You can replace f with something appliable, eg.

L:=[0, Pi/6, Pi/4, Pi/3, Pi/2]:

[p->p,sin]~(L);

    [        [1     1]  [1     1  (1/2)]  [1     1  (1/2)]  [1      ]]
    [[0, 0], [- Pi, -], [- Pi, - 2     ], [- Pi, - 3     ], [- Pi, 1]]
    [        [6     2]  [4     2       ]  [3     2       ]  [2      ]]

You could also construct a reusable procedure that takes f as an argument, as Carl did. It's such short code that I didn't bother; the merit of that depends on whether you intend on using it many times.

In order for email notifications to work the user's profile (on this site) needs to include a valid, working email address. 

That may sound obvious. I mention it because I know of at least a few active members whose profile contains some email address which bounces messages.

@lcz My use of _rest was within the procedure ex2. As Carl mentioned, it allows extra arguments to be passed along.

In this situation it would allow someone to optionally adjust the `frontend` use, in a call-by-call way.

The _rest doesn't mean anything outside any procedure. At the top-level it's just a name. So it's incorrect to use it as you did.

@Christopher2222 Here are some ideas. You don't have to use %* instead of wrapping the first multiplicand in a call to ``(), though I prefer it.

But I really do think that it's better to frontend the expand call, as that last example in this example demonstrates.

extr.mw