An assumption framework is non-trivial as it is basically computational real algebraic geometry.
Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/ B/QEPCAD.html). Perhaps this might fit the bill? Michel On Aug 26, 8:43 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On Mon, Aug 25, 2008 at 11:29 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > > On Tue, Aug 26, 2008 at 12:49 AM, William Stein <[EMAIL PROTECTED]> wrote: > > >>> BTW, one important warning: ginac and sympycore are missing > >>> assumptions and sympy only has very trivial ones, like positive, > >>> negative, integer, even, odd, etc. This is really important for any > >>> nontrivial things in a CAS and I changes to the core may be needed. I > >>> really want to have assumptions in sympy first before saying -- yes, > >>> this approach to do the core is the best. > > >>> Ondrej > > >> Why are assumptions "really important for any nontrivial things in a CAS"? > >> In my entire life I've only ever used assumptions to get maxima to do > >> a symbolic integration. I've never used them in any other context. > >> Can you please educate me on why they are so important? Thanks. > > > Basically all more nontrivial simplifications. Things like to simplify > > sqrt(1-sin(x)**2) etc. Or acos(cos(x)). All of those are things that > > are needed to be automatic, but only work sometimes, e.g. if 0 < x < > > pi, or -pi/2 < x < pi/2 etc. This is obivously needed in integration > > and in solvers and also just when the user wants to simplify the > > expression. So in particular this is done inside ginac, so ginac need > > some way to handle these. Do you have any ideas how to do it? > > From reading the GiNaC docs I have the impression the *only* assumption > it supports is the assumption "x is a positive real number". I think there > are no other assumptions in GiNaC, though I could be wrong. > > I think GiNaC makes it a point not to simplify stuff automatically by > making assumptions, instead providing good pattern matching, > substitution, expression traversal and other tools. In fact somewhere > on their webpage they have the moto in bold "simplification is evil". > > Don't read the above as making any implications about what I think > Sage should do. We can of course tack on something more sophisticated, > and also decide to make our simplifications more sophisticated too, > if we so desire... > > -- William --~--~---------~--~----~------------~-------~--~----~ 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
