Skip to content

Conversation

@fingolfin
Copy link
Member

I made this last may and then forgot... I expect it will break stuff but I'd like to know what; ultimately it'd be good to get rid of this.

@fingolfin fingolfin added the release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes label Sep 25, 2025
@thofma
Copy link
Collaborator

thofma commented Sep 25, 2025

Yeah, I think this is mainly when going from Singular.n_FieldElem{S} back to the Oscar side. The signature we actually want to have is

(R::Field)(x::Singular.n_FieldElem{elem_type(R)})

but as this is not possible, we just catch everything. We could get rid of this if we used singular_coeff_ring everywhere I think.

@fingolfin
Copy link
Member Author

Thanks for the hints, @thofma ! Some questions:

  1. Of course (R::Field)(x::Singular.n_FieldElem{elem_type(R)}) is not a valid signature, but couldn't we at least use (R::Field)(x::Singular.n_FieldElem) ?

  2. In how far would singular_coeff_ring solve the issue?

  3. Wouldn't it be best to get rid of all this code and use iso_oscar_singular_coeff_ring resp. iso_oscar_singular_poly_ring everywhere? Or perhaps that's what you meant anyway?


For my own notes, one of the failing tests is test/Rings/mpoly.jl:254. Specifically:

julia> Zn = GF(ZZRingElem(10)^50+151)
Prime field of characteristic 100000000000000000000000000000000000000000000000151

julia> R, (x, y) = polynomial_ring(Zn, [:x, :y], internal_ordering = :degrevlex)
(Multivariate polynomial ring in 2 variables over Zn, FqMPolyRingElem[x, y])

julia> l = [x*y+x^3+1, x*y^2+x^2+1]
2-element Vector{FqMPolyRingElem}:
 x^3 + x*y + 1
 x*y^2 + x^2 + 1

julia> g = gens(groebner_basis(ideal(R, l); ordering = degrevlex(gens(R))))
ERROR: MethodError: no method matching (::FqField)(::Singular.n_FieldElem{FqFieldElem})
The object of type `FqField` exists, but no method is defined for this combination of argument types when trying to treat it as a callable object.

Closest candidates are:
  (::FqField)(::FqFieldElem)
   @ Nemo ~/.julia/packages/Nemo/IYwMw/src/flint/fq_default_extended.jl:698
  (::FqField)(::Int64)
   @ Nemo ~/.julia/packages/Nemo/IYwMw/src/flint/fq_default.jl:804
  (::FqField)(::FqPolyRingElem)
   @ Nemo ~/.julia/packages/Nemo/IYwMw/src/flint/fq_default_extended.jl:769
  ...

Stacktrace:
  [1] (::FqMPolyRing)(f::Singular.spoly{Singular.n_FieldElem{FqFieldElem}})
    @ Oscar ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:461
  [2] (::Oscar.var"#oscar_generators##0#oscar_generators##1")(x::Singular.spoly{Singular.n_FieldElem{FqFieldElem}})
    @ Oscar ./none:-1
  [3] iterate
    @ ./generator.jl:48 [inlined]
  [4] collect(itr::Base.Generator{Vector{Singular.spoly{…}}, Oscar.var"#oscar_generators##0#oscar_generators##1"})
    @ Base ./array.jl:790
  [5] oscar_generators(B::Oscar.BiPolyArray{FqMPolyRingElem})
    @ Oscar ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:652
  [6] oscar_generators
    @ ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:647 [inlined]
  [7] gen
    @ ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:300 [inlined]
  [8] iterate
    @ ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:318 [inlined]
  [9] iterate
    @ ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:315 [inlined]
 [10] copyto!(dest::Vector{FqMPolyRingElem}, src::Oscar.IdealGens{FqMPolyRingElem})
    @ Base ./abstractarray.jl:938
 [11] _collect
    @ ./array.jl:734 [inlined]
 [12] collect
    @ ./array.jl:728 [inlined]
 [13] gens(I::Oscar.IdealGens{FqMPolyRingElem})
    @ Oscar ~/Projekte/OSCAR/Oscar.spielwiese/src/Rings/mpoly.jl:324
 [14] top-level scope
    @ REPL[166]:1
Some type information was truncated. Use `show(err)` to see complete types.

@thofma
Copy link
Collaborator

thofma commented Sep 25, 2025

  1. Of course (R::Field)(x::Singular.n_FieldElem{elem_type(R)}) is not a valid signature, but couldn't we at least use (R::Field)(x::Singular.n_FieldElem) ?

Yes, I guess so, but it does not help with the problems that this method regularly causes. Problems (such as #976) arise because of the (R::Field)(...) part, since it leads to ambiguities with constructors of the form (R::SpecificFieldType)(x::RingElement) when calling (R::SpecicFieldType)(::Singular..n_FieldElem).

  1. In how far would singular_coeff_ring solve the issue?

Sorry, I meant iso_singular_[coeff_]ring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

package: Singular release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants