@vv Okay, my procedure has been corrected, and I added your new example to the examples section.

Kitonum's solution also "fails" for eval('g(x)', x= 2*x), yet you gave his a vote up whereas mine is treated like a piece of trash to be kicked to the side of the road.

@emendes If L is a list, then <L> will print line by line. If L has more than 10 members, then you'll need to issue the command

interface(rtablesize= infinity);

You only need to issue this command once per session, and you can put it in an initialization file. You can replace infinity by any positive integer that you want to be the maximum number of lines to use.

@vv I think that eval can be easily corrected to handle these situations (see my Answer). If this were done, then there's no need to inform the user about potential problems.

@ecterrab I wonder if you would feel the same way if it were sum instead of int? Please see my Answer below where I apply the same principles to both the default sum and your redefined sum from the Physics package, and then I apply my corrected version of eval to both.

I feel, and I believe that VV feels, that regardless of what the function f is, eval(f(x), x= 1) should equal eval(f(z), z= 1). If this isn't true, then eval is no better than subs.

Ideally, all procedures which use bound variables in their arguments (such as int, sum, limit) should treat their bound variables the same way that seq, add, and mul treat their bound variables. Furthermore, there should be a parameter modifier to declare a variable as having that special status like the bound variables of  seq, add, and mul.

@Preben Alsholm The way that Google (and I guess some other search engines) order search results in based (partly) on how many other web pages the URLs appear on. This is the famous "Page-rank algorithm"---how Google founder Larry Page became famous. Thus, someone who wants to raise the rank of their page wants to get their page's URL mentioned on as many other pages as possible. This is called SEO: Search Engine Optimization. (Not all SEO is nefarious. Legitimate non-spam-related SEO is a major business.)

I spend 10 - 30 minutes every day (except Sunday) deleting spam. There's much less spam on Sunday. Each deletion requires four clicks and three page refreshes: click on title, refresh, scroll down, click on More, click on Delete as Spam, refresh, click on Delete, refresh. And MaplePrimes has by far the slowest page refresh of any web site that I visit regularly.

We need BULK-MODE DELETE! On the page www.mapleprimes.com/recent, there should be a column of check-off boxes next to the titles, just like any web-based email system has. We should be able to check off a bunch of boxes, then one click on a Delete as Spam button, and then they're all gone with NO CONFIRMATION DIALOG. If any in the bunch have Replies, or any are from users with nonzero reputation, then you can reject the deletion operation.

I have deleted thousands of spam, so I know: I don't recall ever seeing spam from someone with a nonzero reputation. Perhaps once or twice in the years that I've been doing this have I seen spam with a Reply. These cases are so rare that they're not worth considering in the bulk-mode delete. If they occur at all, they can be deleted through the ordinary means.

Perhaps you can restrict the bulk-mode delete to users with reputation over 1000.

Since a significant percentage, perhaps the majority, of legitimate Questions come from users with zero reputation, I'm totally and vehemently opposed to the idea of quarantining Questions from users with zero reputation.

I'm hesitant about the captcha idea. Because of what Axel said, we don't know if it'll actually work. If it doesn't work, then it'll be a year or so until the next idea is tried. And I don't want the legimate new users to be inhibited, as Bryon says. On the other hand, the bulk-mode delete is guaranteed to work.

Finally, any user whose username ends with "juriya" is a spammer. I don't know what it means; it's just a pattern that I noticed.

@emendes To use sort directly with a monomial order, the object being sorted needs to be a polynomial, not a list. That is why in my original Answer that I added the monomials (`+`(M)) before sorting. To sort a list of monomials, you need to use TestOrder.

But you didn't say if my most-recent procedure works for you.

@emendes My Answer at the beginning of this subthread was a little bit more complicated than it needed to be because I forgot about the comparison function Groebner:-TestOrder. Here's a procedure using it:

monomials := proc (p::polynom, vars::list)
local
     M,
     v:= indets(p, suffixed({vars[]})),
     C:= coeffs(expand(p), v, 'M'),
     P:= plex(ListTools:-Reverse([v[]])[]),
     S:= sort(`[]`~([C],[M]), (a,b)-> not Groebner:-TestOrder(a[2], b[2], P))
;
     (map2(op, 1, S), map2(op, 2, S))
end proc:

That should work in Maple 14. It can be done more elegantly in later Maple.

Let me know if that works for you, and if it produces what you consider to be plex order. Apparently that's a little different from how Maple considers it because I needed to use the Reverse and the not to get the order shown in your Question above.

@Art Kalb See my Answer below, where I explain the difference.

@emendes Do you want it to return a list of the monomials in plex order and a list of the coefficients in the corresponding order and have it work in Maple 14?

@acer Ah, I just failed to test a case with an even number of arguments where no condition is satisfied. Thanks!

@sunit You wrote:

I just wanted to remove these terms from my equations. So this is the way i came up with.

Sure, if you consider these formulae to be just abstract symbols and you want any terms containing either X or 1/X to disappear, you can just say "Poof!" (or use computer algebra) and then they're set to 0. But how can your model have any physical relevance if you do that? Sure, I can see setting one of them to 0 if it's considered to be small. But if one is small then the other is big, no?

@emendes Ah, you just want the coefficients and monomials to be in corresponding order and you don't care what that order is? That's much easier than sorting because coeffs will guarantee it.

There were two problems with the worksheet that you posted. The first is that your polynomial ddd was in square brackets. The second is that if you're going to collect, then you need to collect distributed. But there's no need to collect: expand will be enough.

Two more tips: M should be a local of monomials. The second argument of monomials can be simply [x]. The suffixed means that any name beginning with x will be treated as a variable; any others will be treated as coefficients.

Let me know if this does what you want:

restart:

ddd:=
     theta[1]*theta[5]*x3-theta[15]*x2^2+2*theta[15]*theta[6]*x2*x1*x0-
     theta[12]*theta[5]*x2*x1+2*theta[15]*theta[4]*x2*x1+2*theta[15]*
     theta[1]*theta[3]*x2*x0-theta[11]*theta[1]*theta[5]*x2*x0-theta[5]*
     theta[1]*theta[6]*x2*x0-theta[5]*theta[1]*theta[4]*x2-theta[15]*
     theta[6]^2*x1^2*x0^2+theta[12]*theta[5]*theta[6]*x1^2*x0-2*theta[15]*
     theta[4]*theta[6]*x1^2*x0-theta[1]*theta[6]*theta[5]*x1^2+theta[12]*
     theta[5]*theta[4]*x1^2-theta[15]*theta[4]^2*x1^2-theta[14]*theta[5]^2*
     x1^2+theta[11]*theta[1]*theta[5]*theta[6]*x1*x0^2-2*theta[15]*theta[6]*
     theta[1]*theta[3]*x1*x0^2-2*theta[15]*theta[4]*theta[1]*theta[3]*x1*x0+
     theta[11]*theta[1]*theta[5]*theta[4]*x1*x0-theta[1]*theta[10]*theta[5]^2*
     x1*x0+theta[12]*theta[5]*theta[1]*theta[3]*x1*x0-theta[1]^2*theta[3]*
     theta[5]*x1-theta[15]*theta[1]^2*theta[3]^2*x0^2+theta[11]*theta[1]^2*
     theta[5]*theta[3]*x0^2-theta[1]^2*theta[13]*theta[5]^2*x0^2-theta[1]^2*
     theta[9]*theta[5]^2*x0
:
monomials := proc (p, vars::list)
local M, C;
   C:= coeffs(expand(p), indets(p, suffixed({vars[]})), 'M');
   ([C],[M])
end proc:

(C,M):= monomials(ddd, [x]);

C, M := [-theta[6]^2*theta[15], -2*theta[1]*theta[3]*theta[6]*theta[15]+theta[1]*theta[5]*theta[6]*theta[11], -theta[1]^2*theta[3]^2*theta[15]+theta[1]^2*theta[3]*theta[5]*theta[11]-theta[1]^2*theta[5]^2*theta[13], -2*theta[4]*theta[6]*theta[15]+theta[5]*theta[6]*theta[12], 2*theta[6]*theta[15], -2*theta[1]*theta[3]*theta[4]*theta[15]+theta[1]*theta[3]*theta[5]*theta[12]+theta[1]*theta[4]*theta[5]*theta[11]-theta[1]*theta[5]^2*theta[10], 2*theta[1]*theta[3]*theta[15]-theta[1]*theta[5]*theta[6]-theta[1]*theta[5]*theta[11], -theta[1]^2*theta[5]^2*theta[9], -theta[1]*theta[5]*theta[6]-theta[4]^2*theta[15]+theta[4]*theta[5]*theta[12]-theta[5]^2*theta[14], 2*theta[4]*theta[15]-theta[5]*theta[12], -theta[1]^2*theta[3]*theta[5], -theta[15], -theta[1]*theta[4]*theta[5], theta[1]*theta[5]], [x0^2*x1^2, x0^2*x1, x0^2, x0*x1^2, x0*x1*x2, x0*x1, x0*x2, x0, x1^2, x1*x2, x1, x2^2, x2, x3]

Verify that coefficients and monomials match:
simplify(inner(C,M) - ddd);
     0

@emendes For that, I think that you simply needs coeffs:

coeffs(collect(p, vars, 'distributed'), vars, 'M'):

then [M] is your list of monomials. I need a good example from you to work with because I'm not too familiar with sorting monomials.

Sorry that I missed your question about expand. Yes, it makes sense that it might be needed. The polynomial in your original Question was already expanded, so I didn't think of it.

Can you show an example in a posted worksheet of what you mean by "The procedure does not work if collect has been used"?

@sunit My analysis so far indicates that the expression that you call trash8, which is the denominator of the expression that you're trying to plot, is identically equal to 0. Any nonzero evaluation of it that you get is just noise caused by round-off error. As you increase the value of Digits, these noise values get closer to 0, which makes the plot even wilder because you're dividing by them.