Ordering Products

[Ron Adam]

Kay Schluehr wrote:
> Ron Adam wrote:
> 
>> Kay Schluehr wrote:

>> BTW.. Usually when people say "I don't want to discourage...", They
>>  really want or mean the exact oppisite.
> 
> Yes, but taken some renitence into account they will provoke the 
> opposite. Old game theoretic wisdoms ;)

True..  but I think it's not predictable which response you will get
from an individual you aren't familiar with.  I prefer positive
reinforcement over negative provocation myself. :-)


> But you seem to fix behaviour together with an operation i.e.
> declaring that __mul__ is commutative. But in a general case you
> might have elements that commute, others that anti-commute ( i.e. a*b
> = -b*a ) and again others where no special rule is provided i.e. they
> simply don't commute.
> 
> But much worse than this the definition of the operations __add__, 
> __mul__ etc. use names of subclasses A,D explicitely(!) what means
> that the framework can't be extended by inheritance of A,D,M etc.
> This is not only bad OO style but customizing operations ( i.e.
> making __mul__ right associative ) for certain classes is prevented
> this way. One really has to assume a global behaviour fixed once as a
> class attribute.

I don't know if it's bad OO style because I chose a flatter model.
Your original question wasn't "what would be the best class structure to
use where different algebra's may be used".  It was how can sorting be
done to an expression with constraints. And you gave an example which 
set __mul__ as associative as well.

So this is a different problem.  No use trying to point that what I did
doesn't fit this new problem, it wasn't suppose to.  ;-)

I'm not sure what the best class structure would be.  With the current
example,  I would need to copy and edit F and it's associated sub
class's to create a second algebra type, F2, A2, M2.. etc.  Not the best
solution to this additional problem which is what you are pointing out I
believe.

So...  We have factors (objects), groups (expressions), and algebras
(rules), that need to be organized into a class structure that can
be extended easily.

Does that describe this new problem adequately?  I'm not sure what the
best, or possible good solutions would be at the moment.  I'll have to 
think about it a bit.


>> c*3*a*d*c*b*7*c*d*a = (21*a*a*b*c*c*c*d*d)
> 
> 
> I still don't see how you distinguish between factors that might 
> commute and others that don't. I don't want a and b commute but c and
> d with all other elements.

In my example factors don't commute.  They are just units, however
factors within a group unit may commute because a group is allowed to 
commute factors if the operation the group is associated to is commutable.


> If you have fun with those identities you might like to find 
> simplifications for those expressions too:
> 
> a*0   -> 0 a*1   -> a 1/a/b -> b/a a+b+a -> 2*a+b a/a   -> 1 a**1  ->
> a
> 
> etc.

Already did a few of those.  Some of these involve changing a group into 
a different group which was a bit of a challenge since an instance can't 
magically change itself into another type of instance, so the parent 
group has to request the sub-group to return a simplified or expanded 
instance, then the parent can replace the group with the new returned 
instance.

    a*a*a -> a**3     change from a M group to a P group.
    a*0   -> 0        change from a M group to an integer.
    a*1   -> a        change from a M group to a F unit.
    a+b+a -> 2*a+b    change a A subgroup to a M group.
    a/a   ->          change a D group to an integer.
    a**1  ->          change a P group to a M group to a F unit.

Some of those would be done in the simplify method of the group.  I've 
added an expand method and gotten it to work on some things also.

   a*b**3  ->  a*b*b*b
   c*4     ->  c+c+c+c


>> What do you mean by 'sub-algebra generation'?
>  
> Partially what I described in the subsequent example: the target of
> the addition of two elements x,y of X is again in X. This is not
> obvious if one takes an arbitrary nonempty subset X of Expr.

Would that be similar to the simultaneous equation below?

    z = x+y        <-  term x+y is z
    x = a*z+b      <-  z is in term x
    x = a(x+y)+b   <-  x is again in x  (?)

I think this would be...

 >>> x, y = F('x'), F('y')
 >>> z = x+y
 >>> x = a*z+b
 >>> x
(((x+y)*a)+b)

This wouldn't actually solve for x since it doesn't take into account 
the left side of the = in the equation.  And it would need an eval 
method to actually evaluated it.  eval(str(expr)) does work if all the 
factors are given values first.


Cheers,
Ron