Conversion of (Calcium)QQBar elements to "plain" number fields; matrix groups over it

[fingolfin]

I tried producing a rotation matrix in a "natural" fashion by using CalciumQQBar (soon to be renamed to QQBar). This worked quite well:

julia> e = one(CalciumQQBar)
Root 1.00000 of x - 1

julia> s, c = sinpi(2*e/5), cospi(2*e/5);

julia> mat = matrix(CalciumQQBar, [ c -s ; s c ])
[    Root 0.309017 of 4x^2 + 2x - 1   Root -0.951057 of 16x^4 - 20x^2 + 5]
[Root 0.951057 of 16x^4 - 20x^2 + 5        Root 0.309017 of 4x^2 + 2x - 1]

julia> mat^5
[Root 1.00000 of x - 1             Root 0 of x]
[          Root 0 of x   Root 1.00000 of x - 1]

Now I wanted to turn this into a group (a simple cyclic group of order 5):

julia> G_mat = matrix_group(mat)
Matrix group of degree 2
  over field of algebraic numbers```

But this group can't do much, we can't even compute its order. Trying to do so, we first hit a technical error:

julia> order(G_mat)
ERROR: attributes storage not supported for type CalciumQQBarField

but that can be worked around by adding @attributes CalciumQQBarField in the REPL (long term fix at Nemocas/Nemo.jl#1645).

Afterwards we get this:

julia> order(G_mat)
ERROR: MethodError: no method matching _iso_oscar_gap(::CalciumQQBarField)

Closest candidates are:
  _iso_oscar_gap(::ZZRing)
   @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/GAP/iso_oscar_gap.jl:215
  _iso_oscar_gap(::QQField)
   @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/GAP/iso_oscar_gap.jl:202
  _iso_oscar_gap(::MPolyRing{T}) where T
   @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/GAP/iso_oscar_gap.jl:538
  ...

Stacktrace:
  [1] __compute_iso_oscar_gap__(F::CalciumQQBarField)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/GAP/iso_oscar_gap.jl:457

Also not surprising, we simply don't support this yet.

I think there are two things of interest here:

• add code which takes a bunch of elements of QQBar (or possibly a matrix, or a bunch of matrices...) and tries to produce a number field K in which these elements can be represented. I guess this would return a function which converts from QQBar elements to K (or perhaps cleaner: a morphism K \to QQBar which allows computing preimages)
• code to support matrix groups over this field, at least finite matrix groups
  • e.g. by adding _iso_oscar_gap method to handle QQBarField, at least "when possible"
  • and/or by adapting _isomorphic_group_over_finite_field to support this
  • ... or by any other means

CC @ThomasBreuer

[fieker]

As I said before: QQbar is not connected to anything. In experimental/GModule (where else?) of course is function Hecke.number_field(::QQField, a::qqbar; cached::Bool = false) which does ist for individual elements, even supporting QQ[alpha] ...

[fingolfin]

@fieker thanks for pointing out these existing conversions.

I realize we haven't connected QQBar to anything yet, which is why I'd like to start doing it now :-).

[fieker]

julia> e = one(CalciumQQBar) Root 1.00000 of x - 1 julia> s, c = sinpi(2*e/5), cospi(2*e/5); julia> K, mp = QQ[s] (Number field of degree 4 over QQ, Map: number field -> QQBar) julia> preimage(mp, c) 2*_a^2 - 3//2 julia> mat = matrix(CalciumQQBar, [ c -s ; s c ]) [ Root 0.309017 of 4x^2 + 2x - 1 Root -0.951057 of 16x^4 - 20x^2 + 5] [Root 0.951057 of 16x^4 - 20x^2 + 5 Root 0.309017 of 4x^2 + 2x - 1] julia> map_entries(pseudo_inv(mp), mat) [2*_a^2 - 3//2 -_a] [ _a 2*_a^2 - 3//2] julia> ans^5 [1 0] [0 1]

[ThomasBreuer]

In this example, we are lucky that the number field can be produced from one qqbar element. My understanding was that we are given a finite number of qqbars, and have to find a common number field that contains them. Does the question for such a number field make sense in general?

[lgoettgens]

I tried producing a rotation matrix in a "natural" fashion by using CalciumQQBar (soon to be renamed to QQBar).

The QQBar export has been removed after discussion in #1379 (comment). Of course, this should be consistent with CalciumQQBar as well...

[fingolfin]

I am happy to not have QQBar exported as long as I can eventually use algebraic_closure(QQ) ;-)

[fieker]

On Wed, Jan 31, 2024 at 01:14:25AM -0800, Thomas Breuer wrote: In this example, we are lucky that the number field can be produced from one `qqbar` element. My understanding was that we are given a finite number of `qqbar`s, and have to find a common number field that contains them. Does the question for such a number field make sense in general?

Yes, as qqbar elemnts have an embedding as well, so the compositum is well defined - possibly

…

-- Reply to this email directly or view it on GitHub: #3279 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[fingolfin]

Since qqbar comes with an embedding into C, but also can decide if some element is actually real, it may be better to go via the embedded number fields in Hecke?