Opened 9 years ago

Last modified 2 years ago

#8751 new defect

conversion between non-prime finite fields

Reported by: zimmerma Owned by: AlexGhitza
Priority: minor Milestone:
Component: basic arithmetic Keywords: sd51
Cc: cremona, jpflori, defeo, pbruin Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

I noticed the following with Sage 4.3.5:

sage: R = GF(9,name='x')
sage: Q.<x> = PolynomialRing(GF(3))
sage: R2 = GF(9,name='x',modulus=x^2+1)
sage: a=R(x+1)
sage: R2(a)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/users/caramel/zimmerma/svn/sagebook/tex/<ipython console> in <module>()

/usr/local/sage-core2/local/lib/python2.6/site-packages/sage/rings/finite_field_givaro.so in sage.rings.finite_field_givaro.FiniteField_givaro.__call__ (sage/rings/finite_field_givaro.cpp:4754)()

TypeError: unable to coerce from a finite field other than the prime subfield

This is ok since indeed a=x+1 is not in the prime subfield. But:

sage: b=R(1)
sage: R2(b)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/users/caramel/zimmerma/svn/sagebook/tex/<ipython console> in <module>()

/usr/local/sage-core2/local/lib/python2.6/site-packages/sage/rings/finite_field_givaro.so in sage.rings.finite_field_givaro.FiniteField_givaro.__call__ (sage/rings/finite_field_givaro.cpp:4754)()

TypeError: unable to coerce from a finite field other than the prime subfield

In this case b=1 *is* in the prime subfield!!!

Side question: is there a (simple) way to get the isomorphism between R and R2?

Change History (13)

comment:1 follow-up: Changed 6 years ago by zimmerma

  • Cc cremona added

any progress on the isomorphism between finite fields?

Paul

comment:2 in reply to: ↑ 1 Changed 6 years ago by cremona

Replying to zimmerma:

any progress on the isomorphism between finite fields?

Paul

See #8335

comment:3 Changed 6 years ago by jpflori

  • Cc jpflori added

If anything has to be done here, it should definitely be after #8335 gets in indeed.

comment:4 Changed 6 years ago by jpflori

  • Cc defeo added

I guess here would be the place to craft a super fast system for "general" finite fields once #8335 and #11938 are done.

Some references:

comment:5 follow-up: Changed 6 years ago by jpflori

Link to Allombert paper:

Rains communicated me its work.

So I guess I now have all that is needed to begin coding.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 6 years ago by cremona

Replying to jpflori:

Link to Allombert paper:

Since he is a lead developer of pari and says in the paper that he has implemented his algorithm in pari, can we not just use that implementation by wrapping it?

Rains communicated me its work.

So I guess I now have all that is needed to begin coding.

comment:7 in reply to: ↑ 6 Changed 6 years ago by jpflori

Replying to cremona:

Replying to jpflori:

Link to Allombert paper:

Since he is a lead developer of pari and says in the paper that he has implemented his algorithm in pari, can we not just use that implementation by wrapping it?

Of course, but that will not give us "lattices of compatible finite fields".

The way I see it, we should get the following tickets merged in that order:

  • #8335 David Roe's for lattices using (pseudo) Conway polynomials, this only goes up and is obviously inefficient for large fields,
  • #11938 which implements going down for finite field using Givaro,
  • maybe extend it to all fields using pseudo-Conway polynomials in a follow-up ticket,
  • #13214 by Xavier Caruso, not sure how useful that will be, but that can give a nice code basis to start upon,
  • this ticket to implement general lattices of compatible finite fields.

    Rains communicated me its work.

    So I guess I now have all that is needed to begin coding.

comment:8 Changed 6 years ago by pbruin

  • Cc pbruin added

comment:9 Changed 6 years ago by defeo

Replying to jpflori

Since it has been mentioned in the tickets related to this one, here's some more literature (by Doliskani, Schost and myself):

...still quite far from the complete picture.

comment:10 Changed 6 years ago by pbruin

  • Keywords sd51 added

comment:11 Changed 2 years ago by zimmerma

any progress on this ticket?

comment:12 Changed 2 years ago by jpflori

Not on my side... We've been indenpendently working on computation of embeddings with Luca and others at:

Inspired by this, the code in PARI/GP should be much better than 4 years ago as well.

Note: See TracTickets for help on using tickets.