On Tue, Aug 26, 2008 at 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".
Yep I know all ginac documentation and I fully agree with
simplification is evil, that's why I wrote in our own simplify
function's docstring:
"
Naively simplifies the given expression.
Simplification is not a well defined term and the exact strategies
this function tries can change in the future versions of SymPy. If
your algorithm relies on "simplification" (whatever it is), try to
determine what you need exactly - is it powsimp(), or radsimp(),
or together(), or something else? And use this particular function
directly, because those are well defined and thus your algorithm
will be robust.
"
>
> 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...
I don't know either what the best way forward is, until we actually
have something that is general and robust and maintainable.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
