On Thu, 23 Apr 2009 13:43:54 -0700
Ondrej Certik <ond...@certik.cz> wrote:
>
> On Thu, Apr 23, 2009 at 1:17 PM, Tim Lahey <tim.la...@gmail.com>
> wrote:
> >
> >
> > On Apr 23, 2009, at 4:07 PM, William Stein wrote:
> >
> >>
> >> Could you explain how assumptions are so important? Could you
>
> We already discussed this many times on this list, just search the
> archives. Without good assumptions, you cannot implement good
> integration, good solvers, good simplification, nothing. Of course,
> things like x+x is easy, but once you have for example
> Integral(<complex expression involving many constants>), sometimes you
> can simplify it, sometimes not and this very much depends on the
> assumptions for the constants. Or things like integrate(x**n, x).
>
> >> particularly address how they can (1) be so critically important,
> >> and yet (2) ginac doesn't have them. Incidentaly, to me they are
>
> ginac doesn't have any assumptions and so ginac doesn't have any
> advanced symbolic features.
> Of course, if the only thing that you are going to use ginac for is
> the core engine, then it should not matter much. But what I want from
> a CAS is to be able to do advanced symbolic calculations with symbols,
> so I need some way to tell it my assumptions about the symbols. Taking
> everything as complex numbers will not simplify things in many cases.
>
> >> particularly important in symbolic integration, which ginac doesn't
> >> do. Also, could you explain why the assumption system in Sympy
> >> needs to be rewritten -- in particular, what design decisions were
> >> suboptimal?
>
> Because we attach assumptions to symbols, e.g. you define
>
> In [2]: x = Symbol("x", positive=True)
>
> and then you work with that:
>
> In [3]: sqrt(x**2)
> Out[3]: x
>
> In [4]: x = Symbol("x", negative=True)
>
> In [5]: sqrt(x**2)
> Out[5]: -x
>
> In [6]: x = Symbol("x")
>
> In [7]: sqrt(x**2)
> Out[7]:
> ⎽⎽⎽⎽
> ╱ 2
> ╲╱ x
>
>
> But this approach is the wrong one, because then the core engine has
> to take this into account and it slows things down. Our new system
> will keep the assumptions external, and define methods to work with
> them, like in mathematica, e.g. refine(). This should simplify the
> core and then we should be able to speed it up.
Note that ginac has a similar mechanism, which it uses for the
automatic simplifications it does. I haven't exposed this in the Sage
interface. I don't know if Mike has either.
Here is a list of the info flags ginac supports (Scroll down for the
table):
http://www.ginac.de/tutorial/Information-about-expressions.html
Pynac has an "infinity" flag in addition to the ones listed there.
I admit that I have no experience with general simplification
routines, but I have the feeling that it all boils down to answering
is_positive(), is_integer() queries about expressions. The trick is to
be able to deduce the answers to these from a few bits of information
gathered from the user.
I don't know of any open source package which can provide this
capability for Sage. I've heard that Reduce with its Redlog package is
very powerful in this area. I doubt if it can be used from Sage though.
Cheers,
Burcin
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
