Add transformations for polyhedral fans and complexes

[YueRen]

This draft pull request comes from the Leipzig Workshop aims to add the following new operations:

• Scalar * PolyhedralFan and PolyhedralFan * Scalar
• Scalar * PolyhedralComplex and PolyhedralFan * Scalar
• -PolyhedralFan
• -PolyhedralComplex
• Vector + PolyhedralFan and PolyhedralFan + Vector
• Vector + PolyhedralComplex and PolyhedralComplex + Vector

Questions:

1. Do we want these functions? My collaborators and I need it for various reasons:

• negation is useful to construct the negated Bergman fan of a matroid (arises for example here)
• translation is useful to see how the initial ideals of the tropical intersection points vary (relevant for example for this)

(If yes, I will add the relevant operators for Cone, the operators for Polyhedron already exist)

2. Is the implementation okay (in particular, I wasn't 100% sure where to put the functions)?

[codecov]

Codecov Report

❌ Patch coverage is 85.71429% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.99%. Comparing base (207c319) to head (66207cd).
⚠️ Report is 41 commits behind head on master.

Files with missing lines	Patch %	Lines
...ometry/PolyhedralComplex/standard_constructions.jl	88.88%	4 Missing ⚠️
...alGeometry/PolyhedralFan/standard_constructions.jl	76.92%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4444      +/-   ##
==========================================
- Coverage   84.19%   83.99%   -0.20%     
==========================================
  Files         715      721       +6     
  Lines       97732    98528     +796     
==========================================
+ Hits        82283    82760     +477     
- Misses      15449    15768     +319     

Files with missing lines	Coverage Δ
src/PolyhedralGeometry/helpers.jl	83.07% <ø> (-0.53%)	⬇️
src/PolyhedralGeometry/iterators.jl	92.47% <ø> (ø)
...alGeometry/PolyhedralFan/standard_constructions.jl	97.91% <76.92%> (-2.09%)	⬇️
...ometry/PolyhedralComplex/standard_constructions.jl	91.30% <88.88%> (-8.70%)	⬇️

... and 62 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[benlorenz]

I think it does make sense to have such operations but they should not be limited to rationals and compatible types but probably use scalar_types_extended and then try to coerce the values with coefficient_field(P)(x) (for rational fans / complexes this would give QQ but it would also work for number fields and other types).

You can try with normal_fan(dodecahedron()) as a number field example and normal_fan(n_gon(7)) as a QQBar example.

Edit: And the first argument for the new object should always be the coefficient field of the old object, e.g. polyhedral_fan(coefficient_field(f), ...).

[YueRen]

@benlorenz I tried changing the code as you suggested, but I cannot get it to work. Can you check why the the following addition is undefined?

julia> Sigma = normal_fan(cube(2))
Polyhedral fan in ambient dimension 2

julia> Sigma + [1,1]
ERROR: MethodError: no method matching +(::PolyhedralFan{QQFieldElem}, ::Vector{Int64})
The function `+` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  +(::Any, ::Any, ::Any, ::Any...)
   @ Base operators.jl:596
  +(::Oscar.StraightLinePrograms.Lazy, ::Any)
   @ Oscar ~/.julia/dev/Oscar/src/StraightLinePrograms/lazy.jl:104
  +(::Any, ::Oscar.StraightLinePrograms.Lazy)
   @ Oscar ~/.julia/dev/Oscar/src/StraightLinePrograms/lazy.jl:105
  ...

Stacktrace:
 [1] top-level scope
   @ REPL[4]:1

I was hoping for it to call the following added line in src/PolyhedralGeometry/PolyhedralComplex/standard_constructions.jl:

+(Sigma::PolyhedralFan, v::Vector{<:scalar_types_extended}) = polyhedral_complex(Sigma)+v

[lgoettgens]

julia> Oscar.scalar_types_extended
Union{Float64, FieldElem, ZZRingElem}

it seems that Int is not part of the type union. Let's hope that @benlorenz has an easy solution for this

[YueRen]

In that case, the simplest solution would probably be added all the missing types to scalar_types_extended, provided that is what the type was designed for in the first place.

[benlorenz]

I had a look at other uses of that union and it should be fine to change it to Union{scalar_types,IntegerUnion} to allow ZZ and Integer.

Edit: it looks like this might need some extra changes for the ray- and pointvectors ...

[benlorenz]

from #4445 (comment)

@benlorenz I've changed scalar_types_extended:

-const scalar_types_extended = Union{scalar_types,ZZRingElem}
+const scalar_types_extended = Union{scalar_types,IntegerUnion}

However, it creates a bunch of errors in the type tests that I don't know how to fix: oscar-system/Oscar.jl/actions/runs/12946690999/job/36111735653?pr=4444#step:8:746

Can you please look into it when you have the time (most likely not during the currently ongoing polymake developer meeting)? Many thanks in advance!

from #4445 (comment)

I am confused, as this PR does not touch scalar_types_extended ?!?

Anyway, the error in the linked log suggest that more things need to be changed if you adjust scalar_types_extended. Presumably if an Int is now used in places, them at some point some code may call parent on it, and this yields Integers{Int64}() -- a special placeholder parent for Julia integers that AA provides. And apparently this is then passed as first argument to point_vector which doesn't know about it.

Thanks, I am aware of the issue and will take a look.

[benlorenz]

The broadcast errors should be fixed now (and I fixed a small issue in the fan negation).

I think most of these constructions would benefit from adding non_redundant=true ? (Since they are using non-redundant data from the original objects)

[fingolfin]

What the status of this PR?

[YueRen]

Sorry for sleeping on this PR, I will look into it and see whether it is mergeable.

[fingolfin]

Looks good to me

[fingolfin]

The formatter complains now, but that could be addressed by running julia etc/format_code.jl (and even someone else can run it for you, @YueRen).

The main question is whether @lkastner and @benlorenz are happy with the the general content now, the formatting is an easy afterthought.

[YueRen]

The formatter complains now, but that could be addressed by running julia etc/format_code.jl (and even someone else can run it for you, @YueRen).

The main question is whether @lkastner and @benlorenz are happy with the the general content now, the formatting is an easy afterthought.

I've run the formatting script and pushed the changes.

[lkastner]

Thank you. We should probably expand transform on the polymake side though.