#11685: Pari finite field extension: element created by list not recognised as
zero
----------------------------------------+-----------------------------------
Reporter: johanbosman | Owner: AlexGhitza
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.7.2
Component: algebra | Keywords: finite fields, pari
Work_issues: | Upstream: N/A
Reviewer: Simon King, Johan Bosman | Author: Johan Bosman, Jeroen
Demeyer
Merged: | Dependencies:
----------------------------------------+-----------------------------------
Comment(by SimonKing):
Replying to [comment:26 jdemeyer]:
> Note that most of the timing overhead in my latest patch is due to the
creation of the `FiniteField` object. Maybe we could add a
`prime_field()` cached method and use that?
There is a `prime_subfield()` method, and you are perfectly right that it
ought to be a cached method. Hopefully someone finally manages to review
#11115: It would make cached methods ''very'' fast.
"Breaking down into two simpler steps" makes sense. But one should keep in
mind that it will now be ''two'' steps that could break. And if you
measure simplicity in lines of code: Both patches have six lines of code
in the section we are now talking about (if I did not miscount).
Perhaps we should clarify what we want to do with a list.
Let K be a finite field that is not a prime field. To the very least, we
want: If L is a list of elements of the prime subfield k of K then K(L)
should first interprete L as the list of coefficients of a polynomial, and
interprete the polynomial as an element of K.
Ideally, we also want to allow in L objects that can be converted into k,
even though their parent is not k in the first place. We seem to disagree
on how that conversion is best done.
1) The first patch seems to argue that, ultimately, we want to put stuff
into pari, and so we should start to put it into pari as soon as possible,
and do all further conversions there: We can put a list of field elements
into pari, and we can easily convert things like pari(K(0)) into an
element of pari(k).
2) The second patch seems to argue that we are Sage programmers, and thus
the conversion should follow Sage standards, not pari standards. Thus, k
is a finite prime field in Sage, and we only accept things that can be
converted into that prime field. Apparently, an element of pari(K) that
happens to belong to pari(k) fails to convert into k, sadly.
I think that both approaches are equally simple, and both approaches make
sense.
So, I suggest to decide based on (a) speed and (b) generality. (b) could
be problematic, since at the moment we have examples that only work with
the first patch and examples that only work with the second patch.
According to Johan, things are already quite slow, so, speed should really
matter most.
By the way, I'd prefer fast code with many features, if I can pick only
two out of three...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11685#comment:28>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
