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.

@mmcdara In your followup's second example the term sin(X(t)) appears in the result, whereas in your followup's first example k*X(t) does not appear in the result. Hence you see the psi in the second, but not phi in the first.

If you don't want psi to appear then you could remove the alias. (I'm not sure I understand when you do or do not want the effect of the alias in output, given both your original question and your followup.)

Download alias_ex2.mw

You wrote, "I want each element in the array to be an empty list, so I can later add to it."

That is inefficient, and not sensible, since a list is not really a mutable data structure.