#15709: Powering with IntegerMod/GF exponents
----------------------------+------------------------
Reporter: ppurka | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.4
Component: coercion | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
----------------------------+------------------------
Description changed by jdemeyer:
Old description:
> From the [https://spreadsheets.google.com/pub?key=pCwvGVwSMxTzT6E2xNdo5fA
> google notebook bug reports]
> {{{
> # I lost several hours because Sage silently converted a number defined
> mod n to an integer
> # when it appeared as an exponent.
> # I was working in a different cyclotomic field, but the problem is right
> here in the complex numbers.
> # I believe I should have to explicitly convert to an integer unless the
> answer only depends on the value mod n.
> a=Mod(3,2)
> print type(a),a,2*a,(i^2)^a,i^(2*a)
>
> Output:
> <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'> 1 0 -1 1
> }}}
>
> ''This must surely have been discussed before. I would have tried to look
> up the discussion if I thought there was any hope that someone could
> convince me that this is not actually a bug.''
>
> ''Mod is not a synonym for remainder, and Sage is very good about not
> making the answer an integer. By later silently converting the answer
> into a remainder it has forsaken me, and undermined my trust.''
>
> (P.S.: The "I" above is not me. -ppurka)
New description:
From the [https://spreadsheets.google.com/pub?key=pCwvGVwSMxTzT6E2xNdo5fA
google notebook bug reports]
{{{
# I lost several hours because Sage silently converted a number defined
mod n to an integer
# when it appeared as an exponent.
# I was working in a different cyclotomic field, but the problem is right
here in the complex numbers.
# I believe I should have to explicitly convert to an integer unless the
answer only depends on the value mod n.
a=Mod(3,2)
print type(a),a,2*a,(i^2)^a,i^(2*a)
Output:
<type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'> 1 0 -1 1
}}}
This must surely have been discussed before. I would have tried to look up
the discussion if I thought there was any hope that someone could convince
me that this is not actually a bug.
Related, Nils Bruin reported on #11797:
{{{
sage: p=7
sage: k=GF(p)
sage: k(2)^k(p)
1
sage: (GF(7)(2))^(GF(5)(2))
4
sage: k(2)^p
2
}}}
It looks like it's simply quietly lifting the exponent to the integers,
which it shouldn't do because there is no coercion in that direction (only
a conversion):
{{{
sage: k.<a>=GF(p^2)
sage: k(2)^k(p)
1
sage: k(2)^k(a)
TypeError: not in prime subfield
sage: ZZ(k(1))
1
sage: ZZ(k(a))
TypeError: not in prime subfield
}}}
There is one side-effect of this that does look elegant:
{{{
sage: R=Integers(p-1)
sage: (k(2))^(R(p))
2
}}}
but in general I'd say an error should result from exponentiations like
this.
--
--
Ticket URL: <http://trac.sagemath.org/ticket/15709#comment:11>
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.
