#20086: ZZ[X], QQ[X]: allow arbitrary powers of constant polynomials
-------------------------------------+-------------------------------------
Reporter: cheuberg | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-7.1
Component: basic arithmetic | Resolution:
Keywords: | Merged in:
Authors: Clemens Heuberger | Reviewers: Benjamin Hackl
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/cheuberg/polynomials/power | 892109ac4f48a4a32d35671365ecceb0d1c9e0bf
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by cheuberg):
Replying to [comment:18 vdelecroix]:
> Let me be more precise then
> {{{
> def __pow__(self, exp):
> cdef long n
> try:
> n = exp
> # old code for integer exponent
> except TypeError:
> n = QQ.coerce(exp)
> # new code for rational exponent
> }}}
ok, if you prefer it like that, we can probably do that.
> > I need a quick fix for `R(1)^(1/2)`. If somebody has time to implement
`((x+1)^2)^(1/2)` very soon, I'd be happy. I do not have time soon.
However, I want to have the code associated with a recently submitted
paper in 7.1.
>
> Are you sure there was a bug?
Do you think that disallowing `R(1)^(1/2)` is the desired behaviour?
> In Sage the integer 1 is *not* the 1 from ZZ[x] (though they are equal
through coercion). Some softwares behave differently to that respect (e.g.
GAP) where there is only one 1 which is an integer and not anything else.
In Sage (but not in GAP) it is already the case that operations change
with respect to the parents even if the objects are equal
> {{{
> sage: Zmod(10)(3) == 3
> sage: Zmod(10)(5) == 5
> sage: log(Zmod(10)(3))
> 3
> sage: log(Zmod(10)(5))
> Traceback (most recent call last):
> ...
> ZeroDivisionError: Inverse does not exist.
> }}}
I have no idea how this is related to this problem, sorry.
>
> > Basically, this fix here simply branches to existing code.
> > Computing `((x+1)^2)^(1/2)` needs new mathematical code (involving
square free decomposition).
>
> Indeed. Your modifications obfuscate the code for only a very trivial
case and a discutable behavior of powering with polynomials.
It might seem trivial to you, but it did cost me an hour while writing a
paper because basically, asymptotic rings using polynomial rings as
coefficient rings could not compute square roots, and, sorry, I need that.
>
> > Therefore, I propose to include this now on the basis that while this
is not a perfect and definitive solution, it is better than the previous
behaviour.
>
> Not sure it is better. Sage used to consider operations based on
parents. Powers are of course a special type of operation and with some
respect might be treated appart. But "(polynomial)^(polynomial)" is not
well defined. And "(polynomial)^(rational)" is well defined in some
situations (and to that respect, your code improves the current situation
a little).
There was a discussion on sage-devel a few weeks ago. Every parent seems
to have its own home-made logic about how to do coercion. Please do not
try to fix that in this ticket.
--
Ticket URL: <http://trac.sagemath.org/ticket/20086#comment:24>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
