@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

@Matt C Anderson How does that help in factoring the example in the Question?

Vote up.

The OP might be interested in simpliying that result. There are various ways to do that, eg.

P := x^4 - x^2 + x - 1:

raw := convert(PolynomialTools:-Split(P, x), radical);

new := map(collect,raw,x,simplify@rationalize);

@mmcdara I believe that the OP is asking about whether the Topic string of the currently opened Help page can be obtained while viewing it.

@gkokovidis That does actually have a boundary. (The boundary is a CURVES plotting substructure, and the filled region is a POLYGONS substructure.) You notice the boundary less here because it is red while that from the ellipse command is black by default.

But in your example the filled region is noticeably not rendered as red, and thus not a color match to the boundary. It is rendered noticeably lighter than red. That is because the plotting command sticks in 0.4 for the transparency of the filled region.

You can use a parametric form and get the whole thing (fill and boundary) rendered with the same shading by suppressing that transparency of the filled region. Eg,

r:=theta->2/sqrt((2*sin(theta))^2+(1*cos(theta))^2):
P:=plot([r(theta)*cos(theta),r(theta)*sin(theta),theta=0..2*Pi],
        filled=true,color=red,transparency=0,
        scaling=constrained,axes=none,size=[1000,500]);

Your formula given for -rA (along with the integral in your image) don't agree with the integand in your call to int. Is the integrand 1/(-rA) or is it -rA?

The shown formulas imply X*(1-X) is in the numerator, but your attempt at integration has it in the denominator.

@tomleslie Unfortunately the OP has omitted the context in which his piece of code made better sense.

I suspect that the context was such that the upright roman characters were desirable, and in which the goal was to prevent reformatting (in another notation) of the floating-point value by the interface. Perhaps it was connected to text appearing in a plot.