Weirdness with polytopes over a quadratic field

[fingolfin]

Consider this input:

julia> F, t = quadratic_field(3)
(Real quadratic field defined by x^2 - 3, sqrt(3))

julia> a = diagonal_matrix(F.([1, -1, -1]))
[1    0    0]
[0   -1    0]
[0    0   -1]

julia> b = matrix(F, [1//2 -t//2 0
                      t//2  1//2 0
                         0     0 1])
[        1//2   -1//2*sqrt(3)   0]
[1//2*sqrt(3)            1//2   0]
[           0               0   1]

julia> G = matrix_group(a, b)
Matrix group of degree 3 over F

julia> o = orbit(G, *, F.([1,1,1]));

julia> vert = matrix(F, collect(o));

julia> ph = convex_hull(vert)
Polyhedron in ambient dimension 3

I think the last command is slightly buggy, because the output is this:

julia> typeof(ph)
Polyhedron{QQFieldElem}

I have to use the semi-undocumented optional first argument to convex_hull (it is documented only in the barest sense: the docstring mentions it, but provides no other information);

julia> ph2 = convex_hull(nf_elem, vert)
Polyhedron in ambient dimension 3 with nf_elem type coefficients

julia> typeof(ph2)
Polyhedron{nf_elem}

Why do I even have to provide this? Can't it automatically determine it?

Anyway, I did not even notice the problem for quite a time, because everything worked, e.g. visualization. But then I tried this:

julia> ehrhart_polynomial(ph)
polymake:  WARNING: rule libnormaliz.ehrhartpoly: H_STAR_VECTOR, HILBERT_SERIES : RAYS | INPUT_RAYS failed: Some error in the normaliz input data detected: Generator degrees are too huge, h-vector would contain more than 10^6 entires. at /Users/mhorn/.julia/artifacts/e75f8bd18c56df0983c9054335c32294bb1eebac/share/polymake/bundled/libnormaliz/apps/polytope/rules/main.rules line 58.
ERROR: Can't locate object method "code" via package "1" (perhaps you forgot to load "1"?) at /Users/mhorn/.julia/artifacts/e75f8bd18c56df0983c9054335c32294bb1eebac/share/polymake/perllib/Polymake/Core/BigObjectType.pm line 1023.

Ooops, scary. I was about to suggest we catch this problem earlier, but now it looks as if ph is simply in an inconsistent state and the proper fix is to adjust the constructors to not allow this?

[fingolfin]

Another problem I had was to figure out how to create the polytope in the first place. So I am doing now convex_hull(nf_elem, matrix(F, collect(o))). As I already wrote, I'd expect the nf_elem to be redundant (the code should be able to figure it out) but I don't know the code, so perhaps this is harder than I naively expect it to be? Or maybe there is a legitimate reason to allow QQFieldElem here? (which?)

Moreover, I first tried convex_hull(collect(o)) (also with the nf_elem) but that run into weird errors:

julia> list = collect(o)
12-element Vector{Vector{nf_elem}}:
 [1, 1, 1]
 [1, -1, -1]
 [1//2*sqrt(3) + 1//2, -1//2*sqrt(3) + 1//2, 1]
 [-1//2*sqrt(3) + 1//2, -1//2*sqrt(3) - 1//2, -1]
 [1//2*sqrt(3) + 1//2, 1//2*sqrt(3) - 1//2, -1]
 [1//2*sqrt(3) - 1//2, -1//2*sqrt(3) - 1//2, 1]
 [-1//2*sqrt(3) + 1//2, 1//2*sqrt(3) + 1//2, 1]
 [-1//2*sqrt(3) - 1//2, -1//2*sqrt(3) + 1//2, -1]
 [1//2*sqrt(3) - 1//2, 1//2*sqrt(3) + 1//2, -1]
 [-1, -1, 1]
 [-1//2*sqrt(3) - 1//2, 1//2*sqrt(3) - 1//2, 1]
 [-1, 1, -1]

julia> convex_hull(list)
ERROR: MethodError: Cannot `convert` an object of type Int64 to an object of type nf_elem

Closest candidates are:
  convert(::Type{T}, ::T) where T
   @ Base Base.jl:64

Stacktrace:
  [1] setindex!(A::Vector{nf_elem}, x::Int64, i1::Int64)
    @ Base ./array.jl:969
  [2] augment(vec::Vector{nf_elem}, val::Int64)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/helpers.jl:157
  [3] homogenize(vec::Vector{nf_elem}, val::Int64)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/helpers.jl:170
  [4] (::Oscar.var"#2405#2406"{Vector{Vector{nf_elem}}, Int64})(i::Int64)
    @ Oscar ./none:0
  [5] iterate
    @ ./generator.jl:47 [inlined]
  [6] homogenized_matrix(x::Vector{Vector{nf_elem}}, val::Int64)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/helpers.jl:176
  [7] convex_hull(::Type{QQFieldElem}, V::Vector{Vector{nf_elem}}, R::Nothing, L::Nothing; non_redundant::Bool)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/Polyhedron/constructors.jl:188
  [8] convex_hull(V::Vector{Vector{nf_elem}}, R::Nothing, L::Nothing; non_redundant::Bool)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/Polyhedron/constructors.jl:200
  [9] convex_hull(V::Vector{Vector{nf_elem}}, R::Nothing, L::Nothing)
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/Polyhedron/constructors.jl:200
 [10] convex_hull(V::Vector{Vector{nf_elem}})
    @ Oscar ~/Projekte/OSCAR/Oscar.jl/src/PolyhedralGeometry/Polyhedron/constructors.jl:200
 [11] top-level scope
    @ REPL[82]:1

Could we support this, too?

[micjoswig]

Polytopes over (embedded) real number fields are in the making for a while. Progress in that direction was slightly stalled due to more urgent things coming up. Will be fixed very soon, but might require a new polymake release (plus the usual downstream yoga toward OSCAR).

[fingolfin]

Just to say

• ph = convex_hull(vert) now gives an error (instead of returning a Polyhedron{QQFieldElem})
• ph = convex_hull(nf_elem, vert) still works but the result cannot be visualized.

As a result, I am unable to do the visualization here anymore, which is a pity as this was the example used in Computeralgebra Rundbrief 72

[micjoswig]

nf_elem is (now) the wrong type. There was a major refactoring involving number fields and their embeddings. nf_elem is the now deprecated version of some Nemo type whose name I forgot.

@benlorenz and I are working on this.

But we need help from @thofma : Currently the constructor of an embedded number field from an abstract number field requires a second (float) parameter for giving the approximate root. To me it seems that adding 1.0 as the default value here should be useful and giving something which fits the intuition of most people. Am I right?

For instance, in the quadratic case, this should always give the positive root.

[fingolfin]

Fair enough. But perhaps convex_hull(vert) could still have a method in this case and give a helpful error, like "cannot use nf_elem, use XYZ instead" or so.

[micjoswig]

Fair enough. But perhaps convex_hull(vert) could still have a method in this case and give a helpful error, like "cannot use nf_elem, use XYZ instead" or so.

Yes. All of this is part of "working on this".

[thofma]

nf_elem is (now) the wrong type. There was a major refactoring involving number fields and their embeddings. nf_elem is the now deprecated version of some Nemo type whose name I forgot.

@benlorenz and I are working on this.

But we need help from @thofma : Currently the constructor of an embedded number field from an abstract number field requires a second (float) parameter for giving the approximate root. To me it seems that adding 1.0 as the default value here should be useful and giving something which fits the intuition of most people. Am I right?

For instance, in the quadratic case, this should always give the positive root.

Hm, yes, for quadratic ones this would always give the positive root. But I am not sure how useful that would be in general. For many other interesting examples, this will immediately lead to errors. For example, working with an n-th root of unity ,one would use a cyclotomic field, but then there is no closest root to 1.0. For this reasons I am bit reluctant to add a default value. Maybe @fieker has an idea.