#15605: (-1)^(2/3) evaluates to 1
-------------------------------+------------------------
Reporter: mmezzarobba | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.4
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
-------------------------------+------------------------
Comment (by mmezzarobba):
Replying to [comment:7 tmonteil]:
> this is somehow a feature of the symbolic ring : no semantics.
I agree in part only. Sure, general symbolic expressions have very weak
semantics—essentially, I view them as straight-line programs that are just
required to evaluate to what you'd expect when you assign values to free
variables. Many ''operations'' on symbolic expressions, however, only make
sense with stronger assumptions on the expressions. Typically,
simplifications are supposed to transform these ”programs“ into
”equivalent“ ones, but of course whether two ”programs“ are equivalent
depends on what the variables can represent.
The sensible thing to do IMO is to view all variables as complex by
default, and require simplifications to be valid for arbitrary complex
values of all variables (or more accurately, for a generic choice of
complex values: for example, we probably do want `x/x` to simplify to
`1`). At least what's what Maple does, and Maple arguably has the best
implementation of ”general symbolic expressions” over there.
We'll still get nonsense in many cases when trying to simplify expressions
containing constants from finite fields or other parents that do not fit
well into this model, but I don't know how to avoid that. (Something that
may be worth trying would be to define new symbolic ”rings“ parametrized
by a parent. For instance, in `SR(QQ)`, all variables would be assumed to
represent elements of `QQ`, constants would automatically be coerced into
`QQ`, and arithmetic operations between constants would take place there.
But that's not how the existing `SR` works.)
> If one want to have something that both:
> - applies rules such as `a^(bc) = (a^b)^c` systematically,
I don't think we want that. IMO this rule should be applied only if either
assumptions on `a`, `b`, `c` make it safe (e.g., `c` is known to be an
integer) or the user explicitely asked for it. Of course, safe
simplification routines are more cumbersome to use. To mitigate the issue,
Maple's `simplify` accepts an option (`symbolic`) that tells it to
disregard all analytical issues related to multivalued functions and just
take any branch it likes. Something like that would be convenient in Sage
as well.
--
Ticket URL: <http://trac.sagemath.org/ticket/15605#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
