Ordering Products

[Diez B.Roggisch]

> I have to admit that I don't understand what you mean with the
> 'constant parts' of an expression?

>From what I percieved of your example it seemed to me that you wanted to 
evaluate the constants like 7*9 first, so that an expression like

a * 7 * 9 * b 

with variables a,b is evaluated like this:

a * 63 * b

So my suggestion was simply to make the *-operator more precedent when 
in between two constants. What I mean with constants here are  of course
integer/float literals. The concept of a differing operator precedence
can be extended to arbitray elements when their types are known - which 
should be possible when variable values are known at parsing
time.

> The associativity of __mul__ is trivially fullfilled for the dummy
> class M if an additional __eq__ method is defined by comparing factor
> lists because those lists are always flat:

I don't care about that, as my approach deosn't use python's built-in parser
 - it can't, as that wouldn't allow to re-define operator  precedence. 

What you do is to
simply collect the factors as list. But what you need (IMHO) is a parsing
tree (AST) that reflects your desired behaviour by introducing a different
precedence thus that the expression

a * 7 *9 * b

is not evaluated like

((a*7)*9)*b

(which is a tree, and the standard way of evaluationg due to built-in parsers
precedence rules) but as 

a*(7*9)*b

which is also a tree.

> The sorting ( or better 'grouping' which can be represented by sorting
> in a special way ) of factors in question is really a matter of
> (non-)commutativity. For more advanced expressions also group
> properties are important:

No, IMHO associativity is the important thing here - if 

(a * 7) * 9

yields a different solution than

a *(7*9)

your reordering can't be done - in the same way as re-arranging
factors a*b to b*a only works if the commute - or, to put in in
algebraic terms, the group is abelian.
 
> If a,b are in a center of a group G ( i.e. they commute with any
> element of G ) and G supplies an __add__ ( besides a __mul__ and is
> therefore a ring ) also a+b is in the center of G and (a+b)*c = c*(a+b)
> holds for any c in G.
> 
> It would be nice ( and much more efficient ) not to force expansion of
> the product assuming distributivity of __add__ and __mul__ and
> factorization after the transposition of the single factors but
> recognizing immediately that a+b is in the center of G because the
> center is a subgroup of G.

Well, you don't need to expand that product - the subexpression a+b is
evaluated first. If you can sort of "cache" that evaluation's result because
the expressions involved are of a constant nature, you can do so.

The rason (a+b) is evaluated first (at least in the standard python parser,
and in my proposed special parser) is that the parentheses ensure that.

To sum things up a little: I propose not using the python built-in parser
which results in you having to overload operators and lose control
of precedence, but by introducing your own parser, that can do the
trick of re-arranging the operators based on not only the "usual" precedence
(* binds stronger than +), but by a type-based parser that can even change
precedence of the same operator between different argument types is's 
applied to. That might sound complicated, but I think the grammar 
I gave in my last post shows the concept pretty well.

regards,

Diez