I don't believe that sage actually does the type type of
simplification I'm describing in any of its own code. RingElement for
example eventually calls the base rings addition which in all cases
that I can think of reduces to addition in a number field  and the
simplification happens automatically. Nearly all examples of
arithmetic eventually reduce to explicit addition.

Its important that I don't want to assume that we are in a polynomial
ring or this is trivial. I'm actually interesting in x and y being
tensors and wondering how
to program from scratch tensor calculus. Even in this case the example
x+y+x is a bit trivial but suppose that I want it to recognize various
identities of tensor calculus involving curvatures and use these to
simplify expressions.

This is similiar to defining a non-commutative ring by declaring
relations and then trying to simplify an expression in that ring.



 
Josh





On Apr 30, 1:04 am, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
> That's exactly what SymPy is doing. You can look at the design
> document, if you are interested:
>
> http://code.google.com/p/sympy/wiki/HowItWorks
>
> You can also look at ginac, they are basically doing the same as SymPy
> (only a little more complicated). But the basic things like
>
> x+y+x = 2*x+y
>
> is SAGE doing as well, at least if I understand it correctly, the
> relevant code is in:
>
> devel/sage/sage/structure/element.pyx
>
> see the method:
>
> RingElement.__mul__()
>
> and RingElement.__add__() and the documentation at the top of the module.
>
> Ondrej
>
> On 4/30/07, Joshua Kantor <[EMAIL PROTECTED]> wrote:
>
>
>
> > I  am actually interested in the internal representations and
> > manipulation required to do this sort of thing. I.e. how would one
> > duplicate the internal workings of maxima in python.
>
> > Josh
>
> > On Apr 29, 10:21 pm, Michel <[EMAIL PROTECTED]> wrote:
> > > The way maxima works that from the view point
> > > of the user there are very few automatic simplifications.
> > > There are however a lot of "expression manipulation commands" like
> > > "expand",
> > > "ratsimp", "factor", "trigexpand" etc...
>
> > > Some automatic simplifications are 12+14=26, x+x=2*x.
>
> > > Internally of course such manipulations are done a lot. Maxima
> > > uses a trick that if a subexpression has been simplified then
> > > a flag is added to that expression so that it is not resimplified
> > > again.
>
> > > Also noteworthy is that maxima makes a distinction between
> > > evaluation and simplification. Evaluation replaces
> > > variables by their values. Simplification replaces
> > > an expression by an equivalent one, independently of
> > > variable bindings.
>
> > > Somewhat strangely evaluation is not recursive which
> > > sometimes leads to counterintuitive behaviour.
>
> > > Michel
>
> > > On Apr 30, 6:22 am, Joshua Kantor <[EMAIL PROTECTED]> wrote:
>
> > > > Disclaimer: I think this may have more or less been covered in the
> > > > earlier mega-discussion on symbolic computation. Also the whole reason
> > > > we use maxima is to avoid dealing with the problems I'm describing but
> > > > I still
> > > > would like to think about it a bit and am curious if anyone has any
> > > > insight.
>
> > > > I have been thinking a lot about symbolic algebra.  I was thinking
> > > > about what would be required to do symbolic manipulations without
> > > > using maxima. If we represent symbolic expressions as trees of
> > > > operations and operands
> > > > then it seems what is needed is some sort of ability to define rules
> > > > to transform trees.
>
> > > > I will represent trees as lists in lisp notation so [+ a b] is the
> > > > tree
>
> > > >           a
> > > >        /
> > > >     /
> > > > +
> > > >     \
> > > >        \
> > > >           b
>
> > > > Consider a + b +a, this will be stored as [+ a [+ b a]] (or maybe [+
> > > > [+a b] a] )
>
> > > > Obviously this should become 2*a + b
>
> > > > If we could define rules that
>
> > > > [+ a b] = [+ b a]
> > > > [+ [+ a b] c] = [+ a [+ b c]]
> > > > [* 1 a] = a
> > > > [+ a [* c a ]] = [* (c+1) c]
>
> > > > then we could make this simplification, however even in this simple
> > > > case, I don't really know how one would automatically do this
> > > > simplification.
>
> > > > Perhaps one could make a rule that multiplication is simpler than
> > > > addition, squaring is simpler than multiplication, etc and rank the
> > > > expressions by their complexity under this ranking and search for
> > > > simpler expressions,
> > > > i.e. since we would find a way to replace an addition by a
> > > > multiplication, 2*a+b is a simpler expression.
>
> > > > We would also need pattern matching capabilities to deal with sub-
> > > > expressions.
>
> > > > i.e. we should be able to infer that
>
> > > > [+ a [+ b c] ]  = [+ [+ b c] a]
>
> > > > and matching [+ a [+ b c] ] to an abstract expresion of the form of
> > > > the first rule above.
>
> > > >  Does anybody know how this works in general.
>
> > > > Josh


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---

Reply via email to