Formal Symbolic Expressions
Jason Merrill
http://groups.google.com/group/sage-support/browse_thread/thread/78dc8d2d476acc46
but thought it was time to move it over to devel. The motivation is
to have a nice notation for formal integrals and derivatives:
sage: integral(sin(x),x).formal()
integral(sin(x),x)
If this is a good idea, then maybe it's a good idea to have a formal
method for all symbolic expressions.
sage: (x - x).formal()
x - x
Here's a monkeypatch that makes this work(ish)
from sage.calculus.calculus import SymbolicExpression
class FormalSymbolicExpression(SymbolicExpression):
def __init__(self,expr):
self.expr = expr
# just delegate everything to the input expression
for m in dir(expr):
self.m = m
def _repr_(self,simplify=False):
return self.expr._repr_(simplify=False)
# implement a _latex_ method
SymbolicExpression.formal = lambda self:
FormalSymbolicExpression(self)
def formal(expr):
try:
return expr.formal()
except AttributeError:
return expr
Let's see it in action
sage: x - x
0
sage: (x - x).formal()
x - x
sage: formal(x - x)
x - x
sage: simplify(formal(x - x))
0
sage: exp(i*pi)
-1
sage: formal(exp(i*pi))
exp(I*pi)
This won't work on integral or derivative yet because they aren't lazy
enough. But it seems like they could be made to behave like the
Function_* classes, for instance Function_exp above.
Cheers,
JM
Jason Merrill
> Here's a monkeypatch that makes this work(ish)
>
> from sage.calculus.calculus import SymbolicExpression
> class FormalSymbolicExpression(SymbolicExpression):
> def __init__(self,expr):
> self.expr = expr
> # just delegate everything to the input expression
> for m in dir(expr):
> self.m = m
> def _repr_(self,simplify=False):
> return self.expr._repr_(simplify=False)
> # implement a _latex_ method
>
> SymbolicExpression.formal = lambda self:
> FormalSymbolicExpression(self)
>
> def formal(expr):
> try:
> return expr.formal()
> except AttributeError:
> return expr
was leading to
sage: simplify(formal(exp(I*pi)))
e^(pi*I)
and presumably horrendous amounts of other strangeness. Here's
another try. It doesn't actually inherit from SymbolicExpression
anymore, which will probably cause some difficulty with isinstance
calls, but it's maybe a little closer
from sage.calculus.calculus import SymbolicExpression
class FormalSymbolicExpression():
self.expr = expr
return getattr(self.expr,attrib)
def __repr__(self,simplify=False):
return self.expr._repr_(simplify=False)
SymbolicExpression.formal = \
lambda self: FormalSymbolicExpression(self)
def formal(expr):
try:
return expr.formal()
except AttributeError:
return expr
sage: simplify(formal(exp(I*pi)))
-1
Regards,
JM
William Stein
Jason,
Just a heads up -- your code above is going to become pointless when we switch
to using Ginac as a backend for symbolic manipulation, since Sage will no longer
keep its own expression tree.
William
Jason Grout
I looked at your ginac/pynac symbolic stuff last night. It appears that
you just call a Gex_to_str function (or something like that) to print
out the expression, which presumably is a ginac thing. Calling latex()
on any expression just returns \text{printed representation}. If Sage
will not maintain the expression tree, will it be able to access it to
print out a latex form? Does Ginac output latex versions of expressions?
Thanks,
Jason
Robert Bradshaw
Hopefully there will still a way to query the tree, but I don't see
how you'll avoid simplifications like 2+2 -> 4 or 1+x+3+x -> 4+x via
this method. This would also be really useful for, e.g. plotting
(where one could delay the evaluation at the symbolic "x" until one
wants to plot, which seems to trip a lot of people up.)
- Robert
William Stein
Yes.
> Does Ginac output latex versions of expressions?
Yes.
William
Jason Merrill
>
> Jason,
>
> Just a heads up -- your code above is going to become pointless when we switch
> to using Ginac as a backend for symbolic manipulation, since Sage will no longer
> keep its own expression tree.
Ginac weren't in the pipeline--it's surely full of holes. The point
was just to try to get a working version of the idea across. Once the
Ginac code lands, will there be a way to represent formal
integration? Could there be? Would it look like this, or would you
want it to?
Regards,
JM
Burcin Erocal
There will be a way to represent formal integration and summation.
I believe avoiding automatic simplification of arbitrary expressions
requires more work (I haven't checked this yet.), but even that
shouldn't be too complicated. This is on my todo list though.
Did you manage to build the pynac package? If not, I can post a
modified version which should build in your environment so you can
start playing with the new code.
Cheers,
Burcin
Jason Merrill
>
> There will be a way to represent formal integration and summation.
> I believe avoiding automatic simplification of arbitrary expressions
> requires more work (I haven't checked this yet.), but even that
> shouldn't be too complicated. This is on my todo list though.
> Did you manage to build the pynac package? If not, I can post a
> modified version which should build in your environment so you can
> start playing with the new code.
(which I also had to do to build 3.1.2.rc2). Trying to apply the
patch at http://trac.sagemath.org/sage_trac/ticket/3872, though,
causes a conflict. Any chance there could be an updated patch
sometime soon that takes into account all the changes that went into
3.1.2?
Best,
JM
Burcin Erocal
Jason Merrill <jwme...@gmail.com> wrote:
>
> On Sep 18, 8:01 am, Burcin Erocal <bur...@erocal.org> wrote:
<snip>
> > Did you manage to build the pynac package? If not, I can post a
> > modified version which should build in your environment so you can
> > start playing with the new code.
>
> I am now able to install the spkg if I take macports off my path
> (which I also had to do to build 3.1.2.rc2). Trying to apply the
> patch at http://trac.sagemath.org/sage_trac/ticket/3872, though,
> causes a conflict. Any chance there could be an updated patch
> sometime soon that takes into account all the changes that went into
> 3.1.2?
You can use the bundle here:
http://www.risc.jku.at/people/berocal/sage/pynac.hg
Cheers,
Burcin
Jason Merrill
> On Thu, 18 Sep 2008 06:57:20 -0700 (PDT)
>
>
> > On Sep 18, 8:01 am, Burcin Erocal <bur...@erocal.org> wrote:
> <snip>
> > > Did you manage to build the pynac package? If not, I can post a
> > > modified version which should build in your environment so you can
> > > start playing with the new code.
>
> > I am now able to install the spkg if I take macports off my path
> > (which I also had to do to build 3.1.2.rc2). Trying to apply the
> > sometime soon that takes into account all the changes that went into
> > 3.1.2?
>
> You can use the bundle here:
>
> http://www.risc.jku.at/people/berocal/sage/pynac.hg
I was able to apply the above patch cleanly, and I now have a working
version of the new symbolic ring to play with. Thanks!
I'd like to have a better understanding of the status of pynac, and
what it means for working on Sage in the coming weeks. Now that I can
play with pynac, who should I tell about my experience, and what sorts
of things are useful to share? Pynac as it stands seems far from
feature complete, but I'm sure you already know that. For instance,
sage: x = var('x',ns=1)
sage: type(x)
<type 'sage.symbolic.expression.Expression'>
# No plotting, I assume most other numerical operations
# don't work for similar reasons
sage: plot(x^3,-3,3)
verbose 0 (3585: plot.py, _plot) WARNING: When plotting, failed to
evaluate function at 400 points.
verbose 0 (3585: plot.py, _plot) Last error message:
''sage.symbolic.expression.Expression' object is not callable'
# Making a callable symbolic function involving x actually
# changes x back to the old symbolic ring
sage: g(x) = x^3
sage: type(x)
<class 'sage.calculus.calculus.SymbolicVariable'>
Somehow I doubt a flood of bug reports like these would be useful
right now. But at the same time, William suggests that writing code
specific to the current calculus module is now pointless. So what is
the best use of time currently? Waiting? For how long?
I'm really grateful to Burcin and William for taking the time and
initiative to write this new code. Because of your leadership and
hard work, symbolics in Sage looks to have a bright future. But at
least to me, it has a hazy present.
Regards,
JM
William Stein
Yes. It is very very very far from "feature complete". In fact, we view
it as an absolutely minimal implementation of just enough to be useful
to start a second stage of development.
> For instance,
>
> sage: x = var('x',ns=1)
>
> sage: type(x)
> <type 'sage.symbolic.expression.Expression'>
>
> # No plotting, I assume most other numerical operations
> # don't work for similar reasons
> sage: plot(x^3,-3,3)
> verbose 0 (3585: plot.py, _plot) WARNING: When plotting, failed to
> evaluate function at 400 points.
> verbose 0 (3585: plot.py, _plot) Last error message:
> ''sage.symbolic.expression.Expression' object is not callable'
>
> # Making a callable symbolic function involving x actually
> # changes x back to the old symbolic ring
> sage: g(x) = x^3
> sage: type(x)
> <class 'sage.calculus.calculus.SymbolicVariable'>
>
> Somehow I doubt a flood of bug reports like these would be useful
> right now.
Yes, that would be useless.
> But at the same time, William suggests that writing code
> specific to the current calculus module is now pointless. So what is
> the best use of time currently? Waiting? For how long?
Yes. I'm sorry, but unfortunately this is how software development
sometimes works. It's painful. It has been very bad already because
another developer put a "lock" on symbolic calculus stuff in January 2008, and
in August had made worrisome progress. Yes, this is happening again
now, but hopefully Burcin/my progress will be much faster.
You could also help with the work to make the pynac based symbolic
calculus in sage feature complete.
> I'm really grateful to Burcin and William for taking the time and
> initiative to write this new code. Because of your leadership and
> hard work, symbolics in Sage looks to have a bright future. But at
> least to me, it has a hazy present.
I hope the above statements clarify the situation. You could also
look at the todo file in the
SAGE_ROOT/devel/sage/sage/symbolic
directory.
William