Re: Ordering Products
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 - 0change from a M group to an integer.
a*1 - achange from a M group to a F unit.
a+b+a - 2*a+bchange 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Ron Adam wrote:
Kay Schluehr wrote:
Here might be an interesting puzzle for people who like sorting
algorithms ( and no I'm not a student anymore and the problem is not a
students 'homework' but a particular question associated with a
computer algebra system in Python I'm currently developing in my
sparetime ).
For motivation lets define some expression class first:
This works for (simple) expressions with mixed multiplication and addition.
class F(list):
def __init__(self,*x):
#print '\nF:',x
list.__init__(self,x)
def __add__(self, other):
return A(self,other)
def __radd__(self, other):
return A(other,self)
def __mul__(self, other):
return M(self,other)
def __rmul__(self, other):
return M(other,self)
def __repr__(self):
return str(self[0])
def __order__(self):
for i in self:
if isinstance(i,A) \
or isinstance(i,M):
i.__order__()
self.sort()
class A(F):
def __init__(self, *x):
#print '\nA:',x
list.__init__(self, x)
def __repr__(self):
self.__order__()
return +.join([str(x) for x in self])
class M(F):
def __init__(self,*x):
#print '\nM:',x
list.__init__(self,x)
def __repr__(self):
self.__order__()
return *.join([str(x) for x in self])
a = F('a')
b = F('b')
c = F('c')
d = F('d')
print '\n a =', a
print '\n b+a+2 =', b+a+2
print '\n c*b+d*a+2 =', c*b+d*a+2
print '\n 7*a*8*9+b =', 7*a*8*9+b
a = a
b+a+2 = 2+a+b
c*b+d*a+2 = 2+a*d+b*c
7*a*8*9+b = 9*8*7*a+b -- reverse sorted digits?
The digits sort in reverse for some strange reason I haven't figured out
yet, but they are grouped together. And expressions of the type a*(c+b)
don't work in this example.
It probably needs some better logic to merge adjacent like groups. I
think the reverse sorting my be a side effect of the nesting that takes
place when the expressions are built.
Having the digits first might be an advantage as you can use a for loop
to add or multiply them until you get to a not digit.
Anyway, interesting stuff. ;-)
Cheers,
Ron
Hi Ron,
I really don't want to discourage you in doing your own CAS but the
stuff I'm working on is already a bit more advanced than my
mono-operational multiplicative algebra ;)
Mixing operators is not really a problem, but one has to make initial
decisions ( e.g about associativity i.e. flattening the parse-tree )
and sub-algebra generation by means of inheritance:
a,b = seq(2,Expr)
type(a+b)
class '__main__.Expr'
class X(Expr):pass
x,y = seq(2,X)
type(x+y)
class '__main__.X'
This is not particular hard. It is harder to determine correspondence
rules between operations on different levels. On subalgebras the
operations of the parent algebra are induced. But what happens if one
mixes objects of different algebras that interoperate with each other?
It would be wise to find a unified approach to make distinctive
operations visually distinctive too. Infix operators may be
re-introduced just for convenience ( e.g. if we can assume that all
algebras supporting __mul__ that are relevant in some computation have
certain properties e.g. being associative ).
##
After thinking about M ( or Expr ;) a little more I come up with a
solution of the problem of central elements of an algebra ( at least
the identity element e is always central ) that commute with all other
elements.
Here is my approach:
# Define a subclass of list, that provides the same interface as list
and
# a customized sorting algorithm
import sets
class Factors(list):
def __init__(self,li):
list.__init__(self,li)
self.elems = sets.Set(li) # raw set of factors used in the
__mul__
self._center = () # storing central elements
commuting with
# with all others
def _get_center(self):
return self._center
def _set_center(self,center):
Center = sets.Set(center)
if not Center=self.elems:
raise ValueError,Subset required
else:
self._center = Center
center = property(_get_center, _set_center)
def __add__(self,li):
return Factors(list.__add__(self,li))
def sort(self):
center = list(self.center)
def commutator(x,y):
if isinstance(x,(int,float,long)): # numeral literals
should
return -1 # always commute
if isinstance(y,(int,float,long)):
return 1
if x == y:
return 0
if x in center:
if y in center:
if center.index(x)center.index(y): # induce an
aritrary
return -1
Re: Ordering Products
Diez B.Roggisch wrote: 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. O.K. 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. Diez, I try not to care too much about global operator precedence of builtin infix operators. The hard problems in designing a CAS beyond Mathematica are related to a bunch of interoperating algebras all defining their own operations. Finally only local precedences exist that are characteristic for certain patterns of expressions with a lot of tangled operators ( e.g. 'geometric algebra' with vector products, wedge products, inner products, additions and subtractions ). I don't want a system defining a syntactically extendable language with 10 custom punctuations per module that no one ( at least not me ) can remind and which looks as awkward as regular expressions. 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. Yes, but I tend to use __mul__ just for convenience. It is reflecting an associative and non-commutative operator whereas __add__ is a convenient way to fix an associative and commutative operator. In an idealized mathematical interpretation they represent nothing specific but as language elements they shall be fixed somehow. For more general operations one may define functional operators e.g. r_assoc and l_assoc where following (in)equations hold: l_assoc(a,b,c) == l_assoc(l_assoc(a,b),c) l_assoc(a,b,c) != l_assoc(a, l_assoc(b,c)) r_assoc(a,b,c) == r_assoc(a,r_assoc(b,c)) r_assoc(a,b,c) != r_assoc(r_assoc(a,b),c) This kind of pattern can be used to define rules about l_assoc and r_assoc. Nevertheless, there is no loss of generality. The system lacks prevention from deriving some class providing __mul__ and overwrite the implementation of __mul__ using l_assoc. People may do this on their own risk. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Kay Schluehr wrote: Hi Ron, I really don't want to discourage you in doing your own CAS but the stuff I'm working on is already a bit more advanced than my mono-operational multiplicative algebra ;) I figured it was, but you offered a puzzle: Here might be an interesting puzzle for people who like sorting algorithms ... And asked for suggestions: It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? So I took you up on it. ;-) BTW.. Usually when people say I don't want to discourage..., They really want or mean the exact oppisite. This is a organizational problem in my opinion, so the challenge is to organize the expressions in a way that can be easily manipulated further. Groupings by operation is one way. As far as inheritance goes, it's just another way to organize things. And different algebra's and sub-algebra's are just possible properties of a group. The groups can easily be customized to have their own behaviors or be created to represent custom unique operations. The sort method I'm suggesting here, with examples, is constrained by the associated properties of the group that is being sorted. Basically, weather or not it's and associative operation or not. So when a group is asked to sort, it first asks all it's sub groups to sort, then it sorts it self if it is an associative group. Ie.. from inner most group to outer most group but only the associative ones. Playing with it further I get the following outputs. ( The parenthesis surround a group that is associated to the operation. This is the same idea/suggestion I first proposed, it's just been developed a little further along.) b+a+2 = (2+a+b)- addition group a*(b+45+23) = ((68+b)*a) - addition group within multiply group a-4-3-7+b = ((a-14)+b)- sub group within add group c*b-d*a+2 = (2+((b*c)-(a*d))) - mults within subs within adds 7*a*8*9+b = ((504*a)+b) a*(b+c) = ((b+c)*a) c*3*a*d*c*b*7*c*d*a = (21*a*a*b*c*c*c*d*d) d*b/c*a = (((b*d)/c)*a) (d*b)/(c*a) = ((b*d)/(a*c)) d*b-a/e+d+c = (((b*d)-(a/e))+c+d) a/24/2/b = (a/48/b) c**b**(4-5) = (c**(b**-1)) (d**a)**(2*b) = ((d**a)**(2*b)) The next step is to be able to convert groups to other groups; an exponent group to a multiply group; a subtract group to an addition group with negative prefix's.. and so on. That would be how expansion and simplifying is done as well as testing equivalence of equations. if m*c**2 == m*c*c: print Eureka! Mixing operators is not really a problem, but one has to make initial decisions ( e.g about associativity i.e. flattening the parse-tree ) and sub-algebra generation by means of inheritance: What do you mean by 'sub-algebra generation'? a,b = seq(2,Expr) type(a+b) class '__main__.Expr' class X(Expr):pass x,y = seq(2,X) type(x+y) class '__main__.X' This is not particular hard. It is harder to determine correspondence rules between operations on different levels. On subalgebras the operations of the parent algebra are induced. But what happens if one mixes objects of different algebras that interoperate with each other? It would be wise to find a unified approach to make distinctive operations visually distinctive too. Infix operators may be re-introduced just for convenience ( e.g. if we can assume that all algebras supporting __mul__ that are relevant in some computation have certain properties e.g. being associative ). Different algebras would need to be able to convert themselves to some common representation. Then they would be able to be mixed with each other with no problem. Or an operation on an algebra group could just accept it as a unique term, and during an expansion process it could convert it self (and it's members) to the parents type. That would take a little more work, but I don't see any reason why it would be especially difficult. Using that methodology, an equation with mixed algebra types could be expanded as much as possible, then reduced back down again using a chosen algebra or the one that results in the most concise representation. ## After thinking about M ( or Expr ;) a little more I come up with a solution of the problem of central elements of an algebra ( at least the identity element e is always central ) that commute with all other elements. What is a central element? I can see it involves a set, but the context isn't clear. Here is my approach: # Define a subclass of list, that provides the same interface as list and # a customized sorting algorithm It's not really that different from what I suggested. And since my example is based on your first example. It has a lot in common but the arrangement (organization) is a bit different. Regards, Kay Here's the current version... It now handles
Re: Ordering Products
Ron Adam wrote: Kay Schluehr wrote: Hi Ron, I really don't want to discourage you in doing your own CAS but the stuff I'm working on is already a bit more advanced than my mono-operational multiplicative algebra ;) I figured it was, but you offered a puzzle: Here might be an interesting puzzle for people who like sorting algorithms ... And asked for suggestions: It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? So I took you up on it. ;-) 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 ;) This is a organizational problem in my opinion, so the challenge is to organize the expressions in a way that can be easily manipulated further. Groupings by operation is one way. As far as inheritance goes, it's just another way to organize things. And different algebra's and sub-algebra's are just possible properties of a group. The groups can easily be customized to have their own behaviors or be created to represent custom unique operations. The sort method I'm suggesting here, with examples, is constrained by the associated properties of the group that is being sorted. Basically, weather or not it's and associative operation or not. So when a group is asked to sort, it first asks all it's sub groups to sort, then it sorts it self if it is an associative group. Ie.. from inner most group to outer most group but only the associative ones. 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. Playing with it further I get the following outputs. ( The parenthesis surround a group that is associated to the operation. This is the same idea/suggestion I first proposed, it's just been developed a little further along.) b+a+2 = (2+a+b)- addition group a*(b+45+23) = ((68+b)*a) - addition group within multiply group a-4-3-7+b = ((a-14)+b)- sub group within add group c*b-d*a+2 = (2+((b*c)-(a*d))) - mults within subs within adds 7*a*8*9+b = ((504*a)+b) a*(b+c) = ((b+c)*a) 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. d*b/c*a = (((b*d)/c)*a) (d*b)/(c*a) = ((b*d)/(a*c)) d*b-a/e+d+c = (((b*d)-(a/e))+c+d) a/24/2/b = (a/48/b) c**b**(4-5) = (c**(b**-1)) (d**a)**(2*b) = ((d**a)**(2*b)) 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. The next step is to be able to convert groups to other groups; an exponent group to a multiply group; a subtract group to an addition group with negative prefix's.. and so on. That would be how expansion and simplifying is done as well as testing equivalence of equations. if m*c**2 == m*c*c: print Eureka! Mixing operators is not really a problem, but one has to make initial decisions ( e.g about associativity i.e. flattening the parse-tree ) and sub-algebra generation by means of inheritance: 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. a,b = seq(2,Expr) type(a+b) class '__main__.Expr' class X(Expr):pass x,y = seq(2,X) type(x+y) class '__main__.X' This is not particular hard. It is harder to determine correspondence rules between operations on different levels. On subalgebras the operations of the parent algebra are induced. But what happens if one mixes objects of different algebras that interoperate with each other? It would be wise to find a unified approach to make distinctive operations visually distinctive too. Infix operators may be re-introduced just for convenience ( e.g. if we can assume that all algebras supporting __mul__ that are relevant in some computation have certain properties e.g. being associative ). Different
Re: Ordering Products
Kay Schluehr wrote: Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? Hello Kay, take this into account: Restrictions like commutativity, associative, distributive and flexibility laws don't belong neither to operands nor to operators themselves. Instead these are properties of fields (set of numbers with respect to a certain operation). For a famous example for a somewhat alternative behaviour look at the Octonions (discovered in 1843 by Graves and 1845 by Cayley), which are not associative with respect to addition and/or multiplication. (http://en.wikipedia.org/wiki/Octonions) or the Quarternions, which are non-commutative (http://en.wikipedia.org/wiki/Quaternion) Obviously, it's not correct to say: addition is associative, or, that multiplication is. With the same right, you could say, multiplication is not associative. With the same reasoning, we can show that it's not easy to generalize sorting, commutation, association or distribution mechanisms. Maybe it would be a very fascinating goal to solve your algorithmic approach in such a limited environment like the Quarternions. A solution for this set of numbers, if achieved in a clean, mathematically abstract way, should hold for most other numbers/fields too, natural and real included. I guess that the approach might be this way: - define/describe the fields which shall be handled - define/describe the rules which shall be supported - find methods to reduce sequences of operations to simple binary or unary operations (tokens) - this may introduce brackets and stacking mechanisms - a weighing algorithm might be necessary to distinguish between plain numbers and place holders (variables) - application of the distributivity (as far as possible) might help to find a rather flat representation and a base for reordering according to the weights of the individual sub-expressions Nevertheless, there are lots of commercial programs which do such sort of symbolic mathematics, and which would badly fail when it would come to such awkward fields like Quarternions/Octonions. Bernhard -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Kay Schluehr wrote: Ron Adam wrote: Kay Schluehr wrote: On a more general note, I think a constrained sort algorithm is a good idea and may have more general uses as well. Something I was thinking of is a sort where instead of giving a function, you give it a sort key list. Then you can possibly sort anything in any arbitrary order depending on the key list. sort(alist, [0,1,2,3,4,5,6,7,8,9]) # Sort numbers forward sort(alist, [9,8,7,6,5,4,3,2,1,0]) # Reverse sort sort(alist, [1,3,5,7,9,0,2,4,6,8]) # Odd-Even sort sort(alist, [int,str,float]) # sort types Seems like you want to establish a total order of elements statically. Don't believe that this is necessary. I want to establish the sort order at the beginning of the sort process instead of using many external compares during the sort process. Using a preprocessed sort key seems like the best way to do that. How it's generated doesn't really matter. And of course a set of standard defaults could be built in. These are just suggestions, I haven't worked out the details. It could probably be done currently with pythons built in sort by writing a custom compare function that takes a key list. Exactly. The advantage of doing it as above would be the sort could be done entirely in C and not need to call a python compare function on each item. It would be interesting to see if and how much faster it would be. I'm just not sure how to do it yet as it's a little more complicated than using integer values. How fine grained the key list is is also something that would need to be worked out. Could it handle words and whole numbers instead of letters and digits? How does one specify which? What about complex objects? In order to handle complex objects one needs more algebra ;) Since the class M only provides one operation I made the problem as simple as possible ( complex expressions do not exist in M because __mul__ is associative - this is already a reduction rule ). Kay I'm played around with your example a little bit and think I see how it should work... (partly guessing) You did some last minute editing so M and Expr were intermixed. It looks to me that what you need to do is have the expressions stored as nested lists and those can be self sorting. That can be done when init is called I think, and after any operation. You should be able to add addition without too much trouble too. a*b - factors [a],[b] - [a,b] You got this part. c+d - sums [c],[d] - [c,d]Need a sums type for this. Then... a*b+c*d - sums of factors - [[a,b],[c,d]] This would be sorted from inner to outer. (a+b)*(b+c) - factors of sums - [[a,b],[c,d]] Maybe you can sub class list to create the different types? Each list needs to be associated to an operation. The sort from inner to outer still works. Even though the lists represent different operations. You can sort division and minus if you turn them into sums and factors first. 1-2 - sums [1,-2] 3/4 - factors [3,1/4] ? hmmm... I don't like that. Or that might be... 3/4 - factor [3], divisor [4] - [3,[4]] So you need a divisor type as a subtype of factor. (I think) You can then combine the divisors within factors and sort from inner to outer. (a/b)*(c/e) - [a,[b],c,[e]] - [a,c,[b,e]] Displaying these might take a little more work. The above could get represented as... (a*c)/(b*e) Which I think is what you want it to do. Just a few thoughts. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Bernhard Holzmayer schrieb: Kay Schluehr wrote: Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? Hello Kay, take this into account: Restrictions like commutativity, associative, distributive and flexibility laws don't belong neither to operands nor to operators themselves. Instead these are properties of fields (set of numbers with respect to a certain operation). For a famous example for a somewhat alternative behaviour look at the Octonions (discovered in 1843 by Graves and 1845 by Cayley), which are not associative with respect to addition and/or multiplication. (http://en.wikipedia.org/wiki/Octonions) or the Quarternions, which are non-commutative (http://en.wikipedia.org/wiki/Quaternion) Obviously, it's not correct to say: addition is associative, or, that multiplication is. With the same right, you could say, multiplication is not associative. It was associative in the tiny example I presented. I did not mentioned to discuss the evolving structure of the whole CAS here in detail which would be better done in an own newsgroup once an early version is released. Maybe the setting of the original question should be made more precise: associative, non-commutative multiplicative groups. Handling non-associative algebras like Lie algebras is a completely different matter and I'm not even sure which one is the best way to represent operations in Python? Maye this way? lie = Lie() # create an arbitrary Lie algebra (lie is again a class ) A,B = lie(),lie() # create two arbitrary elements of the Lie algebra lie[A,B] # create the commutator of the lie algebra by overloading lie[A,B] # the __getitem__ method lie[A,B] == -lie[-A,B] True If one wants to enforce assertions like lie[r*A,B] == r*lie[A,B] True for certain elements r of some group acting on lie, one must refine creation of lie in the initial assignment statement e.g. lie = Lie(V) where V is some vectorspace and the elements of lie are homomorphisms on V. V is created elsewhere. There are a lot of constraints induced by all the objects dynamically coupled together. With the same reasoning, we can show that it's not easy to generalize sorting, commutation, association or distribution mechanisms. Maybe it would be a very fascinating goal to solve your algorithmic approach in such a limited environment like the Quarternions. No CAS can represent infinitely many different representations of quaternions. But it should not be to hard to deal with an algebra that represents admissable operations on quaternions in an abstract fashion. A solution for this set of numbers, if achieved in a clean, mathematically abstract way, should hold for most other numbers/fields too, natural and real included. I guess that the approach might be this way: - define/describe the fields which shall be handled - define/describe the rules which shall be supported - find methods to reduce sequences of operations to simple binary or unary operations (tokens) - this may introduce brackets and stacking mechanisms - a weighing algorithm might be necessary to distinguish between plain numbers and place holders (variables) - application of the distributivity (as far as possible) might help to find a rather flat representation and a base for reordering according to the weights of the individual sub-expressions Nevertheless, there are lots of commercial programs which do such sort of symbolic mathematics, and which would badly fail when it would come to such awkward fields like Quarternions/Octonions. If you take a look on Mathematica or Maple both programs seem to interpret pure symbols as members of an associative and commutative algebra: expand( (a+x)^2) - a^2 + 2ax + x^2 This works very fast and accurate but is mathematically too restricted for me. For doing more advanced stuff one needs to do a lot of programming in either language shipped with the CAS for creating new packages. But then I ask myself: why not doing the programming labor in Python and redesign and optimize the core modules of the CAS if necessary? Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
I see, you're sensitive for the difficulties which might arise. That's the thing I wanted to point out. Maybe I was looking too far forward... My first thought was to add attributes/qualifiers to the operands to improve the sorting. Then I realized that these attributes/qualifiers were related to the operators, since multiplication and division use the same operands, but while in one case it is associative and commutative, it isn't in the other. I agree that all this leads too far. But one thing creeps into my mind again: I guess you'll always need an inverse operation: A class which can handle multiplication will certainly require an inverse operation like division. Bernhard -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Kay Schluehr wrote:
Here might be an interesting puzzle for people who like sorting
algorithms ( and no I'm not a student anymore and the problem is not a
students 'homework' but a particular question associated with a
computer algebra system in Python I'm currently developing in my
sparetime ).
For motivation lets define some expression class first:
This works for (simple) expressions with mixed multiplication and addition.
class F(list):
def __init__(self,*x):
#print '\nF:',x
list.__init__(self,x)
def __add__(self, other):
return A(self,other)
def __radd__(self, other):
return A(other,self)
def __mul__(self, other):
return M(self,other)
def __rmul__(self, other):
return M(other,self)
def __repr__(self):
return str(self[0])
def __order__(self):
for i in self:
if isinstance(i,A) \
or isinstance(i,M):
i.__order__()
self.sort()
class A(F):
def __init__(self, *x):
#print '\nA:',x
list.__init__(self, x)
def __repr__(self):
self.__order__()
return +.join([str(x) for x in self])
class M(F):
def __init__(self,*x):
#print '\nM:',x
list.__init__(self,x)
def __repr__(self):
self.__order__()
return *.join([str(x) for x in self])
a = F('a')
b = F('b')
c = F('c')
d = F('d')
print '\n a =', a
print '\n b+a+2 =', b+a+2
print '\n c*b+d*a+2 =', c*b+d*a+2
print '\n 7*a*8*9+b =', 7*a*8*9+b
a = a
b+a+2 = 2+a+b
c*b+d*a+2 = 2+a*d+b*c
7*a*8*9+b = 9*8*7*a+b -- reverse sorted digits?
The digits sort in reverse for some strange reason I haven't figured out
yet, but they are grouped together. And expressions of the type a*(c+b)
don't work in this example.
It probably needs some better logic to merge adjacent like groups. I
think the reverse sorting my be a side effect of the nesting that takes
place when the expressions are built.
Having the digits first might be an advantage as you can use a for loop
to add or multiply them until you get to a not digit.
Anyway, interesting stuff. ;-)
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Ordering Products
Here might be an interesting puzzle for people who like sorting algorithms ( and no I'm not a student anymore and the problem is not a students 'homework' but a particular question associated with a computer algebra system in Python I'm currently developing in my sparetime ). For motivation lets define some expression class first: class Expr: def __init__(self, name=): self.name = name self.factors = [self] def __mul__(self, other): p = Expr() if isinstance(other,Expr): other_factors = other.factors else: other_factors = [other] p.factors = self.factors+other_factors return p def __rmul__(self, other): p = M() p.factors = [other]+self.factors return p def __repr__(self): if self.name: return self.name else: return *.join([str(x) for x in self.factors]) One can create arbitrary products of Expr objects ( and mixing numbers into the products ): a,b,c = Expr(a),Expr(b),Expr(c) a*b a*b 7*a*8*9 7*a*8*9 The goal is to evaluate such products and/or to simplify them. For expressions like x = 7*a*8*9 this might be easy, because we just have to sort the factor list and multiply the numbers. x.factors.sort() x a*7*8*9 - a*504 This can be extended to arbitrary products: x = 7*a*b*a*9 x.factors.sort() x a*a*b*7*9 - (a**2)*b*63 Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Kay Schluehr wrote: Here might be an interesting puzzle for people who like sorting algorithms ( and no I'm not a student anymore and the problem is not a students 'homework' but a particular question associated with a computer algebra system in Python I'm currently developing in my sparetime ). folded x = 7*a*b*a*9 x.factors.sort() x a*a*b*7*9 - (a**2)*b*63 Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? Regards, Kay Looks interesting Kay. I think while the built in sort works as a convenience, you will need to write your own more specialized methods, both an ordering (parser-sort), and simplify method, and call them alternately until no further changes are made. (You might be able to combine them in the sort process as an optimization.) A constrained sort would be a combination of splitting (parsing) the list into sortable sub lists and sorting each sub list, possibly in a different manner, then reassembling it back. And doing that possibly recursively till no further improvements are made or can be made. On a more general note, I think a constrained sort algorithm is a good idea and may have more general uses as well. Something I was thinking of is a sort where instead of giving a function, you give it a sort key list. Then you can possibly sort anything in any arbitrary order depending on the key list. sort(alist, [0,1,2,3,4,5,6,7,8,9]) # Sort numbers forward sort(alist, [9,8,7,6,5,4,3,2,1,0]) # Reverse sort sort(alist, [1,3,5,7,9,0,2,4,6,8]) # Odd-Even sort sort(alist, [int,str,float]) # sort types These are just suggestions, I haven't worked out the details. It could probably be done currently with pythons built in sort by writing a custom compare function that takes a key list. How fine grained the key list is is also something that would need to be worked out. Could it handle words and whole numbers instead of letters and digits? How does one specify which? What about complex objects? Here's a quick sort function that you might be able to play with.. There are shorter versions of this, but this has a few optimizations added. Overall it's about 10 times slower than pythons built in sort for large lists, but that's better than expected considering it's written in python and not C. Cheers, Ron # Quick Sort def qsort(x): if len(x)2: return x# Nothing to sort. # Is it already sorted? j = min = max = x[0] for i in x: # Get min and max while checking it. if imin: min=i if imax: max=i if ij: # It's not sorted, break # so stop checking and sort. j=i else: return x # It's already sorted. lt = [] eq = [] gt = [] # Guess the middle value based on min and max. mid = (min+max)//2 # Divide into three lists. for i in x: if imid: lt.append(i) continue if imid: gt.append(i) continue eq.append(i) # Recursively divide the lists then reassemble it # in order as the values are returned. return q(lt)+eq+q(gt) -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Kay Schluehr kay.schluehr at gmx.net writes: Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? I don't think that sorting is the answer here. Firts of all IMHO you have to add an additional constraint - associativity of the operation in question So the problem could be reduced to making the constant parts be more associative than the non-constant parts. which you should be able to do with a parser. The BNF grammar could look like this: expr ::= v_expr * v_expr | v_expr v_expr ::= variable | c_expr c_expr ::= l_expr * literal | l_expr l_expr ::= literal | ( expr ) The trick is to create a stronger-binding multiplication operator on constants than on mixed expressions. This grammar is ambigue of course - so a LL(k) or maybe even LALR won't work. But earley's method implemented in spark should do the trick. If I find the time, I'll write an short implementation tomorrow. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Diez B.Roggisch wrote: Kay Schluehr kay.schluehr at gmx.net writes: Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? I don't think that sorting is the answer here. Firts of all IMHO you have to add an additional constraint - associativity of the operation in question So the problem could be reduced to making the constant parts be more associative than the non-constant parts. which you should be able to do with a parser. Hi Diez, I have to admit that I don't understand what you mean with the 'constant parts' of an expression? 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: def __eq__(self, other): if isinstance(other,M): return self.factors == other.factors return False 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: 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. Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordering Products
Ron Adam wrote: Kay Schluehr wrote: Here might be an interesting puzzle for people who like sorting algorithms ( and no I'm not a student anymore and the problem is not a students 'homework' but a particular question associated with a computer algebra system in Python I'm currently developing in my sparetime ). folded x = 7*a*b*a*9 x.factors.sort() x a*a*b*7*9 - (a**2)*b*63 Now lets drop the assumption that a and b commute. More general: let be M a set of expressions and X a subset of M where each element of X commutes with each element of M: how can a product with factors in M be evaluated/simplified under the condition of additional information X? It would be interesting to examine some sorting algorithms on factor lists with constrained item transpositions. Any suggestions? Regards, Kay Looks interesting Kay. I think so too :) And grouping by sorting may be interesting also for people who are not dealing with algebraic structures. I think while the built in sort works as a convenience, you will need to write your own more specialized methods, both an ordering (parser-sort), and simplify method, and call them alternately until no further changes are made. (You might be able to combine them in the sort process as an optimization.) A constrained sort would be a combination of splitting (parsing) the list into sortable sub lists and sorting each sub list, possibly in a different manner, then reassembling it back. And doing that possibly recursively till no further improvements are made or can be made. I think a comparison function which is passed into Pythons builtin sort() should be sufficient to solve the problem. I guess the comparison defines a total order on the set of elements defined by the list to sort. On a more general note, I think a constrained sort algorithm is a good idea and may have more general uses as well. Something I was thinking of is a sort where instead of giving a function, you give it a sort key list. Then you can possibly sort anything in any arbitrary order depending on the key list. sort(alist, [0,1,2,3,4,5,6,7,8,9]) # Sort numbers forward sort(alist, [9,8,7,6,5,4,3,2,1,0]) # Reverse sort sort(alist, [1,3,5,7,9,0,2,4,6,8]) # Odd-Even sort sort(alist, [int,str,float]) # sort types Seems like you want to establish a total order of elements statically. Don't believe that this is necessary. These are just suggestions, I haven't worked out the details. It could probably be done currently with pythons built in sort by writing a custom compare function that takes a key list. Exactly. How fine grained the key list is is also something that would need to be worked out. Could it handle words and whole numbers instead of letters and digits? How does one specify which? What about complex objects? In order to handle complex objects one needs more algebra ;) Since the class M only provides one operation I made the problem as simple as possible ( complex expressions do not exist in M because __mul__ is associative - this is already a reduction rule ). Kay -- http://mail.python.org/mailman/listinfo/python-list
